• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Pmega35

Engine Programming

24 posts in this topic

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:

[list=1][*]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)[/list]
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 [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img])
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='freeworld' timestamp='1301252057' post='4791038']
Ask yourself, how will your engine be used to make a game or other type of app?
[/quote]

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.

[quote name='freeworld' timestamp='1301252057' post='4791038']
How useful will it be to make the game you want to make?
[/quote]

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

[quote name='freeworld' timestamp='1301252057' post='4791038']
What are you building the engine for.. ie do you have a game in mind, what does that game need?
[/quote]

2d platformer kind of game.

[quote name='freeworld' timestamp='1301252057' post='4791038']
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.
[/quote]

Thanks for that.

[quote name='freeworld' timestamp='1301252057' post='4791038']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1301252808' post='4791043']
[url="http://scientificninja.com/blog/write-games-not-engines"]Write Games, Not Engines[/url]

You might want to give that a read...
[/quote]


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....
0

Share this post


Link to post
Share on other sites
If you don't got alot of experience in writing 2D game then writing a [i]flexible [/i]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 [i]games[/i] 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.
0

Share this post


Link to post
Share on other sites
[quote name='simpler' timestamp='1301254088' post='4791053']
If you don't got alot of experience in writing 2D game then writing a [i]flexible [/i]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 [i]games[/i] 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.
[/quote]

Allright thanks.
You can close the topic [img]http://public.gamedev.net/public/style_emoticons/default/rolleyes.gif[/img]
0

Share this post


Link to post
Share on other sites
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 [i]game[/i], 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.[img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]

Your solutions are:
[b]1)[/b] Code a game poorly. [b]Result:[/b] You have a completed game.
[b]2) [/b]Code an engine poorly, and a game alongside it. [b]Result: [/b][size="2"][color="#1C2837"]You have a not-working engine, and stop working on the game, because the engine doesn't work.[/color][/size]
[size="2"][color="#1C2837"][b]3)[/b] Code a game properly. [b]Result: [/b]You have a completed game... and a completed engine that pops out of nowhere![/color][/size]
[size="2"][color="#1C2837"][b]4) [/b]Code an engine properly. [b]Result: [/b]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.[/color][/size]
[size="2"] [/size]
[size="2"][color="#1C2837"]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.[/color][/size][img]http://public.gamedev.net/public/style_emoticons/default/mellow.gif[/img]
[size="2"] [/size]
[size="2"][color="#1C2837"][quote]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...[/quote][/color][/size]
[size="2"][color="#1C2837"]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.[/color][/size]
[size="2"] [/size]
[size="2"][color="#1C2837"][quote]But that looks like it's gonna eat too much cpu[/quote][/color][/size]
[size="2"][color="#1C2837"]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?[/color][/size]
[size="2"][color="#1C2837"]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[/color][/size]
[size="2"][color="#1C2837"]complete, then optimize it using a proper profiler, not guesswork.[/color][/size][img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
[size="2"] [/size]
[size="2"][color="#1C2837"][quote][/color][/size][color="#1C2837"][size="2"]And that's the basic structure ([b]wich is probably bad[/b]), what do you think?[/size][/color][color="#1C2837"][size="2"][/quote][/size][/color]
[size="2"][color="#1C2837"]Don't second guess yourself or put yourself down. Just run hard, and when you hit a wall, dust yourself off and run again.[/color][/size]
[color="#1C2837"][size="2"]It's good to have something to run [/size][i]toward[/i][size="2"], 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![/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]I fully understand the desire to make an engine [/size][i]because it sounds so cool. [/i][size="2"]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. [/size][/color][img]http://public.gamedev.net/public/style_emoticons/default/tongue.gif[/img][size="2"] [/size]
2

Share this post


Link to post
Share on other sites
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!
2

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='berniek' timestamp='1301275844' post='4791167']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
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.



