Not sure what to do...

I've been doing the things out of books for years. I found that I have huge issues thinking of ideas to program and when I do I have even more trouble breaking it down through the steps of idea, pseudo-code, actual code (and whatever steps are in between each). I wanted to program video games and went to college thinking it would teach me what I was lacking in to become better at programming. It didn't. I now have a degree in game and simulation programming and still feel like I'm no where near being a game programmer. Console apps are fine for me (currently coding an address book just for the heck of it). It drives me nuts because I know the language pretty good from all the reading, but can't figure how to overcome my issue of designing it from thought/idea to final design. I'm fairly certain if I had that in place I'd be good to go. Is there anything I can do to help with this? All I ever got at Allegro and Moosader sites were "just code" like it would just suddenly remedy itself if I spent hours fighting the same problem.

(I have this on cplusplus.com too to try and widen my advice consumption range).

My advice is get out of the theory and into practice or put the theories you've learned into practice. Game / simulation programming is still a type of black art in that there is not one book that will or could teach you everything about it. Because game programming differs from game to game and encompasses a whole range of disciplines it is hard to quantify every game and/or how it should be engineered. As well games in their purest form are more art than technology. I like to think of a game programmer as an artist who uses technology as his canvas.

That being said there are several design patterns and approaches to game development that can aid you in creating a game. Since you have had the classes and learning I highly recommend you either buy a 3rd party engine and start from there or use an open source one. Torque Pro by Garage Games is extremely cost effective right now and comes with a good tool set to get started. Unity3D is another 'engine' that is decent if not a bit limited due to their C# scripting approach and 'everything by the editor, for the editor, and in the editor' approach.

Decide what you want to do. If you want to make a game then the above advice is going to get you there fairly quick. If you want to design the system that runs the game then you will be rolling your own engine. I tend towards designing the low-level data driven systems that run the game rather than the scripts and data that make up the game. Most of game programming per se is not programming at all but rather scripting that is done within an existing engine. Change the scripts and the data and you get a very different game running on the same engine. It has to be this way b/c although C++ is great for game engine programming it actually falls quite short for actual game logic. Those two parts of the whole 'game' have very different requirements and it just so happens that scripting languages like Lua, Python, Ruby, and others tend to fair better as actual game logic 'code'. The biggest benefit is that they can change and yet the game itself never has to be recompiled which saves a lot of time and money.

If you want to make a game start cranking out some storyboards and/or rudimentary goals of the game and then start scripting it in whatever language your engine of choice supports. If you want to make a game engine then start cranking out some requirements and UML diagrams. Then go download MSVS 2010 Express and start implementing and iterating on your design. Another alternative is to use C# and XNA. XNA is about as low level as Direct3D with a few more abstractions to make certain tasks simpler than pure Direct3D. In the end both will serve you well so it is up to you to decide if you want to engineer it in C++ or C#. My recommendation is if you are building a game engine leave the heavy lifting to C++.

I found that I have huge issues thinking of ideas to program and when I do I have even more trouble breaking it down through the steps of idea, pseudo-code, actual code.

You will hear a lot of crap about using "brain clouds", "UML", "CRC Cards", or other such things to help you develop a feel for what you need to do next.

Unfortunately, that's all garbage. Until you have a feel for how components tend to interact in practice you can't very well document that relationship in planning. (Imagine trying to explain "Lego" blocks without ever having seen them.) I could post a link to something like common "OOP" design patterns "Observer" and "Visitor". In theory that information would get you started. Those things only represent a vocabulary. For example, VirtualAce might post about a new library facility and we could discuss the design in terms of that vocabulary without my ever needing to see the source. That is extremely useful, but the knowledge of what doesn't provide the experience of when.

Weirdly, the advice to "just code" or "get into practice" is the correct advice.

Here is my advice relating to practice: get yourself a highly valued programming book in your target language, do every example in the book in strict order, and then repeat those examples. It sounds stupid doesn't it? Sure, doing the examples once will be educational, but why do them a second time? Even if you aren't a genius certain things are going to stick in your head so doing them a second time must provide little benefit. Well, there is a reason you are getting "Practice." as advice. It works. In the repeated application of what you are learning throughout the book you will begin to see patterns. Those patterns will eventually form a fabulous set of tools you can reach for in approaching future problems. Sure, once you have a feel for those tools you can name them with "Object Oriented Patterns", describe them with "CRC Cards", and document them with "UML". That's a great idea, but you need to develop a feel for at least the basic patterns first.

"Practice." is truly the only way. A lot of places are dumping garbage programmers into the field who can't develop for crap because they have little real experience. (The degree being based on something else entirely.) Syntax, API, and the environment are all just painful details. You want to learn real development, you practice.

Soma

A lot of places are dumping garbage programmers into the field who can't develop for crap because they have little real experience.

That is pretty much what happened to me. They had me do basics, then for the courses they used Torque but they did it so you had the functions and code you were supposed to make up on your own right there (their online courses were pathetic as it was just flat out copy and paste then compile run and submit a screenshot to show it working. I'm in debt thanks to the college and turned down everywhere I applied.

I'm program console stuff pretty easy (as I'm doing an address book right now and a lot of it is changes done on the fly with limited pre-thought other than a few notes on paper). I always wanted to be the game engine programmer (the man behind the curtain is the analogy I normally use). The problem is that I have tons of practice doing console, but when I ran into problems with not knowing what to do I got advice like: "Make a simple basic game engine." Then when I ran into a problem I was told "Make the game not the engine." Which made me so I had no clue where to start, they actually made me feel like I was some new guy who just started again. Then of course I got the "If you are stuck, learn this language and it will help." I've been told to learn Assembler, Perl, Python, Scheme, Lisp, Prologic, D, Java, C#, C, PHP, ASP, and numerous others instead of working out the problem in C++. I've also been told about using the brain cloud method and UML on numerous occasions.

I also have trouble thinking of things to program because of not knowing the limitations of what C++ can do and such. I'm over ambitious and normally overwhelm myself with some projects. I have C++ Programming From Problem Analysis to Program Design 3rd Edition by D.S. Malik and I've read it through and done the in chapter examples, need to do the exercises too though. The other advice I get is "Read <book>." and "Don't read, just do." The one piece of advice I got that made me feel stupid was "Join with someone on a project and do the Lua scripting or something small and easy." when I don't know anything besides C++ (which as a beginner made me too nervous to even attempt due to my lack of experience). Though when I told them I was too nervous to try all I got was put downs and ridicule so much so that this is the first time I've asked for any advice in two years since finishing my degree.

Originally Posted by VirtualAce

That being said there are several design patterns and approaches to game development that can aid you in creating a game. Since you have had the classes and learning I highly recommend you either buy a 3rd party engine and start from there or use an open source one. Torque Pro by Garage Games is extremely cost effective right now and comes with a good tool set to get started. Unity3D is another 'engine' that is decent if not a bit limited due to their C# scripting approach and 'everything by the editor, for the editor, and in the editor' approach.

This is a very good piece of advice.

Using an existing, well documented and widely used and supported game engine will allow you to go from nothing to something tangible very quickly. It's GREAT to have something to show off! More importantly, you'll be off the ground and making playable games -- it won't be next Deus Ex, but it'll be YOURS. That, like nothing else, will inspire you to learn, improve and iterate on your designs. Motivation >9000!

You mentioned that you would ultimately like to work on the game engines -- writing them yourself -- using an existing game engine is a great first step towards that. To write your own, you'll need an understanding about what actually goes into a game engine and what services it is expected to provide. Working with an existing one will let you study it and gain the necessary understanding to get you started on your own engine.

Furthermore, knowing how to work with a certain game engine opens up opportunities for collaboration or possibly employment. Skills with an existing technology are more likely to lead to either of the two then writing your own game engine.


This came out kind of long-ish. TL;DR: read the second paragraph.

What engines would be good ones to use and learn from? That is a question that has always been on the back of my mind. I know that there are tons out there, but in the same breath some will get me nowhere towards the goal I'm aiming for while others will absolutely help me towards that goal. When someone challenged me to make a basic, simple 2D game engine to make simple games with I took them up on it. Then when I asked how to begin on it I got this cryptic reply "Remember: Game Engine, not Engine Game." So I'm kind of done with them as they are always cryptic or run you down for not knowing. I have confidence problems thanks to them, I started out ambitious and after several years of trying with allegro and its community all I got was depression, less confidence, and a negative outlook. I'm trying to get back to where I was when I started (back in '97, sad that I've been trying for 14 years to still feel like a beginner in C++ and programming). I'm ready to move on, put Allegro behind me, and prove that I can do what I know I can in game programming.

I'm afraid that there's no definitive answer to that question, and it heavily depends on the type of game you want to make. Since you'll want to take an occasional look at the internals of an engine, you should probably discount any engine that doesn't provide its source code without you paying an insane licensing fee. That takes UDK off the line-up; only n-1 game engines left to choose from.

I think that Torque has a 30 day trail that you can try before buying a no-strings-attached license with source code access. Give the trail a go and see how far you can get in those 30 days. If it doesn't meet your expectations you can move on to another engine.

Originally Posted by BHXSpecter

What engines would be good ones to use and learn from?

While there is no 'best' engine, I'm very partial to Quake engines, specifically Darkplaces. Even though this is because I'm bias to said actual games, having done work on them, I can say first hand that there's a _lot_ to be learned from them.

Originally Posted by BHXSpecter

I'm trying to get back to where I was when I started (back in '97, sad that I've been trying for 14 years to still feel like a beginner in C++ and programming).

Either your just not cut out for it, or you've been doing something _terribly_ wrong! Take a breather and just program what you enjoy, cares of the world aside. It's a lot of fun, and you'll gain experience very fast (of course, the experience out there that there is to be had is practically infinite).

I think that Torque has a 30 day trail that you can try before buying a no-strings-attached license with source code access. Give the trail a go and see how far you can get in those 30 days. If it doesn't meet your expectations you can move on to another engine.

Well in regards to Torque I went to DeVry University for their GSP program and got my degree (lot of good that did). But thanks to them I do have the full versions of TGE and TGEA.

Either your just not cut out for it, or you've been doing something _terribly_ wrong!

Not me doing anything terribly wrong, just had terrible help for those 14 years. I was stuck learning everything on my own and anytime I asked a question I got an answer that was laced with a ton of geek vocabulary that I didn't understand. For example, I did a pong clone and a lightcycles clone, I pointed out I was having an issue with figuring out the collision and some one started telling me to do quad trees and went into a 5 minute thing about how great they are. Then the only college I had did C# for the beginner course and C++ for the advanced course then just threw you into the game oriented things (which they then proceeded to give you all the code and told how to edit the files, where you then just submitted a screenshot of the running modification). So I have been given a raw deal for the 14 years but never knew where to go for legit help so I feel like I'm a noob in every sense of the word.

Well in regards to Torque I went to DeVry University for their GSP program and got my degree (lot of good that did).

Why am I not surprised? DeVry really isn't anything more than a diploma factory.

...quad trees...

That is geek speek that you should know and love if you are serious about game programming.

A quad tree for collision detection is an interesting albeit flawed idea and certainly overkill for pong. For pong a simple impl of the separating axis theorem would do. As for learning it on your own take it from me that is not always a bad thing. I learned everything on my own at one time and eventually made a career out of it. The experience I gained while coding during my free time couple with the advice I received from members here made a huge difference at work. Experience is a huge plus in anything and although education is extremely important experience is equally so.

With Google and information pouring out of every nook and cranny on the web you should be able to turn the geek speek into something you understand. While quad trees might be more game oriented any type of data structure used in games should have been taught in a data structures class. Most courses cover binary trees, quad trees, oct trees, and more. If you need to brush up on your data structures then buy a book on them from Amazon. Since everything a software engineer does is related somehow to data I am of the opinion that every one in the field should have a good data stuctures book. It never hurts to brush up on data structures and it just might help your design later.

