🔒 Locked 🎮 Unity

Engine design suggestions requested

Started by muhkuh Sep 15, 2005 at 5:59 PM 3 replies 900+ views

Original Post

Sep 15, 2005 at 5:59 PM

Hello, I've just been hired as a game programmer to use and improve an existing engine. Unfortunatly the current state of the engine seems like a total mess to me. As this is my first employment in the game industry I'm quite unsure what should be changed how to improve the situation. So I'm going to ask you. I'll give an overview of the current situation followed by some questions. It would be great if you could spend the time to read it through. As of yet only one programmer (called Mr. G. from now on) worked on the project. He coded the engine and a scene editor for external artists. The most awkward thing to me is that the scene editor (which is quite limited and buggy) does produce C++ source code that gets compile into the engine. Mr. G. used the scene editor for basic scene setup and edited the generated C++ code by hand. The internal structure is something wildly grown. There is some base mesh class containing OpenGL code and a limited number of derived classes for special cases. There is some kind of hirarchy that will cause problems when used excessivly as it wasn't designed for that. The problem is that the only person who can actually use this stuff is Mr. G. But soon an artist will be hired to setup scenes and I doubt that he or she will be able to do anything with that scene editor. Furthermore it's not possible to develop a better scene editor while improving the engine at the same time as they are to tightly coupled - remember: the scene editor generates code that requires to match the engine's internal classes and such. I think a complete redesign would be best. I really don't see a lot worth keeping. So my question is: Which design do you recommend in that case? After reading some articles about game engine design I think a new engine should: 1. Put graphics API dependent code in a renderer class and use the visitor pattern. Although it might not be necessary for now it's not that much extra work and allows support for different render paths. 2. Establish some scene graph like structure using the composite pattern. May be a transform hirarchy tree with links into an object list. An attribute stack for rendering the tree seems like a good idea, too. 3. Skip this C++ code generation and establish a working arts pipeline. I'm unsure how to do this. Is a scene editor really needed or should scenes be modelled in 3DSMax? Or should the artist define positions and animations using a script? Thanks for you endurance to read this far. I hope the information I gave is enough for you to give me some advice. May be I should add that this is only a graphics/sound engine with spare user interaction for small scenes on low end systems. Thank you for helping me. Regards Markus

rollo

Sep 15, 2005 at 6:12 PM

If you feel the engine is just in the way at the moment (and it sounds like it) why not go with an open source engine like Ogre or Nebula Device (if you want to be patriotic ;)) instead? I'm pretty sure both have exporters/importers etc for Max/Maya.

EDIT: Just read your last paragraph properly... Ogre and nebula might be a bit big if you are aiming for very low-end systems.

Mike Bossy

Sep 15, 2005 at 6:14 PM

The first big thing is to remove any kind of tool that generates game code that needs to be tweaked. Talk about a bad work flow where artists make changes the results in new or changed code that needs to be compiled in. Who is responsible for tracking down build breaks in this scenario?

The ideal situation is to have your engine totally data driven where artists can add content to the game and the engine will pick it up without needing any new code. The middle step for this is to have new content mean new code but have a developer add it. As long as you have your object model done well then your new content should map to an existing object type so you really just need to create a new instance of that object for the new content and add it to the scene.

hplus0603

Sep 15, 2005 at 6:36 PM

You don't need to redesign anything. It's almost always better to keep something that's working working, and successively clean up the parts that are necessary.

I would change the part that generates code first. Factor out everything that the generated code does into one big interface (you can split it later). Provide another big interface of game functionality to the level, so that the level doesn't use globals for anything, but instead uses the interface. You do this by changing the code generation.

Once that's done, write a "generic" level which can take data structures to determine the variation points (the differences in behavior), and have the code generator generate these data structures rather than code.

Once you've done that, translating the data structure generation into XML, and writing de-serialization that loads the XML into a copy of the data structures for the loading side is the last piece. All the while, you've kept the existing system working.

Meanwhile, if you find crashing or data-loss bugs, make sure to write a unit test that reproduces the bug first, then fix it so the test passes. One fix would be to cut out the functionality entirely, if you can have something still working without it. You can always add it back later if you'll need it.

Now, there may be other factors you're not telling us about. Is there a filesystem on the target device? Are there publisher requirements? Does download size matter? Does the generated code implement functionality that's better expressed in script?

muhkuh

Sep 16, 2005 at 1:35 AM

Thank you for your comments.

Now to the missing information:

Quote:
Original post by hplus0603
Now, there may be other factors you're not telling us about. Is there a filesystem on the target device? Are there publisher requirements? Does download size matter? Does the generated code implement functionality that's better expressed in script?

There is a file system on the target device that is linux on X86 at the moment. For now it's a hard disc but that will probably change into a flash memory. So "download" size does matter as much as there will be quite limited space but that was something I thought I could care about later.

There is no publisher as a sperate company. Our requirements are that it looks good while not using too much resources.

The generated code does something like this:
1. create all game objects (scenes, meshes, subscenes, lights, animations) as global variables in a namespace

2. generate quite general setup functions to initialize a szene, setup required rendering parameters, rendering it and doing animation work.

When the scene required user interaction that went further than switching from one scene to another the programmer used the generated code as a base and added it manually. His point is that he is much better in writing code and that there will always be things in a new project using the engine that a scene editor cannot express. For instance there is some wheel in the scene that moves around a bit. A user event tells the engine to rotate the wheel to a specified position or to stop rotation in a specified position. How can this be mapped to the arts pipeline? That's what I thought might be done by a script. Is that correct?

What I forgot ealier is that the animation system is quite limited too. All frame's matrices precomputed. There is no interpolation going on. This leads to a huge number of key frames and makes blending between animation of characters quite hard. The skinning is done by the CPU and uses an enormous amount of CPU cycles. Also there are tons of global variables in the code in almost every file. Furthermore there are serious problems with state management. Every scene has to take care of every render state when it is designed. This might get quite annoying when more render states are intrudoced. I ran into this problem when adding a new scene. Another scene seemed to require som specific render state but didn't set it as it assumed to be the default. So I had to fiddle out which one of my render states set was to blame and which value of it the old scene required.

That's why I thought a rewrite might be less work than changing everything. But I see your point that changing something working (well it could be better called existing) might be the better choice.

[Edited by - muhkuh on September 16, 2005 2:35:42 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.