Where to start with game engine creation
Author
Hey guys. I have been put in charge of developing a 2D game engine for my group. Problem is I've never made a game engine. I know what it needs to be capable of but my question is where do I start? I'd like to jump in and start with the battle system but that doesn't seem very logical since I wouldn't have a rendering engine or any of that good stuff. So, my simple question is where do I start.
Thanks!
It doesn't really matter where you start, it just matters that you finish
personally I start on the output portion so I can spew out debugging info for the rest of the parts.
personally I start on the output portion so I can spew out debugging info for the rest of the parts.
Start with planning. Write down the requirements, try to make a list of the dependencies of each feature. Then you can move on with laying down the general architecture, as well as in which order each part should be implemented.
I suggest writing it in this order.
Math/CRT
Resource Manager
Renderer
Input
Physics
Networking *if necessary
Entity System
AI Library
GUI/Sound
Math/CRT
Resource Manager
Renderer
Input
Physics
Networking *if necessary
Entity System
AI Library
GUI/Sound
Personally i find it easier to start by just writing the game, then lift out anything that isn't specific to that game so that it can be reused easily, make a second and third game with that as a base and refactor as needed and you'll get something that resembles an engine quite naturally.
It doesn't really matter where you start, but personally i find that getting something interactive on screen early helps alot with the motivation, normally i start with a rough prototype of the gameplay and just work from there. Don't forget to refactor your code, its fine to just hack something together to get things rolling(i always do) as long as you remember to clean it up afterwards.
It doesn't really matter where you start, but personally i find that getting something interactive on screen early helps alot with the motivation, normally i start with a rough prototype of the gameplay and just work from there. Don't forget to refactor your code, its fine to just hack something together to get things rolling(i always do) as long as you remember to clean it up afterwards.
Usually you would design from top-to-bottom and then implement from bottom-to-top. However, many people don't want to spend hours designing and would rather dive right in with code (I know I do); thus it would make sense to begin coding from the high level stuff first.
In other words, begin making things like your battle system, your entity system, scenario system etc and get them working with input and graphics that are just bunged/hacked in (ideally in some sensible way, but it's not essential).
Once you're happy (or as you do it) you can lift out graphics related code, input code, physics code and so on; then your lower level engine appears as a simple iterative refactoring of that.
To get things rolling you might consider creating something as simple as (in C++):
Then specialise this for things like players, NPCs, buildings, trees, GUI objects etc.
In other words, begin making things like your battle system, your entity system, scenario system etc and get them working with input and graphics that are just bunged/hacked in (ideally in some sensible way, but it's not essential).
Once you're happy (or as you do it) you can lift out graphics related code, input code, physics code and so on; then your lower level engine appears as a simple iterative refactoring of that.
To get things rolling you might consider creating something as simple as (in C++):
class SceneEntity{public: virtual ~SceneEntity() = 0; virtual void render() = 0; virtual void update() = 0;private: Matrix transform; // etc};Then specialise this for things like players, NPCs, buildings, trees, GUI objects etc.
I'd change bzrooms list a bit so you can more quickly get to prototyping your game:
Math/CRT (get an existing math library, you likely won't do a better job)
Resource Pool (I hate "managers", a factory will work fine for this)
Renderer (very, very basic, displaying models and single textures then move on and add on later as you go)
Input (Could be before/after renderer, just very simple to start)
GUI (need to see things, want to be able to prototype game fast and a GUI helps)
Physics (use an existing library at least to start)
Entity System (component based will be worth the time trust me!)
** Prototype most of the game here so you can start tweaking early **
AI Library (final version of the AI)
Networking (use an existing library...)
Sound (basic sound/music can be implemented earlier, come back and finish it here)
Math/CRT (get an existing math library, you likely won't do a better job)
Resource Pool (I hate "managers", a factory will work fine for this)
Renderer (very, very basic, displaying models and single textures then move on and add on later as you go)
Input (Could be before/after renderer, just very simple to start)
GUI (need to see things, want to be able to prototype game fast and a GUI helps)
Physics (use an existing library at least to start)
Entity System (component based will be worth the time trust me!)
** Prototype most of the game here so you can start tweaking early **
AI Library (final version of the AI)
Networking (use an existing library...)
Sound (basic sound/music can be implemented earlier, come back and finish it here)
Write Games, Not Engines; start writing whatever you need to get your game up and running, and you can factor out the reuseable functionality into an engine later if you'd like. Windowing, rendering or input (you'll need both, I'd suggest the rendering first so you can test the results of the input visually) and resource loading are probably things you'll need early on. I also agree with Mike2343 that prioritising your functionality to allow for prototyping of the gameplay as early as possible is a good idea.
I also agree with his suggestion that you should use existing libraries where possible, and in fact... if you want to get straight into the gameplay stuff is there any particular reason you aren't using an existing engine or framework (HGE, The PopCap Framework, Torque Game Builder, etc.) rather than rolling your own?
I also agree with his suggestion that you should use existing libraries where possible, and in fact... if you want to get straight into the gameplay stuff is there any particular reason you aren't using an existing engine or framework (HGE, The PopCap Framework, Torque Game Builder, etc.) rather than rolling your own?
@jbadams: I was exactly hinting at that without directly saying it. That and I was in too much of a rush to find that "write games not engines" link. There are those that want to write engines (myself, I love it) but few understand it's hindrance of writing games, which most people wish to do on here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