I'm gonna say that if you had taken a class or otherwise read a good book on software design (not languages, etc), it could help you out a lot. Having had that experience and practiced it, I would never dream of doing a large project again without complete requirements gathering, making a use case diagram, writing out detailed use case specifications, analysis class diagrams, and sequence diagrams. The first time I actually took these concepts I learned from class, taking the discipline to slow myself down and do the full and proper planning before I even touched the code, I couldn't BELIEVE how smooth coding went. I'm sure there are gurus out there who just open up their editor and start whipping out a massive program, but for me, I feel like you discover how to code it as you plan it. The real revelation for me is how if you start with this vague idea and start developing it in a uniform and disciplined fashion...it's like sculpting, the form suddenly starts to appear out of the lifeless rock.

I think those who knock UML, etc are right to do so, if you are a person who just whips open some UML software and think that some boxes and lines will suddenly make your idea into a project. They are just tools to apply good object orientated design, but you have to learn how to design before you can get any benefit from the tools. And of course, you have to practice. And the first time you try to do a full scale design, you should start with something small to get the hang of it...not try to create the masterpiece you've been dreaming about...BUT do something novel--no template or example to follow.

Everybody wants to work on "the engine." if you work on "the engine" you will be master of the universe, prayed to by millions of worshippers and get ALL the girls.

Reality is, most people are too stupid to create "the engine" because it needs abstract inspiration. That's what the comment "game engine, not engine game" means. The point is the game. The "engine" is just a means. Only a handful of people have the prescience to create a framework that will be truly useful to other people. If you want to write games, write games, not engines.

^^^
That's a good point. I think the word "stupid" is a big subjective. To a Nikola Tesla, everybody would seem stupid, but that's setting the bar pretty damn high. But what you say is pretty much the case for everything. It's like video/audio converters. If you look around you'll see all these different converters on the various platforms....handbrake, super, whatever. I used to think that each one one of these programs had their own optimized implementation of some function that actually took the digital data and converted it to the other format. The truth is, all of those programs simply serve as a wrapper around popular conversion engines like mencoder, etc. While that might seem to trivialize the accomplishment of said programs, there is no doubt that certain programs take better advantage of these "engines" than others, and make the user's conversion experience easier (handbrake, ftw). So, while the genius innovators may provide the foundation that all of us use, a damn good use of that innovation is nothing to look down your nose at.

Originally Posted by wildcard_seven

To a Nikola Tesla, everybody would seem stupid [...] So, while the genius innovators may provide the foundation that all of us use, a damn good use of that innovation is nothing to look down your nose at.

I think you are over-emphasizing the significance of "the lone genius" and missing the fact that regardless of who does what well, this is a simple necessity. Lets say I'm interested in writing a game, do I sit down and:

- design and implement an operating system
- design and implement a 3D graphics library for the OS
- design and implement a game engine for the graphics library

That is a hierarchy, and at first glance, you would probably want more skilled and experienced people to do the OS than the graphics library, because if the OS doesn't work right, the graphics lib doesn't stand a chance. However, it may be true that the graphics lib is the most complex item in the pile, so demands the most skill. But that is still more abstract than looking at what particular knowledge and experience are applicable to a particular task. So programmer A may have a higher IQ than programmer B, and more years of experience, but if programmer B possesses significantly more knowledge in a particular context (say, regarding hardware interfacing for the graphics lib) programmer B is probably better suited to the task.

In any case, I don't think anyone is going to go for a modular stack where every component was done by the same person, even if that person was Tesla. Point being: you can't do it all yourself. Choosing a niche you want to focus on should not be about a totem pole model, where some tasks are more prestigious than others. Someone could create a great game with a crap engine, if they were so inclined. Do you then look at the game and say, "Nice job, I guess the guy who did the engine must have been even more awesome." Bah.

Originally Posted by brewbuck

Reality is, most people are too stupid to create "the engine" because it needs abstract inspiration.

I'd take that to mean that most people who want to create an engine don't really understand what they are getting into, don't appreciate what is involved, and are perhaps not that interested in becoming so. They want to create a game -- a very concrete (as opposed to "abstract") application.

OTOH, maybe brewbuck has gone over my head again