Hi everyone. I''m looking for some sort of log or diary or documentary about what goes on when a group of people plan an engine out. I''m talking about the technology related side of things, as opposed to the game design side. I''ve looked at a bunch of .plan files (including id''s), and while they do offer a lot of info on how projects are procceding, and why they''ve decided what they''ve decided, they don''t go too much into details. To be more specific, the sort of stuff I''m looking for are: - How much do they really do flesh out an engine design. - Is it all in their heads, on a black board. - Does everyone contribute, or just a few people. - How do they coordinate the different technologies developed by different people. - Any special design software (flow charts, etc). - Aprox. percentage of time they spend planning as opposed to coding and debugging. - How much special "research" goes into it... do they make little private mini demos and such for each special feature, or do they just plan it into the big engine outright. I know Carmack does a lot of this-- is this pretty much standard? - Anything else about the tech side pre-production. I know that''s a heap of stuff. It probably silly to a lot of the people here. But I tend to get disorganized very quickly so I wanted to know how companies and people stay on track. I''ve read some tutorials like Code on the Cob and such, that give a sort of hint at this, but still very vague. Also, for some reason, I find reading about stuff like this inspiring. Any pointers to very detailed .plans, diaries, docs, even videos, on the subject of game engine design, would be wonderful. Thanks for reading through all this. SH

This is damn good thread so anyone with info better post, or SH and I will come to your house and kick your ass.

quote: Original post by Orpheum

This is damn good thread so anyone with info better post, or SH and I will come to your house and kick your ass.

Thanks, Orpheum-- you get all kinds of support in these forums!

well I can''t real point you to any docs and what not on this but I can say a little about how I do things... I think it will help you out because from the sounds of it your exactly like me... you start something then somewhere in the middle of it you loss intrest or things get ungodly to handle or what ever...

ummm how I plan something out depends on how big of a project I''m talking about... something simple like say a tetris clone or a little help util I think about it for a few days figure out exacly what I need and what not then I just go strait into developing it...

if its something large like say... an RPG or like my current project... I do a lot of planing...for a few weeks or so I just think about it... I get a good idea on how to do something I write a little note down somewhere... then when I''ve got a good amount figured out in my head I organize things... I start by listing everything I want to do on one peace of paper(paper on in MS Notepad or something)... then for each feature I pull out another peace of paper and write down an abstract discription of it... after I''ve got all the abstracts done I figure out how each peace needs to fit togeather.... then I start writing out the declerations of each function/class/whatever... then with some functions(the complex ones) I write some pesudo code for it... I run through in my head trying to figure out how each functions call each other... make shure all paramiters are there and what not... then after I''ve thought my self to death on everthing I start coding... then if I notice that something isn''t working out the way I need it to I go back to my designe docs and figure out how to make them work... while I''m programming if I come acrossed something I don''t quite know how to do... I write a little demo program and figure things out in that... then I rewrite(not cut and past) the code in the main project...



Great Milenko

Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."

http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech

- How much do they really do flesh out an engine design.

This is a good idea. Most people I''ve heard about have to redesign a few times to get this right. Have a look around for things called Scene Graphs, they are kind of generic ways of building an engine. At the very least have a look at their class structure.


- Is it all in their heads, on a black board.

I tend to keep details in my head and large structure as a soft copy. More specifically I use visual studio and lay out the files \ folders first, then lay out some high level classes.

- Does everyone contribute, or just a few people.

I once worked on a mod. If failed because everyone didn''t contribute, we had all the maps\art\models\textures\sounds done but our coders were flakes. (One of the reasosn I learnt to code)

- How do they coordinate the different technologies developed by different people.

Firstly get the coder together(or on an IRC channel if remote) and talk about standards. Once everyone is comfortable go off and select a style guide that sort of loosly fits with everyone in the team. Edit the document if necessary. Let everyone know that everyone else will be making personal style sarifices as well. This _REALLY_ should be adhered to.

Get the artists together and select a common tool for each task, or at the very least common file formats. Say textures should be tga, sounds as wav etc. File formats should NOT include any kind of lossy compression except for releases(always keeping the originals). If fine for some artists to use 3D MAX and others Blender, so long as you share a common file format amongst the team.

- Any special design software (flow charts, etc).

I tended to make bullet points. I used email as the medium(we were all remote) as it allowed lazy evaluation by all team members. You can miss a lot on IRC.

