24 replies to this topic

[Stefanoit]

Hi everyone, I just started with Game Development and I'm currently working on a 2d engine for my game. I'm using C++ and SDL and I wanted to ask you guys a few questions about the engine structure.
I've been reading articles and tutorials on the web on the subject and it looks like there's really no "perfect design" it's a personal choice how to structure classes etc... I was thinking about it and I came up with this:

• System class: inits/closes the library, handles input and rendering and checks for collision
• Image class: loads/frees images and returns an SDL_Surface * (because i'm using SDL) when needed
• Audio class: same as Image class just with audio
• Font class: save as above with fonts
• Sprite class: has a SDL_Rect wich is used to render the sprite and also for collision and all the flags like is_solid is_transparent is_animated
• Tile class: same as above (infact i think i should link Sprite and Tile together in some way)

And that's the basic structure (wich is probably bad), what do you think?

Also i have a question about collision... I don't know when to check for collision, I guess i'd have to check inside the main loop if all the sprites in the game are solid and if they are solid if they are colliding with each other OR with the tiles wich are solid... because if i just check for collision on a key down for example, i'm only checking for the player and I want to check for the enemies also...
But that looks like it's gonna eat too much cpu and I'm sure there are better ways to do that.

Thanks in advance, I hope my english is comprehensible.
(This is my first attempt at making a game engine by the way, go easy on me )

[freeworld]

Ask yourself, how will your engine be used to make a game or other type of app? How useful will it be to make the game you want to make? What are you building the engine for.. ie do you have a game in mind, what does that game need?

There's millions of ways to make an engine... or framework. If they accomplish the goal you set out to accomplish then you made it the way it needs to be. Not to be harsh but you post looks like youre staring down the barrel of a loaded gun but have to ask other people how to pull the trigger.

[phantom]

Write Games, Not Engines

You might want to give that a read...

[Stefanoit]

Ask yourself, how will your engine be used to make a game or other type of app?

The engine will be used to make 2d games, at the moment i have one particular game in mind but i want the engine to be flexible.

How useful will it be to make the game you want to make?

I don't know if it'll be "useful", I'm just doing it because I love programming and videogames.

What are you building the engine for.. ie do you have a game in mind, what does that game need?

2d platformer kind of game.

There's millions of ways to make an engine... or framework. If they accomplish the goal you set out to accomplish then you made it the way it needs to be.

Thanks for that.

Not to be harsh but you post looks like youre staring down the barrel of a loaded gun but have to ask other people how to pull the trigger.

I'm just asking to experienced game developers if my design is solid for a good 2d game engine wich would be flexible and also i asked a specific question about collision checking, I naively thought a forum about game development would be a good place for it.

[Stefanoit]

Write Games, Not Engines

You might want to give that a read...

I don't want to delude you but i'm actually making a game alongside the engine... I just want the engine to be usable in the future too.
But nevermind, really....

[simpler]

If you don't got alot of experience in writing 2D game then writing a flexible game engine that can be used in several games is really hard to pull off. Since you said you just started with game development I suggest you write games first. Every game needs some kind of engine, but it's a big difference between an engine made for a specific game and one made for several.

[Stefanoit]

If you don't got alot of experience in writing 2D game then writing a flexible game engine that can be used in several games is really hard to pull off. Since you said you just started with game development I suggest you write games first. Every game needs some kind of engine, but it's a big difference between an engine made for a specific game and one made for several.

Allright thanks.
You can close the topic

[Servant of the Lord]

Several times in the past I've tried to go the route of designing an engine and a game... usually it starts to work at first, but then gets really complicated as unexpected things pop up.
Currently, I'm writing a game, and I'm doing my best to keep my code clean and concise. As I'm writing the game, I see logically how it's separating into three different types of code: general code, genre-specific code, and game-specific code. So I then separate those types of code into three different folders (which I call, 'Common', 'Engine', and 'Game', respectively).

As I'm writing my game, the engine falls out of it if the game is coded well. If the game isn't coded well, me trying to make an engine will result in an engine that isn't coded well and can't be used anyway.

Your solutions are:
1) Code a game poorly. Result: You have a completed game.
2) Code an engine poorly, and a game alongside it. Result: You have a not-working engine, and stop working on the game, because the engine doesn't work.
3) Code a game properly. Result: You have a completed game... and a completed engine that pops out of nowhere!
4) Code an engine properly. Result: You have an completed engine. But to code an engine properly, you have to have experience coding a finished game properly in the past anyway, so you are probably a professional already.

The game to learning how to make good game engines in the future is to make good games in the present. If you aren't focusing on the game, then all you are doing is making a fancy API by wrapping whatever API you are already using.

Also i have a question about collision... I don't know when to check for collision, I guess i'd have to check inside the main loop if all the sprites in the game are solid and if they are solid if they are colliding with each other OR with the tiles wich are solid... because if i just check for collision on a key down for example, i'm only checking for the player and I want to check for the enemies also...

After a keypress, call something like Player->Move(). After the AI thinks, the AI calls something like Enemy->Move(). The 'Move()' function could check for collision, not the keypress handling function.

