Jump to content
  • Advertisement
Sign in to follow this  
RobMaddison

Game Engine and Level Design

This topic is 3629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi Does anyone know how level design tools incorporate game engines? To explain my question further, when writing a level design tool (similar to, but obviously not as complex as, Crysis' Sandbox 2), is: a) the actual full game engine used inside the design tool? b) a superset of the game engine used inside the design tool? c) the game engine not used at all? In the likes of Sandbox 2 (and UnrealEd), it looks like you can issue normal game engine commands and enter the game to play your map whilst you are designing which says to me that the actual game engine is somehow embedded into the level designer. I'm investigating adding something similar but on a much smaller scale to my work-in-progress game engine. My engine is a relatively simple event, process and command-driven game engine written in c++ and DirectX 9 and I'd like to add a relatively simple level designer for it. The engine code resides in a library and games are written in an exe using the engine library. Can anyone shed any light on how this should be approached? My initial thought was to wrap my engine in an ActiveX control and host it in a simple c# design tool. Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
I never made an universal game engine, but I think its not a bad idea to use the same tools for the editors as in the game itself. In the past I always created the 'game' first, and then editors with (simplified) different techniques for rendering, loading data, etc. Not really wise, because if something changes in the game, I had to reprogram my editors as well, or vice versa. A lot more of work, and then there is also the psychologic aspect: I always rushed my editors into crappy products because I didn't want to waste too much time in making editors (boring).

Nowadays I do a reversal approach. Before making any game, I make test applications and the editors, using the final game engine modules. So while building, for example, a map editor, I also have to make libraries for
- loading stuff
- shaders / materials
- physics
- sound
- scripting
- and of course, rendering

Because editors and test program ussually don't need the full engine, and/or simplified methods (high quality rendering disabled), I'm forced to make the engines more universal/adjustable and re-useable between multiple programs. And when I finally can get to the game, I already have a tested engine including the editors. That means the fun can begin, focussing on the game aspect instead of writing boring tools.

If you really want to make a stand-alone engine capable of all kind of projects, I think you really need to put alot of effort in the design, documentation and structure before starting happy coding (like I always do :) ). The libraries are mentioned above could be made in several DLL files for example. The real difficulty is to make them stand-allone and not too much specific for one task. The rendering DLL for example should not be dependant on the scripting engine for example. With proper documentation and a good design, these DLL's could be connected to *any* kind of game/editor/tool.



Of course, there is somewhere a point where you'll have to choose between 'specialization' and 'globalisation'. You could make a 'super' engine capable of doing Super Mario Bros, Crysis, and controlling your refrigurator. But probably you will loose performance because its not specialized on certain tasks, and it will get huge and therefore hard to manage/use. And it costs alot of time to make this as well. Don't forget that game engine usually only live for a few years, so is it really worth the energy to make it that universal?

On the other hand, rushing and focussing too much on very specific game/task will make the engine not very practicable or hard to change when you want to do something new with it. Therefore try to make it at least 'ready for the future'. For example, in the year(s) you are working on the graphical part, there is 99.99% chance that there will come new techniques/shaders that you want to use. So make sure you can easily adjust, remove or add them.


I believe there was a tutorial on gamedev about 'how to make an engine'...

Greetings,
Rick

Share this post


Link to post
Share on other sites
Thanks for the quick response and very interesting comments, Spek. I totally agree with the "test-driven development" (or at least tools-driven-development) paradigm in this instance and it's the way my engine is developing.


Now it would be nice if I could take my pure c++/DirectX9 engine library and somehow embed it into a nice c# GUI app for ease and speed of tool development. Anyone done this before? Or should I just stick to a old-word Win32 UI?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!