Jump to content
  • entries
    437
  • comments
    1000
  • views
    337166

Admissions

Sign in to follow this  
evolutional

179 views

Engines, Games and Automobiles

Remember my old thread about Engines and hobbyist game programmers? In some ways, I'm still stuck in the same trap. I know I've been busy on an ASP project for months and my current C++ tinkerings are with scripting environments and garbage collection but what's happening with my game projects?

  • Manta-X is left in some semi-transient state between me ripping out the scene graph and replacing it with some scene-graph message propagation hybrid.
  • jsInvaders is pending a cross-platform rewrite; I want to break it from Win32 and put it in SDL before the next article gets written.
  • ZSI is less of a game and more of me messing around with pixel art; but I have some ideas I'd like to build in and make a game out of.

    So, why the rewriting? If you recall Manta-X is in it's 4th or 5th rewrite. Why's it been rewritten so much you may ask! The main reason is that I've coded the game 'engine' myself. The first 3 versions were me playing Carmack and trying to come up with some all-purpose engine that I could adapt to make my simple space shooter. I armed myself with a C++ compiler and a printout of the Enginuity series and thought I knew it all. I'd read this, that and the other and thought I knew my way around C++ well enough to make my engine. "Once that was done", I'd decided, "I'll make my game!". Hah, well let's just say it never got done.

    Making an engine is not making a game. Unless you know your stuff, you will always get back to a point where you realise that you can't code your desired game feature because of some flaw in your engine. You go back and patch the engine to cope with your new feature and go from there. But your patch takes a long time to add in and doesn't really get implemented as well as you'd hoped because it's a rejig of some core feature and you were in a hurry. So the flimsy implementation of your patch then
    causes bugs to appear later down the line which you go back and tie together with some more code. Before you know it you've done this 7 or 8 times and have spaghettified your engine code with your game code running in some unstable fashion on top.

    So you've got your engine 'working' and go to work on your game code some more. You get to the stage that you'll need some cool levels and content for your game and realise that your custom engine dataformats that you thought were cool six months ago don't quite cut it anymore. You started out with some abstract idea when you implemented them and didn't have any real-world grounding in there. So you go back and recode them to something more practical - but it's sad to see that cool code go to waste. Then wait, you've got to create the tools to make your levels - you can't really pick up anything that's out there already because the formats are different. Plus you think that you've coded the engine, you can code the tools too...

    A few weeks later you realise that making tools is shitty work and you've just spent a few months on some rudimentary toolset that works, but not quite the way you wanted it to. So when you wind up with a bit of content you realise that the failure to plan your game has resulted in some rewrites of the game engine logic to make it work as it should. You had plenty of cool models flying around with multiple textures and nice lighting, but when it comes to setting up real level structures and controlling the updates of the game objects you're in trouble. So you go back and start rewriting that section of the game code; but the changes you make are fairly big and the code doesn't compile any more. What's worse, the spaghettified code you thought would be ok requires these changes to be replciated system wide - except now you've got a few dozen files and a few hundred thousand lines of code to work with.

    The game dies shortly after that when you realise you'd be better off starting again, this time with a 'plan'.

    Sound familiar? It's probably you; I know it's been me many times in the past.

    So what do you do? Let's face it this is not 1985 anymore; it's hard work for people to throw out a decent game in a year, let alone a few months how it was back then. Many of us insist of working alone, so if you do - we should do all we can to take the burden off ourselves. If you have a team of ten with design document and a few years of coding time go make your new engine and impress the world... If you're on your own in your bedroom, stay the hell away from making Engines if you intend to make a real game out of it. Trust me on this, you are either doing one or the other; very few of us can claim to have done both (and if you have, I both envy and respect you).



    Third Party

    Middleware is a term that's fairly ambigous but I think we should be getting used to it. What we're all guilty of is going back and reinventing the same wheel over and over and over and over. It's like me not believing in gravity so going out and poving it every time I experience it's effects. We're supposed to be advancing this science, advancing the game creation field, not bloody stagnating it with half-assed engines and square wheels. We should be taking some basecode and adding to it, not throwing it out and remaking it from scratch. Countless others have slaved away at the same problems, why should the rest of us be so stupid, effectively sticking our fingers up at their work and making it ourselves.

    So back to me. I've realised where I want to go, I want to make games like I used to do back on the Amiga. I'm taking my own advice. Screw making my nice generic scenegraph message passing hybrid. I'm going to pick up some technology and work with it. I'm used to using third party libraries such as SDL and scripting languages, but that's simply not enough. I want to make a game, I want to do it in C++ so I'm going to use a third party Engine. I've been looking around and Irrlicht has the stuff I'll need, perhaps not the way I'd do it but sod it - I'm going to throw something at it see what I get out. I'm afraid I'm going to have to bend my arrogant 'do it myself' bones and accept that the world of development can't always be the way I want it. I'm going to have to put up with someone else's basecode and build from there; even if I have to fight the interface I'll stick to it. So my project might fail - big deal, I bet that I get a damn sight further than I have before.



    Changes

    Coming to this conclusion has been a long path. I've stepped down gradually; in the past I tried it all myself, then I stepped down and let SDL do some of the work - well now I'm going to trust Irrlicht to do more of the work. A catalyst for this change is down to my recent promotion at work. I am now a developer on a fairly large, important database project that's critical to the company. They have an existing basecode that is in constant development; it's impossible for me to impose any of my will on this code. Sure, I can make changes here and there to the functionality, but the actual core is not going to change, even if I disagree with how it's done. I'm sorry people, but that's the way it is these days. I think the same should also apply to game projects. If you're an indie working on your own it's very easy to do what you want, when you want with no discipline to stop you. I really do feel that we're in for a hard think, we're facing the wrong way - let's make games and not engines! We can realise game ideas that large publishers have no hope in creating; why the hell do we end up losing those dreams in the middle of a failed engine project?



    Education

    I feel very strongly about this now, as you may be able to tell. In some ways, I feel as if the current teaching resources are to blame. All the books and articles flying around about game development teaches you how to start from the ground up - where are the books and articles on taking an existing game engine and building a real-world game on it? I don't mean a tech demo, I mean a real-life, functioning game that you can pass to your friends to play with.

    If you've written a game on Irrlict, Crystalspace, OGRE, Quake2, or [whatever] engine, I urge you to sit down and start thinking about how you can impart this knowledge onto other people. I'd love to see a 10 part series that focuses on picking up an engine and making a real game from it. Where are they? You don't see anything like that anywhere. If you can do it, write an article or two! If you do, I can hold my hand up and say that your name will be remembered by others. You will be the people that picked up the torch and carried it to the next runner. Let's inspire the next generation, let's stop them from making the same mistakes we've made for years...

    I do acknowledge that some people should be making engines for us all to use, it's part of the deal. But people asking where to start, why do we point them at a C++ compiler and a direct X SDK? Why not at some Irrlicht tutorials? It'd be neat to point a beginner to an all-in-one 'make a game' tutorial that uses a common third party engine. It's something that's hard to do right now. Don't believe me? Read here and tell me it wouldn't help the guy. If you still don't believe me, listen to John Hattan and Washu. I'm not the only one thinking along similar lines (although I'm probably hitting the bone without as much tact).

    I've noticed that most of our forum topic activity is cyclic in nature; we have people asking where to start all the time, people asking what to do next and then people just vanishing with little or nothing to show from their efforts. It's obvious that people are helping out on the same questions over and over because the problems aren't really changing. Hardware is advancing but people are still bickering about C vs C++, C++ vs BASIC, DX vs OGL, etc.

    This tells me that we're perhaps in a rut as indie game developers. Sure, some of us will make advances, make great games, great engines and so forth (WhiteSpace's "StickSoldiers", RectorInteractive's "Sector 13", Raduprv's "Eternal Lands" and EDI's "Morning's Wrath" spring to mind). We're indies, we have the world at our fingertips - I can't help think that we should be doing more. Why start at the same bases? Let's learn a lesson and step up and help each generation in turn make that further step. Let's rekindle the old spirit of the 1980's/early 1990's.

    I really hope you understand my meaning here. I'm going to be following it from here on.

    Fixed journal links, thanks John
  • Sign in to follow this  


    11 Comments


    Recommended Comments

    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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.

    Share this comment


    Link to comment
    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*

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!