Sign in to follow this  

How should a game engine work?

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

Hello everyone. This is something that i alone just cant figure out (yes, i'm THAT dumb). I've been working on a game engine for the past 2 years and about 3 months, but i keep failing at the most critical point: How should the user use the game engine? So let's say i've got some fancy-pants engine done, it's working well, but now it's time to give access to the users of the engine. What should i do? Should i allow the user to do things like:
GraphicsDevice = GetGraphicsDevice("OpenGL");

while(GraphicsDevice->Active())
{
   GraphicsDevice->Clear();
   GraphicsDevice->Draw();
   GraphicsDevice->End();
}

Or should i do something different? How exactly should a game engine give access to it's users for the creation of games? Sorry if this sounds like a stupid question, but i'm having quite a hard time thinking of a decent answer... Thank you for your time regarding this message, and have a nice day!

Share this post


Link to post
Share on other sites
You should come up with a logical and consistent api. I would look at how the other game engines do it to get an idea(ogre,crystal space etc.) Though I wouldn't copy it whole cloth because then what is the point of using yours?

Share this post


Link to post
Share on other sites
Phantom, i did make games, my problem is (i hate it when i cant explain myself in my first post) that i want to make it "so easy to use" that i end up messing up in the end.
I've been able to make simple first person shooters, "online games" (more like online worlds), "demos", and other things, but my problem is that i try to make it "so very easy" that i end up with no idea on what to do.

But i think i should just give the user access to the code i myself use when making games, do you think that's the way to go?

Share this post


Link to post
Share on other sites
Quote:
Original post by stonemetal
You should come up with a logical and consistent api. I would look at how the other game engines do it to get an idea(ogre,crystal space etc.) Though I wouldn't copy it whole cloth because then what is the point of using yours?
Never mind the fact that copying code from an open source project and making out like it is yours would be illegal :-)

Ok here's a few tips:
1. Never over simplify. Making games is technical, you should allow the user to do technical things when he needs to.
2. Make your interfaces clean, intuitive, logical and most of all, comment everything.
3. Do the basics well. Memory management, error reporting, helper utilities / etc should all be perfect.
4. Dont kid yourself, this engine is probably mostly a learning tool, but make games alongside the development of the engine. It will help you learn how it needs to work, figure out what the missing features are, and make it perfect!

Good luck, it's not easy :-)

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
Never mind the fact that copying code from an open source project and making out like it is yours would be illegal :-)

Too true.
Quote:
Original post by TheGilb
Ok here's a few tips:
1. Never over simplify. Making games is technical, you should allow the user to do technical things when he needs to.

I always try to make whatever i do easy to use, maybe i think about the users of the engine as some sort of "hai i dun want 2 code plz" guys. Can't believe it took me this long to figure that out. =/
Quote:
Original post by TheGilb
2. Make your interfaces clean, intuitive, logical and most of all, comment everything.

My engine (previous version) had over 20k lines of comments, for doxygen documentation. >_>
Quote:
Original post by TheGilb
3. Do the basics well. Memory management, error reporting, helper utilities / etc should all be perfect.

I wouldnt say it's perfect, but the Memory Management system, Logger, and helper functions were pretty good.
Quote:
Original post by TheGilb
4. Dont kid yourself, this engine is probably mostly a learning tool, but make games alongside the development of the engine. It will help you learn how it needs to work, figure out what the missing features are, and make it perfect!

I usually just make demos, my deviantart page has a lot of demos as screenshots and flash videos, and i'm constantly adding features to it. Problem is, i oversimply things when i want to complete it...
Quote:
Original post by TheGilb
Good luck, it's not easy :-)

Yes it's not. And thank you!

Share this post


Link to post
Share on other sites
It wouldn't be illegal if he open sourced his engine as well.

It takes a certain amount of sophistication to successfully be a programmer, so don't be afraid to allow things to be complicated. However try to avoid "Mechanical complication", that is functions should provide clean logical actions there should never be a certain order functions have to be called in such as screen create, screen init, screen set settings, screen reinit that will break unless called in that very specific order(sure creation before first use can be expected but in the example every function after create should not exist, creation should produce a working object). If I have to mechanically call things in order it should be automated. If there can be a reason for the mechanical path provide both a default easy path and the broken up step by step path. In your example there is a clear, draw, end that sounds like something that will always be performed in that order why should I be bothered with having to type repetitive code?

Another thing if you are writing this engine for others you will be hard pressed to get it 100% right with out the involvement of others. Try to clean up and document the api and release it if you are going to do so. If it is a pet project not meant for outside consumption then try documenting it as if you expected others to use it, any time during the tutorial that you can't explain why the next step isn't hidden in the current step then you need to polish that section of the api.

Share this post


