Game Engine Development

Discussion in 'Game Development (Technical)' started by ProgrammingFreak, Apr 15, 2006.

  1. ProgrammingFreak

    Original Member

    Joined:
    Oct 22, 2005
    Messages:
    126
    Likes Received:
    0
    I am planning on developing a Game Engine. I know I should use C/C++. However I am wondering what portions would be good to write ASM code in.
     
  2. gmcbay

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    280
    Likes Received:
    0
    None of them.
     
  3. impossible

    Original Member

    Joined:
    Aug 9, 2004
    Messages:
    443
    Likes Received:
    0
    Or all of them if you're a masochist :). Depends on what type of game you're making and what platform. Even the highest end 3D games only really use assembly for SIMD math libraries.

    Because of the quality of compilers and the nature of processors, you'll rarely be able to write asm that's better than what the compiler generates, and even then its just not worth it.

    From what I understand you're a beginning programmer? You'll have enough trouble with C\C++, don't worry about asm. Its good to learn some things about it for educational purposes, but you won't be using it in a game.
     
  4. svero

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    3,392
    Likes Received:
    6
    It's crazy to write a game engine nowdays unless it's just for fun and learning. There's enough good free and commerical ones out there. Best to just use one of those. Popcap Engine, PTK, Torque 2d/3d, etc....
     
  5. Coyote

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    697
    Likes Received:
    0
    Writing a 3D engine is a great learning experience - but understand you are making a 3D engine, and not a game. If only I knew at the beginning of Void War's development what I know now :)

    Anyway - the days of doing certain parts of the engine in Assembly are pretty much long gone. Even John Carmack has commented that the tiny bits of optimized assembly he wrote for the Quake 3 engine are pretty much useless and sub-optimal today.

    I'd recommend C++ if you are going to do it, though.

    The 3D engines out today have MANY man-years devoted to their creation. How are you going to compete with that? What will your 3D engine offer that none of the others do? What advantages will it give you? Besides working on the lower-level to make pretty polygons appear on the screen, are you prepared to handle all the other crap that you have to do with a 3D engine? Like support importers from popular modeling formats so that people can actually get models into your game? Texture caching? There's a ton of grunt-work involved in making a 3D engine.

    It used to be easier to answer these questions. Back in the day (when I got started), it was actually easier to put together your own 3D engine than to spend the time and effort learning to use someone else's engine. But times have changed, and 3D engines have become MUCH more involved and feature-rich. Unless you have a very specific reason (such as "I want to learn how to do it"), I'd steer clear.
     
  6. Sharpfish

    Original Member

    Joined:
    Feb 25, 2005
    Messages:
    1,309
    Likes Received:
    0
    I didn't see him say he was:

    .Making a 3D game engine
    .Planning on selling it or allowing others to use it

    So some clarity on his plans would be good! :)

    If he is bringing together a small 2D engine it's perfectly possible to do that and use some "test games" to help advance and polish it. As Steve says though, it is pointless if he is just going to make typical 2D games that could be done with Blitz, Popcap, PTk etc. If he wants to make a bespoke engine for learning and full control over it's direction then I think he could easily piggyback his API of choice and make a decent one (D3D, OGL). It may take 6 months or a year to be fully featured and robust. If you are a newcommer to the language you are using as well (C++) and the API (OGL/DX) you can factor in upto another year at least. (of course people can learn faster or slower).

    If you are talking 3D, be aware that the actual 3D engine and the Game engine are two different things. The 3D part is probably going to be an abstracted rendering engine and the game engine will wrap a lot of that functionality into easy to reuse library calls. I made "half" a 3D engine with C++ and D3D as the api. Start with simple rendering, put in scenegraphs and scene nodes, material handling, .X file import isnt too hard but you could end up using D3DX functions for that which may not be ideal (relying on d3dx is not a sure thing). Then layer on the effects like particle classes, stencil buffer usage (reflections, shadows etc). I wouldn't personally bother with shaders for the target audience I have in mind, purely fixed function pipeline.

    Anyway, I spent 6 months on the intial "rough" engine getting all the simple things working (I had no previous experience with that kind of stuff so lots of learning time). Then another 6 months implementing features. It was never fully robust and a lot of time was lost. I felt "good" that I had learned more about the process and the tech behind it - which enables me to customise any future code of it's type, but in all honesty the time would have been better spent using an availble engine and concentrating on the games.
     
  7. gmcbay

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    280
    Likes Received:
    0
    From a pure business standpoint, I agree with everyone who recommends not making your own engine. I think virtually all of us fall into this NIH trap when we first get started, wasting months if not years of time. Using someone else's engine is superior because:

    a) it already works
    b) it is likely already field tested on many types of hardware
    c) it will be maintained in the background, with little to no effort on your part.

    However, assuming you do want to write your own engine, either because you really need to for the game you're creating or because you want to offer the engine to others, or you just need to learn the "buy don't build" lesson for yourself, there's really absolutely no need for any assembly. The world has moved on since the 90s and there are very few situations in which hand optimized assembly actually helps at all (with the previously noted exception of SIMD assembly for math and vector operations, and even these are pretty well optimized if compiled from C++ by a vectorizing-aware compiler, like the one in Visual Studio 2005).

    The downsides are many -- not only is assembly a pain to maintain, but you run into tons of portability issues if you decide to support another OS, or move the code to 64 bit, etc.

    If you're really set on using assembly just for the fun of it or as a learning experience, this is something you could probably find people to discuss with you on www.gamedev.net. On these forums there tends to be more of a hard business/practicality slant, but on that site and others like it there are plenty of people who do still use assembly just for fun or learning or whatever other reasons. Personally I did a lot of assembly programming back on the C64 and Commodore Amiga and had a lot of fun with it, but now that I'm older and have less time to waste, I'm glad the world has moved on and it isn't really needed anymore. YMMV.
     
  8. Huge

    Original Member

    Joined:
    Sep 22, 2005
    Messages:
    142
    Likes Received:
    0
    To work out what to optimise, first profile.
    To profile, first write your engine.
    To write your engine, first write your first line of code.
    So you have a while to go before thinking about asm.

    You will find the design/algorithm opimisations could achieve several 100 percent performance improvements, while asm could give you, at most, say 10%.
     
  9. ggambett

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,982
    Likes Received:
    6
    None, unless you're writing system memory surface-to-surface blitters yourself.
     
  10. vjvj

    Indie Author

    Joined:
    Sep 25, 2004
    Messages:
    1,732
    Likes Received:
    0
    NONE.

    Finish your engine and then profile it.
     
  11. C.S.Brewer

    Original Member

    Joined:
    Aug 20, 2004
    Messages:
    102
    Likes Received:
    0
    doing it for need, I think it's clear the consensus is none of it!

    doing it for fun, do as much as you can :)
     
  12. Emmanuel

    Moderator Original Member

    Joined:
    Nov 23, 2004
    Messages:
    859
    Likes Received:
    0
    Nowadays it's a pretty safe bet to make D3D/OpenGL accelerated 2D games which are almost 100% graphics card bound; so the previous posters are right: probably no assembly unless you're doing software rendering and want to move surfaces in memory by hand. For Mystic Inn I modified a tiny fraction of ptk to use vertex buffers (both on Windows and the upcoming Mac version) and that yield a 500% increase in how much we could put on the screen (now we're limited by the fill rate of the lowest common determinator cards).. Still no assembly code was used. :)

    Best regards,
    Emmanuel
     
  13. ProgrammingFreak

    Original Member

    Joined:
    Oct 22, 2005
    Messages:
    126
    Likes Received:
    0
    Ok Thanks, now I have a better understanding
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer