4 replies to this topic

[Narf the Mouse]

If so, will you allow me to pick your brains?

What worked?
What didn't?
What architecture choices did you make and why?
What would you have done differently?
What could you have done better?

Thanks.

[ApochPiQ]

An engine for what kind of game?

[Narf the Mouse]

An engine for what kind of game?

...So that's what the post was missing.

*Edited title*

Edited by Narf the Mouse, 20 August 2012 - 08:33 PM.

[EngineProgrammer]

I have written one, a year ago.

What worked? Networking, creating games like tetris,dragonball Z(2D), video
What didn't? XFORM camera ( didn't want to use Matrices )
What architecture choices did you make and why? Factory Pattern
What would you have done differently? Using another pattern maybe? Using matrices instead of XFORM
What could you have done better? Make a better framework, because it was a mess.

But maybe you can give more details? It all depends on how you want your engine to be.
Are you interested in 2D games or in 3D games?
Are you interested in using libraries ( DirectX, OpenGl, SDL, FMOD, etc )

Have you already looked at open source engines and do you understand their frameworks?

I'm going to write a better game engine ( through writing games and extracting all reusable code )
Here is a decent engine structure: http://www.ttoprpg.com/gedisc.htm

edit:
Ah noticed you changed the title in something more clear.

Never wrote a 3D RPG engine before so I'm retreating a bit.
Have you ever wrote a basic engine? Or are you planning to move immediately to the big work? In that case stop and go back.
But same rules counts, it all depends on how your engine needs to be.

Edited by EngineProgrammer, 20 August 2012 - 08:41 PM.

[ApochPiQ]

I've worked on a couple of major 3D engines. I've also written my own small 3D engines, although I spent more time trying to get software rasterization to work than I spent on the gameplay :-)

Your questions are still very broad, and honestly a nontrivial game engine is huge enough that it's extremely hard to summarize in bullet points why things are the way they are. Usually the results are the cumulative effects of many dozens of design decisions ranging from trivial to earth-shatteringly important. They also tend to be measured in hundreds of thousands of lines of code, if not more, which makes it all but impossible to talk about in high-level general terms with someone who isn't also intimately familiar with the codebase.

There used to be some great post-mortem analyses of various games floating around GDNet, but I imagine you can still find them via Google. Those are probably your best bet, since it takes a several-page article to really get any deep information on a project of scale.