0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1301252808' post='4791043']
[url="http://scientificninja.com/blog/write-games-not-engines"]Write Games, Not Engines[/url]
[/quote]
[quote name='berniek' timestamp='1301275844' post='4791167']
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.
[/quote]

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 [i]make[/i] 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:
[quote]So my advice to you, if you’re trying to write an engine, is: [i]Don’t[/i]. 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.[/quote]
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.
1

Share this post


Link to post
Share on other sites
[quote name='Tom KQT' timestamp='1301296766' post='4791228']
[quote name='phantom' timestamp='1301252808' post='4791043']
[url="http://scientificninja.com/blog/write-games-not-engines"]Write Games, Not Engines[/url]
[/quote]
[quote name='berniek' timestamp='1301275844' post='4791167']
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.
[/quote]

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 [i]make[/i] 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:
[quote]So my advice to you, if you’re trying to write an engine, is: [i]Don’t[/i]. 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.[/quote]
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.
[/quote]

You took that quote out of context. Here is the [i]entire[/i] quote:
[quote][size="2"][font="Times New Roman"][color="#FFFFFF"]So my advice to you, if you’re trying to write an engine, is: [i]Don’t[/i]. 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. [b]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 [i]much [/i]more smoothly if you are focused on writing a [i]game[/i] instead: a game is much easier to identify requirements for, much narrower in focused, much more rewarding when finished, and much, much more useful.[/b][/color][/font][/size][/quote]
...which clearly states exactly what the entire article is trying to get across: write games, which you can then [i]refactor into oh, say, an engine! [/i]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 :)
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='TTT_Dutch' timestamp='1301283679' post='4791193']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
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 [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]
0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1301252808' post='4791043']
[url="http://scientificninja.com/blog/write-games-not-engines"]Write Games, Not Engines[/url]

You might want to give that a read...
[/quote]
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?
0

Share this post


Link to post
Share on other sites
[quote name='SaLiVa' timestamp='1301361252' post='4791555']
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?
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
Why don't you want to have your own engine which uses other libraries like sfml or allegro?

0

Share this post


Link to post
Share on other sites
[quote name='Domx' timestamp='1301313759' post='4791292']
[quote name='TTT_Dutch' timestamp='1301283679' post='4791193']
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.
[/quote]

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.
[/quote]

Sorry I wasn't very clear. I mean that with this guys goal, he wants to learn how to make games. Now making games in the industry does consist of re-inventing the wheel a little. There comes a point where it is useless to re-invent something just for the purpose of creating games. Like inventing another c++ just for a game. I mean if this guy wanted to learn to make games with assembly then you would be right, but who wants to do that? This guy learned c++ and he should use the basic tools that are used in the industry (such as c++, platform specific windowing system, and OpenGL/Directx) to learn to make games.
0

Share this post


Link to post
Share on other sites
[quote name='MeshGearFox' timestamp='1301427703' post='4791859']
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.
[/quote]

You just posted what I meant to say, but shorter. :)
0

Share this post


Link to post
Share on other sites
[quote name='Servant of the Lord' timestamp='1301262360' post='4791095']
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 [i]game[/i], 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.[img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]

Your solutions are:
[b]1)[/b] Code a game poorly. [b]Result:[/b] You have a completed game.
[b]2) [/b]Code an engine poorly, and a game alongside it. [b]Result: [/b][size="2"][color="#1C2837"]You have a not-working engine, and stop working on the game, because the engine doesn't work.[/color][/size]
[size="2"][color="#1C2837"][b]3)[/b] Code a game properly. [b]Result: [/b]You have a completed game... and a completed engine that pops out of nowhere![/color][/size]
[size="2"][color="#1C2837"][b]4) [/b]Code an engine properly. [b]Result: [/b]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.[/color][/size]

[size="2"][color="#1C2837"]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.[/color][/size][img]http://public.gamedev.net/public/style_emoticons/default/mellow.gif[/img]

[size="2"][color="#1C2837"][quote]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...[/quote][/color][/size]
[size="2"][color="#1C2837"]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.[/color][/size]