But that looks like it's gonna eat too much cpu

If your CPU can run advanced 3D games from two or three years ago, why worry about a few 2D images like what they used to make 20 years ago?
It can handle your game. Only start optimizing your game when your game drops below 20 frames per second. Otherwise, wait until your game is
complete, then optimize it using a proper profiler, not guesswork.

And that's the basic structure (wich is probably bad), what do you think?

Don't second guess yourself or put yourself down. Just run hard, and when you hit a wall, dust yourself off and run again.
It's good to have something to run toward, though, otherwise you are running at the wrong goal. Making an engine, even for learning, isn't the best goal. It's an 'acceptable' goal, but a better goal is to make a game. Simple and friendly advice that a lot of people are offering you - you can accept it, reject it, or store it away for later, it's your call!

I fully understand the desire to make an engine because it sounds so cool. Just don't let it stop you from making your game; and if you fail, don't let it stop you from picking yourself up again, and if you succeed, don't let it go to your head.

[Postie]

I can understand where you're coming from with the question you posed, however it is very hard to answer, which is the reason some of the responses haven't been to your liking it seems.

I'm a programmer in my day job (not games though), but in my spare time I have coded several games projects, and my advice to you is to go ahead and write the game and not dwell too much on trying to making an awesome engine to run it. You'll make mistakes, but that's the way we learn what works and what doesn't. It takes a great deal of talent and experience to build a reusable, extensible framework and it's not a realistic goal as a first project to be honest.

That said, the classes you've described sound ok to me. Once you get cracking on the project you'll find you need a whole bunch more classes you never even considered, but that's the nature of coding where the design is in your head, not specced out by a designer into a 200 page requirements document.

Re: Collisions, typically collision detection is done in the main game loop, once per frame. Modern hardware should be able to handle even fairly naive brute-force tests here, if performance is an issue there are plenty of optimisations you can do.

Good luck!

[berniek]

As others have pointed out, why reinvent the wheel. For 2d platformer there are the HGE or Löve engine. Both are very good. Just recently checked them out.

[Riztro]

As others have pointed out, why reinvent the wheel. For 2d platformer there are the HGE or Löve engine. Both are very good. Just recently checked them out.

But the whole point of creating things is to learn. You should only use an engine if you can code your own. This is almost the same as saying, just use Game Maker instead of learning c++ and OpenGL/Window system because it is easier.

[Postie]

Depends on what your end goal is. If you want to get a game made as quickly as possible, an existing engine plus content generation tools are the way to go. On the other hand, a lot of the skills you walk away from the project with are suited to that specific framework.

[Tom KQT]

Write Games, Not Engines

As others have pointed out, why reinvent the wheel. For 2d platformer there are the HGE or Löve engine. Both are very good. Just recently checked them out.

Two thoughts on that:

- If people weren't reinventing the wheel, our cars would still have stone or wooden wheels. Yes, the chance that you will come with something better than what already is out there isn't such big, but it still exists.

- When someone decides to make a game, his primary goal does not have to be to have the game done to be able to play it or share it. His primary goal can be to make the game. That can be the fun for him, to create the game, including his own engine or whatever. And actually finishing the game doesn't have to be a crucial part of it.

And a bit to that article:

So my advice to you, if you’re trying to write an engine, is: Don’t. No matter what your reasons are — it doesn’t matter if you’re writing an engine so you can write your dream game, or if you’re writing an engine because you think it will be a good learning experience, or any number of similar reasons. They’re all wastes of time.

So writing a game engine isn't a good learning experience? Yes, it might be not the best learning experience about "how to make good games". But it certainly is a good experience in more general meaning.
It sounds really mean - I don't care how good reasons for making an engine you have, you definitely are wrong and I am right when I say that you shouldn't even try to make your own engine. No matter how much you in fact want to make an engine and not a game because you feel more like a programmer and not game maker or whatever.

[DarklyDreaming]

Write Games, Not Engines

As others have pointed out, why reinvent the wheel. For 2d platformer there are the HGE or Löve engine. Both are very good. Just recently checked them out.

Two thoughts on that:

- If people weren't reinventing the wheel, our cars would still have stone or wooden wheels. Yes, the chance that you will come with something better than what already is out there isn't such big, but it still exists.

- When someone decides to make a game, his primary goal does not have to be to have the game done to be able to play it or share it. His primary goal can be to make the game. That can be the fun for him, to create the game, including his own engine or whatever. And actually finishing the game doesn't have to be a crucial part of it.

And a bit to that article:

So my advice to you, if you’re trying to write an engine, is: Don’t. No matter what your reasons are — it doesn’t matter if you’re writing an engine so you can write your dream game, or if you’re writing an engine because you think it will be a good learning experience, or any number of similar reasons. They’re all wastes of time.

So writing a game engine isn't a good learning experience? Yes, it might be not the best learning experience about "how to make good games". But it certainly is a good experience in more general meaning.
It sounds really mean - I don't care how good reasons for making an engine you have, you definitely are wrong and I am right when I say that you shouldn't even try to make your own engine. No matter how much you in fact want to make an engine and not a game because you feel more like a programmer and not game maker or whatever.

