The journal links don't work unless you click on the "comments" link to show the journal entry with comments. I think the main journal pages are temporary and are thrown out often.

WOW The evolution of evolutional [smile]

This seems to be the trend. I guess it seems like a good idea, and I must confess that one of the reasons I make games with my own source is the lack of good tutorials for existing engines.

That being said, one of the reasons that I do make games with my own source is because I can. I have dedication, time, money, and patience. I'm not in a hurry to get noticed or start a movement either. If you want to be noticed, or just complete a game, I'd say get yourself a free engine and make a game - it will save you so much time and stress.

At the same time, how many hobbyists actually care about the completed project? Being a hobbyist, you aren't in it for the money, but for the love of design and the passion of creation (be it drawing, programming, modeling, music...whatever). I personally don't care if my game is ever complete: I work on it because I enjoy working on it...not because I want it to be over. If I wanted it to be over, I wouldn't be trying something so out of my league.

At the same time: mods are terribly fun. I tried my hand at some QuakeC a while back and had a hoot of a time. It was awesome to see my dog-launcher immediately appear, instead of having to fool with some hog-wash sprite and model shinanigans.

I suppose for those who only care about the end product, then prefabricated engines are the way to go...but many of us like the journey.

Excellent entry, by the way.

Great post evolutional, I totally agree with everything you mentioned :)

I was a victim of the do it my way syndrome as well and always wanted to roll my own solution to a problem. I've learned over the last few months that it just can't go that way, like it or not, and you'll never finish a thing if you keep re-writing. I mean I look at how at work we are constantly looking to leverage pre-existing code and middleware and I see how far ahead the project really gets... things get done... amazingly fast.

For my current project I have decided on using an existing rendering and animation system, and I'm using some base code from my other projects as well. Middleware and existing code libraries solve many of the issues game development faces today.. and not only on an indie level.

The problem is, if you point the newbies at Irrlicht tutorials, who's going to code the next Irrlicht? Besides, I don't think using an engine like that gets you out of having to understand pointers and memory management and the like.

I think we're in danger of assuming the existing tools are fine and forcing them upon the newbies, when actually they're pretty crap most of the time, and it takes someone with a bit of home-grown engine coding experience to spot the difference! On top of that, the main problems tend to stem from the language, not the libraries that are (not) used.

Quote:The problem is, if you point the newbies at Irrlicht tutorials, who's going to code the next Irrlicht?

Believe me, this thought was in my mind the whole time writing that post. I'm not saying this route is for everyone, but I am starting to believe that it should be the next step up on the learning ladder from learning your basic language features.

At present, I feel as if we're pushing newbies down our interest paths, not down the paths they should really be taking. I'm as interested as the next man in low-level programming of memory management systems; in fact one of my current toy projects is a garbage collector and a memory pooling system.

Quote:Besides, I don't think using an engine like that gets you out of having to understand pointers and memory management and the like.

The way I see it is that people should get to grips with the basic features of a language, then take on an existing engine and make some games with it. By doing this, they will have created a couple of real games (more advanced than pong/tetris) and will start to appreciate the limitations of their chosen engine. From here, they will more likely be interested in coding at a lower level, perhaps choosing to first modify their existing engine and then going into things at a lower level and creating their own. It is then that the next Irrlichts will be forged, more likely as an evolution of the existing technology than a revoltion.

Quote:I think we're in danger of assuming the existing tools are fine and forcing them upon the newbies, when actually they're pretty crap most of the time, and it takes someone with a bit of home-grown engine coding experience to spot the difference!

Many people creating engines (including myself) seem to have little or no experience of using an existing solution and as such, will have no real appreciation of why they're doing things in a particular way. We are effectiveley reinventing a wheel without knowing what a wheel is. An engine is a large project, especially when a game is also planned on top of this. Jumping from homebrew tetris to a fully customised engine and a game is a leap that far too many people seem to be making. It's also suicidal in terms of workload. Whilst the tools may be 'crap', it'll be a lot easier for people to appreciate why they are crap if they've used them. It's pretty dangerous to tell people that something is crap without giving them the chance to discover the reasons themselves. Besides, what's crap to one person might be adequate for another.

