Sign in to follow this  

Is it a good idea to separate game from engine code from the start?

This topic is 2539 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,

I'm working on a game for which I decided to start from scratch with OpenGL, OpenAL etc. I've moved all engine-code (i.e. code I could reuse in a similar project) into a separate source directory, and once I can come up with a reasonable name for it, I'll move it into a separate project.

However, working on the game and the engine at the same time does make things a little more complicated from time to time, hence I'm wondering if you would suggest continuing with my approach or to throw all the code together for now and extract the engine code later. What is your usual approach if you start from scratch?

Share this post


Link to post
Share on other sites
Actually, I've done it both ways, and it was a pain-in-the-rear to extract the reuseable parts. If you've developed projects with reuseable code before, I'd recommend keeping stuff in separate folders. Note: that alone won't guarantee, by any means, that the "reuseable" code will be clean when you're done.

If you're relatively new to game programming, I'd suggest you code a game (all-in-one) and get a full understanding of the features you want in a game engine. Then develop the engine.

Share this post


Link to post
Share on other sites
You might want to write at least one (relatively complete) game in the style you want your engine to be: 3D, 2D, FPS, side-scroller, etc., to see what your engine will have to do. As an "all-in-one" type game, it'll be easier to code and debug, and you can get the kinks worked out. It will probably go more quickly and you'll have the satisfaction of having something (close to) working.

There're going to be several pieces - texture loading, collision/physics, etc., that, without a lot of experience in games in particular, you may need to get a taste of.

Share this post


Link to post
Share on other sites
So the gist seems to be that it'd be beneficial for me to create my game without separating engine from game content. I don't have a problem with that, but IMO it makes it a bit more difficult to keep things in order. For instance, this is my project's current source tree:

src // Everything specific to the particular game I'm building goes right here.
- engine // Everything that seems reusable goes here.
-- core // Fundamental stuff. Game initialisation, utilities etc.
-- graphics // Everything related to graphics
-- audio // Everything related to audio
-- input // Everything related to input

I guess I'll come up with more subdirectories in the future. If I don't split between game code and engine code, I can probably not divide stuff into subsystems like this, can I? It'll probably all be mixed up.

On the other hand, this separation does indeed complicate things. I'm working on menus right now for example, and although I've created a subclass of "Sprite" that functions as an animated menu item *, I can't really push it into the engine directory because I've hard coded, font face, font colour, mouse over effect etc. Making all of this configurable is not reasonable right now, and I don't know where I will need flexibility in the future. That's probably due to my lack of game development experience.

Would you wager that trying to built an engine along the way will harm my gamedev skills more that it will benefit them? Is it reasonable to built anything but small games without clearly separating the engine?

* Not sure if that's sensible design, but that's probably another story.

Share this post


Link to post
Share on other sites
Quote:
Making all of this configurable is not reasonable right now, and I don't know where I will need flexibility in the future. That's probably due to my lack of game development experience.

It sounds like it, but that's okay. You don't know what you want yet or how to program it. Get something simple working. You don't want to frustrate yourself (you sound like a mature programmer so that may not be a problem).
Quote:
trying to built an engine along the way will harm my gamedev skills more that it will benefit them?

If you've been programming for years, even if not games in particular, I don't think it will hurt. The biggest benefit of your previous experience is that you've learned how to learn. However, trying to guess how all the features should be kept separate may be delaying acquiring specific skills. Concentrating on developing one game at the moment may serve you better. As mentioned above, you need to find out what features you want in your game before you can generalize or make them configurable.

EDIT: Even the best available game engines aren't infinitely configurable. There are going to be some things that are just hard and fast and that's how it has to be done. At this early point in the development, worrying about how to make a menu button configurable certainly sounds premature. Actually, worrying about menus at all, at this point, sounds premature. They're window-dressing and, for now, could be implemented as dialog boxes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Buckeye
If you've been programming for years, even if not games in particular, I don't think it will hurt. The biggest benefit of your previous experience is that you've learned how to learn. However, trying to guess how all the features should be kept separate may be delaying acquiring specific skills. Concentrating on developing one game at the moment may serve you better. As mentioned above, you need to find out what features you want in your game before you can generalize or make them configurable.