[size="2"][color="#1C2837"][quote]But that looks like it's gonna eat too much cpu[/quote][/color][/size]
[size="2"][color="#1C2837"]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?[/color][/size]
[size="2"][color="#1C2837"]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[/color][/size]
[size="2"][color="#1C2837"]complete, then optimize it using a proper profiler, not guesswork.[/color][/size][img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]

[size="2"][color="#1C2837"][quote][/color][/size][color="#1C2837"][size="2"]And that's the basic structure ([b]wich is probably bad[/b]), what do you think?[/size][/color][color="#1C2837"][size="2"][/quote][/size][/color]
[size="2"][color="#1C2837"]Don't second guess yourself or put yourself down. Just run hard, and when you hit a wall, dust yourself off and run again.[/color][/size]
[color="#1C2837"][size="2"]It's good to have something to run [/size][i]toward[/i][size="2"], 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![/size][/color]

[color="#1C2837"][size="2"]I fully understand the desire to make an engine [/size][i]because it sounds so cool. [/i][size="2"]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. [/size][/color][img]http://public.gamedev.net/public/style_emoticons/default/tongue.gif[/img]
[/quote]


Thanks for the idea, but I have a question.
Say your making an FPS. Would window handling, menu system, subscription system (you can "subscribe" functions to be called during the game loop), and sound system be in common folder? And then the AI, Collision, Rendering system, and (I don't know what else is part of a game) in the Engine folder. And then the main game loop and logic in the game folder?
0

Share this post


Link to post
Share on other sites
[quote name='TTT_Dutch' timestamp='1302049133' post='4794832']
[quote name='Servant of the Lord' timestamp='1301262360' post='4791095']
Currently, I'm writing a [i]game[/i], 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).
[color="#1C2837"] [/color][/quote]
Thanks for the idea, but I have a question.
Say your making an FPS. Would window handling, menu system, subscription system (you can "subscribe" functions to be called during the game loop), and sound system be in common folder? And then the AI, Collision, Rendering system, and (I don't know what else is part of a game) in the Engine folder. And then the main game loop and logic in the game folder?[/quote]
Well, this is my first time doing it this way, so I'm working it out as I go. [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]
I've moved some chunks of code back and forth between 'Engine' and 'Game' several times, struggling to find the balance between "Logically it should go in 'game', but class 'x' in Engine needs to access it, so I have to put it in 'Engine'" and similar problems. (Anything in 'Common' can only access other stuff in 'Common' (or any external libraries), anything in Engine can only access other stuff in 'Engine' or stuff in 'Common', anything in 'Game' can access anything in 'Game', 'Engine', or 'Common' - this helps me make each separate part of the code self-contained, and to reduce dependencies).
The main loop in my code is actually outside all three folders, though it could just as easily be in 'Game'.

One example of struggling to find the balance and moving files back and forth is my 'Player' class. Does the Engine know about the Player or only the Game? All 2D RPGs will have a Player, so I'd prefer for it to be in 'Engine'. On the other hand, different games will have the Player have different stats. Game A might use 'Defense', 'Strength', and 'Agility', but Game B could be entirely different! So it should go in the 'Game' folder... except I figured out a (clean, concise, and logical) way to make Player be in 'Engine' and leave his stats undefined, so I went with that and put him back in Engine. I may encounter problems with that method down the line, and be forced to move the Player class back to 'Game' - we'll see. [img]http://public.gamedev.net/public/style_emoticons/default/cool.gif[/img]
I went through something similar with my 'GameStructure' class that ties the different parts of my program together. Since it 'owned' the player, every time I moved the player, I had to move the GameStructure too.[img]http://public.gamedev.net/public/style_emoticons/default/laugh.gif[/img] An alternative option, might be to have a GameState own the player, or make Player global in 'Game' (though I'm trying to avoid globals (with some exceptions like my logger).

My current setup is this:
In "Common" I basically have stuff like my Lua binding code, my logging code, my different structs (Color, Point, Rect, Size, etc...),


[b]Common:[/b]
- Logger
- Scripting
- String (string conversion (bool to string, point to string, etc...), and string flags (used in a dozen places to store information in a textual format))
- Types
- ConfigFile
- RichTextFile
- Image
- Time
- FormattedTime
- Basic Types
- Color
- Fraction
- Point
- Rectangle
- Size

[b]Engine:[/b]
- Window
- Animation + Animator
- Localizer
- World
- 12 visual representation of the world classes.
(Area -> Chunk -> Floor -> Layer -> Tile, tile image caching, tile special attributes, tile animating, etc...)
- Collision with world classs
- Structure
- Camera
- Avatar
- GameFlags
- GameState + GameStateManager
- 'GameStructure' class that ties the various pieces of the engine together.

[b]Game:[/b]
- States
- Exploring (currently my only game state)
('Game' will soon receive more classes - currently, I have a few game-specific classes in 'Engine' that I need to move to 'Game', but also 'Game' will grow once I get past my current Todos and start adding more game specific features)

Outside of any folder is 'main' (but it could easily be part of 'Game' and would make sense for it to be - I may move it there in the future), which loads the primary resources, initializes the logging, and then pushes the first GameState onto the GameStateManager, kicking off the program execution.

Looking at 'Common', 'Engine', and 'Game', 'Common' is the biggest as it's the most generic. 'Engine' is next largest (and is almost equal to 'Common'), and 'Game' is least. This makes sense, and makes the code re-usable, and visually tells me what code I may want to use for future projects and which code probably wont be helpful. I expect 'Common' to grow, but I think 'Engine' will out-pace it as my game gets closer to completion. If I was focusing on making a generic "Game Engine", I'd probably fall into the trap of adding feature after useless feature, and actually end up making lots of "Common" code, and less "Engine" code, and no "Game" code. But by focusing on the end-product, "Game", 'Engine' automatically comes about, and 'Common' springs from 'Engine'.


'Common' for me is self-contained and isolated classes or functions that mostly function on their own (ConfigFile class, or the three self-contained but complimentary scripting related classes). They are tools to be used. Engine is the actual structure of a game, and instead of being a generic game, hones in specifically to the type of game I'm making: A turn based RPG with a 2D tile-based world. Game is only the specifics of the current game that aren't common to most 2D turn based RPGs, and only common to [i]this[/i] turn based RPG.

So, to answer your question:
[quote]Say your making an FPS. Would window handling, menu system, subscription system (you can "subscribe" functions to be called during the game loop), and sound system be in common folder? And then the AI, Collision, Rendering system, and (I don't know what else is part of a game) in the Engine folder. And then the main game loop and logic in the game folder?[/quote]
Everything you described for 'Common' actually would be part of 'Engine', if I was doing it. But your 'Vector3D' and 'Matrix' classes, your self-contained AStar pathfinding classes, and perhaps your generic 'Texture' class, would go into 'Common', along with your self-contained logging system, your generic networking classes (if your API of choice isn't good enough on it's own), and your encryption and compression functions or classes.


It really depends on what feels right, on a case by case scenario. Does it feel self-contained and re-usable even for non-FPS games? Probably goes in 'Common'. Or does it feel like a large 'system' that provides a 'service' (or is it a small class that was created specifically for that system)? Probably goes in 'Engine'.

And just because something goes in 'Game' doesn't mean it *can't* be re-used. My next project will probably have a 'MainMenuState' similar to my current project (once I get around to adding a main menu to my current project), so I'd probably copy and paste that 'MainMenuState' and tweak it for my next project - but everything in 'Engine' I'd probably copy and paste and instead of tweaking to fit my new project, it'd work right out of the box, and I'd [i]build upon it [/i](new engine features) instead of [i]rip stuff out of it [/i](game-specific features).

Again, this is my first time using this system, so I don't know whether it'll prove beneficial in the long run - I only know that it's certainly more organized and maintainable than my previous project. [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] So even if it's a dismal failure compared to what others are using, it's still a big step up for me.[img]http://public.gamedev.net/public/style_emoticons/default/biggrin.gif[/img]
0

Share this post


Link to post
Share on other sites

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  
Followers 0