Link to post
Share on other sites
What are your goals with this engine? To build games with, or to release it to the public?


Either way, it looks like you're a perfectionist and haven't figured out the problems of that attitude yet. I've got the same issue, but I'm actively fighting it. Things don't need to be perfect, they just need to do their job. That's not an excuse for poor coding, that's a reminder not to waste time perfectioning things that already forfill their purpose well enough. If you want to build a game, then get a game done. There will always be rough edges. That's ok, it's normal. I can't name a single game that was absolutely perfect.

As for easy to use, the only way to find out is to put it out in the open. In the announcements board, there's two guys who are working on a 2D game engine, Agen. From time to time they're releasing a new build. For me, it's pretty interesting to see their progress, for them it's pretty usefull to receive feedback every now and then.

Share this post


Link to post
Share on other sites
"clear -> draw -> end" seems like a perfectly sound implementation to me, with the "clear" method being optional, of course. The engine won't know how many objects you intend to "draw," so you have to tell it when you're done. This is intuitive to graphics programmers and shouldn't be changed. Otherwise, I agree that obligatory steps should be consolidated whenever possible. This is the path DirectX has been following. I still get chills thinking about device initialization in DX7. Brrrr.

Share this post


Link to post
Share on other sites
How about
class MyApp : public engine::Application {
public:
void initialize() { ... initialize stuff ... };
void update() { ... update loop ... };
void finalize() { ... get rid of stuff ... };
};

int main()
{
Base asdf(new MyApp);
}

That's the base would handle the generic loop (you still might want to give some access to eg. clear) and application would just update what it needs.

BTW. I have no idea how a game engine should work [ignore].

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
Dont kid yourself, this engine is probably mostly a learning tool, but make games alongside the development of the engine.


QFE

That's my approach as well. I spent the better part of two years building a 2D engine, but i did it with a specific game in mind. In fact, the engine was born from the game. I ripped out all the game-specific code and turned it into its own library. No i'm planning on using for a different project.

Having a game project gives your engine project some direction. Consider doing both in tandem.

Share this post


Link to post
Share on other sites
the game engine should be easy to use for who ever wants to use it. With that said, usually, the game developer will want easy to use graphical user interfaces. They will not want to go into the engine source code all that much.

So what I would recommend is abstracting your engine in such a way that all the key features can be used with simple scripts and through "level editors".

For example, you fire up the level editor where you are presented with tools to build your dungeon (or what ever). place objects, monsters etc. THen by writing a few scripts you make everything come alive.

Oh, and one thing that you shouldn't overlook, the game engine should be focused to some sort of genre. Don't try to make something that will be able to handle every different type of game out there. If you do that, you'll spend the rest of your life building the engine and never make any games with it.

Share this post


Link to post
Share on other sites
Write a game, then turn the code into a game engine afterwards if there is public demand for it. Example:

Doom 3. They make the game, then sell off the game engine.
Tribes 2: Same. Its now called the Torque Game Engine.
Quake 3: Same. How many quake 3 mods are there?
Half Life (original): Modders take the game engine and created counterstrike.
Half life 2: -> Source engine.

You should follow the same process. If your game is good enough it will generate public demand. If you sell it (big step I know but its possible) you will generate capital you can then use towards developing a game engine to sell under the same brand.

REALLY BIG IMPORTANT POINT:

These things are years down the line for you. Just focus on making a GAME, don;t worry if the components are re-usable to others for now, just ensure you document it well enough and have a simple enough process that YOU or anybody who you work with is able to understand what to do to create a game using your "engine", even if the pipeline is convoluted.

Share this post


Link to post
Share on other sites
Hi this thread gave some sort of knock on the head. I guess I really have to concentrate on a game. It's been a 2 years already, and because of that perfectionist and make-an-engine-first attitude I wasn't able to accomplish anything tangible.

Share this post


Link to post
Share on other sites
Quote:
Original post by AndreiVictor
Hi this thread gave some sort of knock on the head. I guess I really have to concentrate on a game. It's been a 2 years already, and because of that perfectionist and make-an-engine-first attitude I wasn't able to accomplish anything tangible.


No:

1) You picked up a lot of programming experience.
2) You learned bits of a graphics library, and bits of an IO library.
3) You will quickly learn more of those libraries now that you have a grounding.
4) You readily admit your mistake, a sign that you are not insane. (i.e. Insanity being defined by doing the same thing again and again, getting the same result, but expecting a different result).

I still haven't finished my Zombie shooting game, and guess what... I'm 2 years in. I've been concentrating on creating a game. I spent the first year learning stuff, the second building stuff. Once the game is complete I'll turn it into libraries (not an engine) that I can use to create other games.

Share this post


Link to post
Share on other sites

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