EDIT: Even the best available game engines aren't infinitely configurable. There are going to be some things that are just hard and fast and that's how it has to be done. At this early point in the development, worrying about how to make a menu button configurable certainly sounds premature. Actually, worrying about menus at all, at this point, sounds premature. They're window-dressing and, for now, could be implemented as dialog boxes.


Well, my game has quite a high emphasis on menu design, so it's kind of a core aspect. About the rest of your post: I guess you're right, I have been struggling with where to draw the line between "game" and "engine" code. I'm really not a fan of prophetic software development, so I decided to add nothing to the engine that I don't need right now, for this game. If I compare a game engine to a software framework (e.g. Google's Android SDK), I can probably safely add most of the menu code to the engine. In Android, a preferences view will (per default, the framework is quite flexible) have it's look and feel completely defined by the SDK.

But this comparison doesn't make it that much easier to draw the line. I'll put my menu item into the engine, because hard coded font and animation is fine for now. The title menu itself, however, does sound like game content. Then again, it could also be engine, I'm undecided.

Can you give me some rules of thumb on how to best draw that line?

Share this post


Link to post
Share on other sites
The pain-in-the-rear part was trying to extract general stuff from my game. Part of my own experience - see below.
Quote:
Can you give me some rules of thumb on how to best draw that line?

Personally, no, I'm afraid. I'm more a fan of reusable code for my own use than creating an engine for my own use.

I have code that initializes DirectX, maintains full-screen and windowed resets, supports Windows menus and has empty functions such as OnCreateDevice(), OnLostDevice(), OnResetDevice(), OnUpdate, OnDraw, etc.

Likely due to my own experiences and preferences, I've found, for myself, that creating content compatible with an engine takes more time than implementing game specifics which are compatible with the general functions mentioned above. So I copy the reusable code into a new project and go from there.

I did code some classes in libraries for collision detection/physics and sound playing. I guess those are sort of like engine components. I guess it boils down to preferences - how basic or complete you want your engine to be, how much of the coding you want the engine to take care of versus how much is to be left to the user to create compatible content.

Share this post


Link to post
Share on other sites
Quote:
Original post by Buckeye
I have code that initializes DirectX, maintains full-screen and windowed resets, supports Windows menus and has empty functions such as OnCreateDevice(), OnLostDevice(), OnResetDevice(), OnUpdate, OnDraw, etc.

Likely due to my own experiences and preferences, I've found, for myself, that creating content compatible with an engine takes more time than implementing game specifics which are compatible with the general functions mentioned above. So I copy the reusable code into a new project and go from there.


I guess writing reusable code is more about writing decoupled, coherent classes than about putting stuff into a different project. Do you split game content code (the flow of the game, the only thing I would not expect to see in an engine) and the rest in any way? Do you abstract DirectX away? Do you organise into graphics, sound etc. subsystems?

What I don't like about that approach is that I'd have to literally copy code, I don't like to do that. If I keep it in a separate project, I can easily fix bugs or make improvements in several games at once.

Quote:
Original post by Buckeye
I did code some classes in libraries for collision detection/physics and sound playing. I guess those are sort of like engine components. I guess it boils down to preferences - how basic or complete you want your engine to be, how much of the coding you want the engine to take care of versus how much is to be left to the user to create compatible content.


I'm not planning to make an engine that is used by anyone except by me, so that doesn't really matter to me. What I want is to pump out a second game ASAP as soon as the first one is done, and to make it as easy as possible to port the whole series to Android, and possibly some other systems as well.

Share this post


Link to post
Share on other sites
There is something called "Design Patterns". It allow you to write Reusable code.. There are two great books about Design Patterns, the first is "Design Pattern Gang of Four" and the second (more easy to learn) "Head First - Design Pattern".

There you can find all answare that you need.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tano_ITA
There is something called "Design Patterns". It allow you to write Reusable code.. There are two great books about Design Patterns, the first is "Design Pattern Gang of Four" and the second (more easy to learn) "Head First - Design Pattern".

There you can find all answare that you need.


I know the GOF patterns and they're general purpose patterns, doesn't tell me where to draw the line between engine and game code.

I'll guess I'll make the distinction as follows:

Game code: Everything that describes the game's flow and logic. Like the business layer in an enterprise architecture.
Engine code: Everything else.

Share this post


Link to post
Share on other sites
Note: my personal goals include tweaking code (below the "engine" level) just for the sake of learning new "stuff" to see what happens. That supersedes, for me, having an engine.
Quote:
writing reusable code is more about writing decoupled, coherent classes than about putting stuff into a different project

Yep. And, as you mention, if you find a bug in the "copied" code, it's easier to fix and re-implement if it's separate. I guess I've just had my code around long enough (it's not that complicated) that it's "bug-free." [laughs at himself: yeah, right]
Quote:
Do you split game content code...

In that I usually code "content" to conform with the general functions OnCreateDevice, OnResetDevice, etc., yes. And that's not the only reusable code I employ. I have various reusable mesh classes (static, animated, animation controller, etc.) that I copy into my project as needed - rather than having an engine that supports any-and-all types of content.

Being basically lazy, I could've put those objects in statically linked libraries, I suppose, to pull in only what's needed. But I tweak my code a lot and add custom implementations quite a bit. See "learning new stuff" above.
Quote:
Do you abstract DirectX away? Do you organise into graphics, sound etc. subsystems?

I don't abstract DirectX. If something responds to OnDraw (for instance), it's in charge of drawing itself - using DirectX calls, etc. That could be certainly be abstracted, I would think, but I'm too lazy to go back and generalize an OnDraw call. I also find myself using custom file formats a lot (I enjoy implementing those).
Quote:
What I want is to pump out a second game ASAP as soon as the first one is done

That's a decision that you'll have to base on how you want to spend your personal assets, "assets" being effort, time, etc. It sounds like you'll probably want to do a third.. and fourth.. perhaps concentrating on content, rather than implementation. That would push you towards an engine, I would think.

EDIT:
Quote:
the game's flow and logic

My reusable code does contain a game loop/FPS control. I implement logic primarily through OnUpdate calls.

Share this post


Link to post
Share on other sites
Quote:
Original post by futlib
Hi,

I'm working on a game for which I decided to start from scratch with OpenGL, OpenAL etc. I've moved all engine-code (i.e. code I could reuse in a similar project) into a separate source directory, and once I can come up with a reasonable name for it, I'll move it into a separate project.

However, working on the game and the engine at the same time does make things a little more complicated from time to time, hence I'm wondering if you would suggest continuing with my approach or to throw all the code together for now and extract the engine code later. What is your usual approach if you start from scratch?



My approach right now is to throw it all together but to group the "engine-like" code into a separate class as much as possible.

Share this post


Link to post
Share on other sites
Quote:
Original post by Buckeye
That's a decision that you'll have to base on how you want to spend your personal assets, "assets" being effort, time, etc. It sounds like you'll probably want to do a third.. and fourth.. perhaps concentrating on content, rather than implementation. That would push you towards an engine, I would think.


Hm, so I guess it really depends on what one tries to achieve. Yeah, we're planning to do three games in a row (episode distribution model), and I'm planning to focus on other projects after the first one is done, so I need good maintainability. Although it's possible with copied code, it's still a nightmare IMO. At least for buggy, fresh code like mine, a more mature code base like yours is probably not affected as much.

My final goal is to have close to 100% of the game scripted, so that I'll "just" have to port the engine to other systems later to make the games available there.

Quote:

My reusable code does contain a game loop/FPS control. I implement logic primarily through OnUpdate calls.


Is OnUpdate regularly called by the game loop? In that case, our design's the same in that area. I was wondering if my event polling (that method checks for input etc.) was a good idea :)

Quote:
Original post by dantheman3633
My approach right now is to throw it all together but to group the "engine-like" code into a separate class as much as possible.


Just one class? But you're differentiating. Do you abstract low level stuff like DirectX, OpenGL etc. away?


Share this post


Link to post
Share on other sites

This topic is 2539 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this