- Aprox. percentage of time they spend planning as opposed to
coding and debugging.

Depends on how serious you are and what your goals are.

- How much special "research" goes into it... do they make little private mini demos and such for each special feature, or do they just plan it into the big engine outright. I know Carmack does a lot of this-- is this pretty much standard?

I do a LOT. In fact I do it with each peice of technology I use. I create things like object loaders(3ds,opengl), simple chat programs(winsock), etc, etc... Anything that is non trivial you should try in isolation. Look at things like GLUT to help you along (if your using opengl). Having an isolated testbed for trying stuff out is a good idea so you can keep bits of code from messing each other up. These minidemo''s (IMHO) are never used in the main game. Initially I tried to make the new mini demo use a class that will eventially be rolled in to the main app, when doing this I ended up not doing r&D but full development. Doing this take much more time to R&D something. The experience you gain in doing the R&D will make you better design stuff for the main app anyway.

- Anything else about the tech side pre-production.

Come up with a document that specifies what your goals are. When someone suggest a good idea that everyone agree''s to add it to the list. Then, only items on the list should be worked on. Drill it in to everyones heads, "not on list, no effort". You have to keep focused during the bulk work part of the project. Remember is better to have produced something that isn''t perfect than never finishing the project because you keep tripping yourself over with cool new features and useless R&D. Most game failure are due to an unfocused development team.



One last cool tip. Every once in a while when you in the mood or are technically stuck on something sit back and imagine actually playing the game, imagine the graphics for shooting enemies the physics on how your player will move. Not only will it keep you motivated but you might think of other things that need to be done that from a coding perspective you might have missed.

HTH

gimp

Hi. Thanks, everyone, for replying.

Great Milenko, you said that, after creating abstract descriptions of the functionalities you''ll need, you go onto create function headers, and to piece together what calls what. A huge problem that I have with abstraction is that their is always some critical thing they need that I miss if I''m too abstract. For instance, a mesh object would have a "load()" function, which seems logical engouh for me-- until I rember that I need to hook that mesh up with some pre-loaded textures. Do you have any advice on how abstract you should be in general? It always seems to be the simple things that trip you up... It sounds like a great strategy you''ve come up with.

Gimp, using DevStudio to create a sort of template for the project is a great idea. I was sort of leary of trying it because it felt like I was leaving a lot of holes, but it does make a lot of sense. Making a testbed is another great idea-- especially when dealing with D3D. R&D happes in development with me, too. I suppose it''s this Object Reusability thing-- it''s a double edged sword, I''m learning. If you take it too far, you could spend more time trying to make it fit than it would have taken to just redo it.

SH

quote: Original post by gimp


One last cool tip. Every once in a while when you in the mood or are technically stuck on something sit back and imagine actually playing the game, imagine the graphics for shooting enemies the physics on how your player will move. Not only will it keep you motivated but you might think of other things that need to be done that from a coding perspective you might have missed.

HTH

gimp

I love doing that, just imagining what my game will be like. The problem is, five minutes later, it''s turned itself into something that a proffesional company would choke on with the technology of ten years hence. Still, you''re righ, it does get you up and running again.

SH

quote: Original post by Great Milenko


if its something large like say... an RPG or like my current project... I do a lot of planing...for a few weeks or so I just think about it... I get a good idea on how to do something I write a little note down somewhere... then when I''ve got a good amount figured out in my head I organize things... I start by listing everything I want to do on one peace of paper(paper on in MS Notepad or something)... then for each feature I pull out another peace of paper and write down an abstract discription of it... after I''ve got all the abstracts done I figure out how each peace needs to fit togeather.... then I start writing out the declerations of each function/class/whatever... then with some functions(the complex ones) I write some pesudo code for it... I run through in my head trying to figure out how each functions call each other... make shure all paramiters are there and what not... then after I''ve thought my self to death on everthing I start coding... then if I notice that something isn''t working out the way I need it to I go back to my designe docs and figure out how to make them work... while I''m programming if I come acrossed something I don''t quite know how to do... I write a little demo program and figure things out in that... then I rewrite(not cut and past) the code in the main project...



Great Milenko

Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."

http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech

I know this is a bit up front to ask, but is there any chance you could post a small example of the types of notes you make on abstract functions and objectives? Abstraction isn''t my strong point, and it would help a lot to see an example of how people take a problem like this apart.

SH