What I'm proposing is that our generation of Indies should be actively laying the groundwork for the next to work from. If you have your engine created, release it to the public - write some tutorials on using it and let's help others start at a higher level.

The learning cycle now seems to be:

Learn C/C++ basics

Write a tetris/pong clone

Try and tackle a 3D API, resulting in a couple of tech demos

Decide to code an engine for a much larger game project

Work on the engine, scrap the engine, work on the engine, etc

The way I think it should be is (assuming we start from the same base)

Learn C/C++ basics

Create a game using existing engine technology

Create another game using more advanced features of the technology

Realise limitations of existing technology and look at other options (which includes trying a new engine, enhancing the engine or making your own)

Rather than go from bottom up, we should be teaching people to go from top down. Sure, the approach won't suit everyone, but I believe it would help out a lot more people.

I tend to agree that there's an odd focus and general bigotry (although that's too strong a word) against middleware. But it's certainly softening. A good example would be gamedev's own "Four Element" contests. A hard rule several years ago was "no game engines or scene-graph libraries". You couldn't even use Direct3D retained-mode because it was considered to be too high level.

The resistance to things like engines or authoring tools or scene-graph libraries is getting less pronounced than before. I think it was you who commented in my journal that using a high level language or authoring system isn't being a "pussy", but it's being efficient.

On that note, Gamedev's got a new big contest in the works, and they're removing all "you must write native code to the bare 3D API" limitations. If you can write a clever game in Flash or BlitzBasic, then you've got a shot at winning the contest.

I think the fact that the IGF audience award went to a Java game in 2004 and a Flash game in 2005 shows that people are focused more on good design than coding things "the best way" nowadays.

I've actually been grappling with this issue myself lately. I'm not sure I totally agree with your assessment, but I MOSTLY agree =)

The thing I would quibble about are these:
1) (ok, this is a quibble with another commenter, since you seem to agree with me here) - I don't think there will ever be a lack of people making engines. As has been said, many people enjoy the journey more than the destination. Most people, for example, don't have a clue how to make a TV. But that doesn't stop people from making TV shows. It also doesn't stop the advancement of the science of making better TV's.

The evolution of technology has always been a story of evolution and revolution. Every once in a while, a revolution happens and something new comes along. Many take up the idea, evolve it and refine it. Eventually, the technology reaches a plateau of maturity and usefulness. Then, a new revolution comes along where the pain of learning a new way is beneficial enough to scrap the investment in the old technology. Sometimes, if a technology stays mature long enough or a broad enough foundation exists that isn't changed too much by new revolutions, then the field becomes broad enough to support people branching into basic research and applications. It becomes much rarer for people to be good at both basic research on a technology and applying it. There's too much to know, too much to do in that field.

I think game programming has reached that latter type of plateau. There's still a need for engine programmers and improvements to the underlying foundational technology. But there's enough of a base now that it's ok to have people being good at just USING the game engines to make games.

The drawback, of course, is the same drawback I see in many new college grads we interview - if you don't understand at the least the priniciples of the underlying technology, you can't use it effectively. Many college grads we interview have only the vaguest notion of memory management, pointers, or what happens under the covers when they do a "new BIGObject" inside a million-iteration for loop (even in Java). They don't understand the underlying principles of programming enough to avoid the major performance problems or to understand why one algorithm is better than another.

2) So, what we have is an interesting situation where the best way to become good at game programming these days is to maybe follow these steps:

• Learn C/C++ basics
  
• Create a small game start-to-finish with limited, pre-defined features that maximize education about how a basic engine architecture works and brings out the fundamental problems that engine designers face. The emphasis here is actually on engine design, not game programming.
  
• Armed with the knowledge of how an engine should work and what it's doing under the covers (mainly because you realize your own engine sucks), you search for an existing engine you like and then create the same game using that engine.
  
• With all the spare time that programming the game again leaves you (since you probably did it in about 1/100th of the time), you can then explore the more advanced technology in the engine and add features to your game.
  
• Start creating real games.
  

The point is that I think it's actually important still to make an attempt at creating a basic game engine architecture because I think a new game programmer needs the education. The trick is confine the time taken to something reasonable and to have very constrained pre-defined engine/game goals. Don't get caught in the typical programmer quagmire of "adding just one more little feature that'll make it soooo cool!"

Hmmm, I'll stop filling your comment log now. I think I have more to say on this, but I'll make it into a journal entry of my own soon.

I agree with that assessment completely. There is definitely a market in books and tutorials focusing on the nuances of creating your own Engines, one that starts you off with a language and also one that starts your basic game programming in that language. It does seem that the market has a gap in the tutition of using existing technology. Is this gap real, do you think, or just imagined? If it is a real gap, surely we should start thinking about how to fill it.

Evolutional:

I don't think we're pushing newbies in the wrong direction, although it's possible that we're failing to make it clear that there are different options available to them. When someone asks a question here, I think there are 3 categories they fall into:

a) They want to know how to make games
b) They want to get a job making games
c) They already make games and have a specific problem

The people in category C are ok here. The people in category B are also fine, and need to be pointed at C++ because - except in a few border cases - to do anything else is a disservice to them. You don't get hired for your l33t BlitzBasic skills. Where we perhaps let people down is category A, by directing them at a C++ compiler when there are many alternatives.

"people should get to grips with the basic features of a language, then take on an existing engine and make some games with it" - This makes sense but the problem is that 'basic features' are very tricky. As an example, Irrlicht is packed with pointers, namespaces, templates, factory methods, etc. And that's just the 'short example' they give! You may be giving them a lot of functionality by pointing them at a pre-made engine but they're ill-equipped to use it. There's no getting around the fact that they really need to 'pay their dues' by writing some software of their own first to get used to the process.

"Many people creating engines (including myself) seem to have little or no experience of using an existing solution and as such, will have no real appreciation of why they're doing things in a particular way."

I think you're looking at it the wrong way around; these engines/libraries are often built to deliberately hide a lot of the information that is important to an implementor. When looking at other libraries I don't learn anything about why to do things in a certain way, only arguably better ways to present an interface. You don't know the assumptions they were working under when they decided to create it the way that they did.

I think you learn more from setting your own specifications, attempting a solution, then comparing that with others.


Devnull:

"Most people, for example, don't have a clue how to make a TV. But that doesn't stop people from making TV shows. It also doesn't stop the advancement of the science of making better TV's."

That's a poor analogy because the act of making a tv show and making a tv are very different. On the other hand developing a computer game and developing a computer game engine use probably 90% of the same skills. (I am excluding artists, musicians, and designers from this because I don't think they are the focus of the discussion.) If you're developing a game using an existing engine you're still gonna be writing loops and functions, modifying variables, allocating and deallocating resources, etc.

"Many college grads we interview have only the vaguest notion of memory management"

Exactly. Personally I think Java is a horrible language to teach because it occupies an awful middle ground between C++ and the higher level languages. I'd be much happier if they taught basic program construction with Python (or Basic, or something else fairly simple) and taught C/C++ in addition so that you get a good grasp of low level concepts.

"The point is that I think it's actually important still to make an attempt at creating a basic game engine architecture because I think a new game programmer needs the education."

We definitely agree here. I think using existing technology is important - hence my free libraries list - but you need to make an attempt of your own first to really appreciate what is required of you.

Quote:It does seem that the market has a gap in the tutition of using existing technology. Is this gap real, do you think, or just imagined? If it is a real gap, surely we should start thinking about how to fill it

Yup, I do think there's a gap here waiting to be filled. In the last 4-5 years, there's been a huge number of useful game [engine] programming books. I'm hoping that soon we'll start seeing lots of good books about programming with specific engines. Most engines have tutorials and documentation to some degree, but they almost always seem like an afterthought.

I know that I, for one, would definitely buy books on programming Ogre, Irrlicht, Torque TSE, etc. especially if they took a basic game concept and used the engine to make it from start to finish. If I had the means available to buy a higher-end engine like Rednerware, etc, I'd love a book like that for it too.

I might even consider writing a book like that except that authors get paid like crap and I couldn't afford the time to write the book. *sigh*

this is lovely myscouting