You took that quote out of context. Here is the entire quote:

So my advice to you, if you’re trying to write an engine, is: Don’t. No matter what your reasons are — it doesn’t matter if you’re writing an engine so you can write your dream game, or if you’re writing an engine because you think it will be a good learning experience, or any number of similar reasons. They’re all wastes of time. You can sit down and write a game without writing a pre-written engine, and in fact this is very often the better approach, regardless of why you want to write an engine. The entire development process goes much more smoothly if you are focused on writing a game instead: a game is much easier to identify requirements for, much narrower in focused, much more rewarding when finished, and much, much more useful.

...which clearly states exactly what the entire article is trying to get across: write games, which you can then refactor into oh, say, an engine! Instead of writing an engine upfront thinking that is "how it's done" and then working around the horrible quirks that are a result of a poorly designed engine. Or hell, you can just skip the entire thing all together and use something that already has been written. Point is, there is no reason to write an arbitrary engine to fit some imaginary requirements (and they are just that, imaginary, until you know what that particular genre requires of a game engine!) when you could be spending time writing a game instead! If all you want is an engine, fine, go ahead. We're not stopping you from wasting your time. But why not spend it wisely where it matters? Experimenting, researching, writing games. The "engine" will come naturally after you've done those things

[Tom KQT]

I admit that I misunderstood the article a bit (frankly, I didn't read it thoroughly the first time). I thought it was about using existing engines and making a game.

So, the author is saying that you shouldn't make an engine just to have an engine - and to make the engine "blindly" without actually building it for, and together with, a particular game. He says that it is prefered to make a game and an engine will come as a "side effect". I agree with that.

But it sounds that Stefanot actually wants to make a game, not just an engine. It sounds (I may be wrong of course) that he wants to make his game and his little engine for that game, not a fully featured engine which he would LATER use for his game.

And if you don't want to hard-code the whole game (alhough it is also possible and IMHO it's a good start if you are new to 3D programming for example) which would make a hard-to-read, hard-to-expand and almost-impossible-to-reuse code, you simply have to make an engine. Although here I must again agree with the article, specifically with its beginning, that the term "engine" is not so unambiguous.

[Domx]

But the whole point of creating things is to learn. You should only use an engine if you can code your own. This is almost the same as saying, just use Game Maker instead of learning c++ and OpenGL/Window system because it is easier.

While we're at it, why not use assembler instead of higher level languages? I mean, if you can't create your own programming language, why use C++?
We're all standing on the shoulders of giants and we should make the most of it. And constant reinventing of the wheel is definately not the answer, that's not what progress is about.

[Stefanoit]

Looks like i was totally misunderstood, I am making the engine alongside the game, I'm not just making the engine alone... The fact that got all of this started was that i said that i wanted to make it flexible and reusable, I think that's the goal of every programmer when they write software or at least it's my goal everytime i write software, I don't honestly care if you think it's too hard, I know it's hard, so what? I like challenges, and I really do. I'm not full of myself or anything like that, else i wouldn't be here...

Also I do it because it's fun, my goal is not only to make a game (i would have used XNA or game maker to just make a game quick), my goal is also to make it nearly from scratch, it's a challenge, it's strange that noone really understands that sometimes you just wanna do something because it's fun and/or challenging, not just to learn or to produce something, and by the way, I am learning a lot from this, I'm doing mistakes, correcting them and I'm understanding more and more every day about how games really work.

I posted here (honestly) because I wanted to join a gamedev community, I rewrote most of the engine and got collision working, I'm currently always working on the engine/game when i'm at home and yea... it's fun

[SaLiVa]

Write Games, Not Engines

You might want to give that a read...

Hi, I read through that article and I understand it completely. I've been wasting my time trying to figure out the ugly innards of OpenGL 4.1 and Direct X 11 with no real sense of achievement.

I didn't understand the last part of the article however. Do I choose a pre-existing engine such as UDK or Unity and write a game or make a game from scratch building on the foundations of the game engine as needed?

[Domx]

Hi, I read through that article and I understand it completely. I've been wasting my time trying to figure out the ugly innards of OpenGL 4.1 and Direct X 11 with no real sense of achievement.

I didn't understand the last part of the article however. Do I choose a pre-existing engine such as UDK or Unity and write a game or make a game from scratch building on the foundations of the game engine as needed?

Both ways are perfectly valid. Since the article article attempts to encourage a shift from engine-first development to writing games, their suggestion is more of the second option. Write a game and get the next one running on some reusable parts of the first one. And so on, until you end up with several reusable systems that you can bundle together and call them an engine. However, unless you want to challenge yourself or are really hell-bent on writing an engine, it's probably better to pick an existing engine, with some kind of track record and community, and use it to make great games.

[MeshGearFox]

Sometimes trying to reinvent the wheel is very informative, because even if you don't end up inventing a BETTER wheel, you will know how to BETTER USE the existing wheels.