Jump to content
  • Advertisement
Sign in to follow this  
GroZZleR

Game Engine Design - Help guide my thoughts?

This topic is 5394 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

Hey all, I know these kinds of questions come up all the time, but it's an important issue, so I'm going to make a new thread anyways. I'm about a quarter (give or take) of the way through my final year of college, and I think it's about time I created a very serious demo project to use when applying for jobs come May. The project is going to be an overhead 2D game, with moddable content (new guns, new enemies, etc.). This allows me to showcase the areas I want to specialize in: Gameplay, AI, Logic and Content Creation. I can also showcase these things without complicating things with the problems associated with 3D (plus I think 2D can be just as sexy). Enough about my history, let's talk about engines. I think that a modular, efficient way of making this engine reusable is to adapt an "engine in library, game in exe" approach over the more common, "game in DLL, engine in exe". The library allows me to reuse rendering and sound routines for the various planned tools. Specifically, the map creator, sprite animator and the actual game. Since I'll be doing a 2D game, rolling my own tools seems like the only real solution (and a good learning experience). So basically, the engine library will break down like this:
	Graphics
	Audio
	Networking
        Input
        World (Map / Level)
        Timers
	Sprites and Animation
        Resource Managers and Factories
        GUI
	Entities (basic entity to derive from)
The engine library will also create a series of classes and interfaces, to "turn on" these components "out of the box". So basically, create an instance of the graphics, sound, input and resource manager classes. Derive some new entities from the base entity, and attach animation sets (created through the sprite editor and loaded through the predefined sprite classes) and you're pretty much done. Make a game loop, poll for input, move your sprites and you're on your way. Basically the engine library is 'put together' by the game, rather than the engine 'putting together' the game. Is this the way to go for my project, or am I under-engineering? By the end of it, I really want this 'library engine' to handle any 2D game, so reusability and modularity is key. Never having to create a 2D engine after this is the idea to keep in mind.

Share this post


Link to post
Share on other sites
Advertisement
Having recently remade alot of my "just a nice simple 2D" client application, I'd just like to remind you that you will make more engines in the future, because the first few will be poor. Also, it's my experience that Input is generally broken into Mouse and Keyboard input, as the two are fairly seperate beasts in practice.

Share this post


Link to post
Share on other sites
I don't think "game in DLL" is the more common approach. Most SDKs you actually buy will put "engine in DLL" and let the game use whatever components it wants.

What I will suggest, is making sure that you define a small core set of things that every piece of your engine depends on (say, memory management, reference counting, logging and error handling) and then making sure that every other module (file I/O, sprite management, input, windowing, etc) is independent from every other module in implementation and interface. Where you need to hand off data from one to the other (file I/O -> sprite sheet -> 2D rendering), you define interfaces that make piping one into the other easy, but you keep the actual implementations cleanly separated.

Share this post


Link to post
Share on other sites
I'd put in some physics and/or collision detection too.
I believe GUI (menu stuff I assume) is very closely related to your sprites and input. Actually, I treat a menu as renderable and event handler (input are in essence events, èh).

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Where you need to hand off data from one to the other (file I/O -> sprite sheet -> 2D rendering), you define interfaces that make piping one into the other easy, but you keep the actual implementations cleanly separated.


I am in the process of designing/creating an engine also. And, I've been stuck with this problem on how to seperate everything and still have the ability to communicate between them.

What type of implementation for these interfaces do you suggest? Just a message handler or something more extravagant than that?

Share this post


Link to post
Share on other sites
I would also encapsulate a scripting engine. There are many many many many (etc.) scripting languages to use, but making a nice wrapper interface which provides some game specific scripting capabilities is very important.
Do this right and you can swap in different scripting languages (ie python, lua, etc) as you settle on your fave. The key is to *not* do a one-to-one mapping. Provide some higher level concepts like, triggers, ai sequences etc. It is much easier to change (and throw away!) scripts.

Good luck. :)

-R

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
I don't think "game in DLL" is the more common approach. Most SDKs you actually buy will put "engine in DLL" and let the game use whatever components it wants.

What I will suggest, is making sure that you define a small core set of things that every piece of your engine depends on (say, memory management, reference counting, logging and error handling) and then making sure that every other module (file I/O, sprite management, input, windowing, etc) is independent from every other module in implementation and interface. Where you need to hand off data from one to the other (file I/O -> sprite sheet -> 2D rendering), you define interfaces that make piping one into the other easy, but you keep the actual implementations cleanly separated.


You meen that you write GAME for ENGINE, and what bad to write ENGINE for GAME ?

Share this post


Link to post
Share on other sites
Guys, why don't you just use one of the open source engines already out there, like Nebula2 for instance? Are you afraid that if you contribute to a public effort, you're not going to adequately demonstrate your technical prowess by doing shitloads of work? Think again. All of the public 3D engines need shitloads of work. Quit trying to write everything from scratch and save the implementation complexity for your actual game.

I mean really, "I would also encapsulate a scripting engine." What do you think all the open source guys have been banging their heads on already??!?

Share this post


Link to post
Share on other sites
I disagree, a potentail employer is going to want someone who knows what he is doing. It is a very good learning experience doing everything from scratch, right now im writing a game with directX. The next game i write im gonna build my own graphics engine, tricks of the 3d game prgramming gurus!

this will let me learn any api in days.

Share this post


Link to post
Share on other sites
Quote:
Original post by vanevery0
Guys, why don't you just use one of the open source engines already out there, like Nebula2 for instance? Are you afraid that if you contribute to a public effort, you're not going to adequately demonstrate your technical prowess by doing shitloads of work? Think again. All of the public 3D engines need shitloads of work. Quit trying to write everything from scratch and save the implementation complexity for your actual game.

I mean really, "I would also encapsulate a scripting engine." What do you think all the open source guys have been banging their heads on already??!?

because its fun?

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!