Sign in to follow this  

Engine Design

This topic is 2846 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. I'm working on building a 2D Game Engine based on the irrlicht 3D Graphics Engine. I'm more or less considering it an unofficial extension to the irrlicht library, so I'm sticking to the rules on their website for extending the engine. However, I want the 2D Engine to be complete, and eventually hope to write a full program with it that has an integrated map editor, as well as event manager, etc. By complete, I mean I would like it to allow one to create RPGs, both classic FF style or Chrono Trigger style, as well as fighting games, scrolling shooters and platformers, and so on. Here's my problem: How should it be structured? I've already written a tile manager that works. I need to streamline it in the future, but it currently correctly performs everything I'd like it to. (More info: http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=37336). What are other important things I need to consider, such as an event manager, perhaps sound. I'm guess I should have a separate hierarchy of classes for handling sprites and their relevant functions. Any suggestions, perhaps a link on in-depth information?

Share this post


Link to post
Share on other sites
Write some examples of the types of games you want your engine to support. Then extract the parts that were common between them. That's really the only way to know what belongs in an engine. Game engines aren't beginner projects. Games can be though.

Share this post


Link to post
Share on other sites
Of course it's not a beginner project, but it's what I'm most interested in at this point. The problem with making a game is that it most often seems to involve opening a world editor (whether 2D or 3D) and doing most of the work there, with subsequent customizations done through scripting.

That's great and all, but I'm more interested in the underlying code and structure that the design of a game. The most I want to know about game design at this particular time is enough to provide all the tools a developer would need in creating their game.

Unfortunately, I don't think your suggestion will help me. I'm not writing for a specific type of 2D game. Either that, or I misunderstand your suggestion, in which case I apologize.

Share this post


Link to post
Share on other sites
Couldn't you just rewrite some of the functions to just ignore the Z? Not sure how expansive that engine is or how in depth you want to go.

I'm not 100% sure why you'd want to extend a 3D engine to do 2D work though. It seems like it would be really inefficient with system resources unless you pretty much rewrote a copy in 2D, which may or may not be worth your time (especially if you're the only person doing anything).

Share this post


Link to post
Share on other sites
Edit: You can disregard this for now. I'm going to read up on a few things and may revive this thread later if needed.

Well, it's a free graphics engine, so that's not a problem. And just writing out the Z simply wouldn't work. I believe it has all of the necessary 2D tools built-in, but it's a graphics engine and I want to make a game engine.

If you take my tile manager as an example (I'm not even sure a tile manager is what I want, but I made it so I had something to get me motivated and started: it uses the 2D aspects of the engine to create a managing system to draw tiles to the screen in an efficient manner, rather than explicitly stating "draw this here, then that there, and then..."

Share this post


Link to post
Share on other sites
Quote:
Original post by Raislin
Well, it's a free graphics engine, so that's not a problem. And just writing out the Z simply wouldn't work. I believe it has all of the necessary 2D tools built-in, but it's a graphics engine and I want to make a game engine.

If you take my tile manager as an example (I'm not even sure a tile manager is what I want, but I made it so I had something to get me motivated and started: it uses the 2D aspects of the engine to create a managing system to draw tiles to the screen in an efficient manner, rather than explicitly stating "draw this here, then that there, and then..."

I think I misunderstood your original question then.

You're main goal is to take a 3D graphics engine and use it in your 2D game engine/editor? And are you looking for a 2D engine or a 2D editor?

Share this post


Link to post
Share on other sites
Raislin, we aren't being critical of your interest (you've explicitly stated your interest is about the underlying tools, not the actual game). But, the thing is, you're making a game engine. In doing so, what you're saying is, "I have an idea of how to approach various design issues common to a set of games".

Then you come here and ask us what that approach is.

Do you see what the issue is? Making a game engine means that you determine the answer to your questions. To ask us defeats the purpose of creating your own game engine...

Share this post


Link to post
Share on other sites
Quote:
Original post by oler1s
Raislin, we aren't being critical of your interest (you've explicitly stated your interest is about the underlying tools, not the actual game). But, the thing is, you're making a game engine. In doing so, what you're saying is, "I have an idea of how to approach various design issues common to a set of games".

Then you come here and ask us what that approach is.

Do you see what the issue is? Making a game engine means that you determine the answer to your questions. To ask us defeats the purpose of creating your own game engine...


I didn't think anyone was being critical. I could go about making the engine the way I think it would be made, but, aside from some aspects that I just don't know about, I'm afraid it'll be bloated and defeat the purpose of using one.

I wouldn't mind making a game first to get myself started, but I really don't want to be using anything that involves using an editor, as that'll ruin the learning process for me. But even this hasn't been pretty much impossible to find good information on. Most books are useless. Or rather, every book I've come across has been useless.

That's why I said to just disregard it for now. I'm going to attempt to go about creating a game, but getting started has wasted so much of my time up until now.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raislin
I could go about making the engine the way I think it would be made, but, aside from some aspects that I just don't know about, I'm afraid it'll be bloated and defeat the purpose of using one.

That's indeed a big risk if you're setting out to build an engine in isolation, yeah. That's why many people here discourage beginners from building engines. You can't build a 'complete' engine anyway: 'complete' differs from game to game. :)

What I've found to be a good approach is to build a simple game first - and then another, reusing some code from the first. Go through a few iterations like that and you'll end up with a framework that has proven itself to be practically useful.

For example, you could find that your tile manager (sprite manager? tile manager sounds similar to tilemap, and that's not what you've got here) is not very practical if you can't determine it's width and height. And in another game, you could see that a tile manager would be more flexible if it had a position of it's own, allowing you to compose levels of multiple tile manager objects. And perhaps tile IDs are too cumbersome to work with? Perhaps drawing big tile collections isn't very efficient, and you'll want to store them in an internal spatial structure? These are things you'll only encounter when you're actually putting it to use.

Quote:
I wouldn't mind making a game first to get myself started, but I really don't want to be using anything that involves using an editor, as that'll ruin the learning process for me.

You'll still learn things - just different things. Which can be a healthy thing: level-design showed me how the various parts of a game come together (AI, art, models, sound, design, etc.). That helped me a lot later on.

Quote:
That's why I said to just disregard it for now. I'm going to attempt to go about creating a game, but getting started has wasted so much of my time up until now.

What problems did you run into? Where did you get stuck? I'm sure we can give some specific advice. :)

Share this post


Link to post
Share on other sites
Quote:
I'm going to attempt to go about creating a game, but getting started has wasted so much of my time up until now.


I can totally relate to that.

When I was first starting I always got lost trying to do basic things like putting pictures on the screen. I never finished anything, because I never got beyond that basic stuff. Then I discovered Flash and could finally focus on making games and not graphics subsystems and so forth. Having had such a good experience with it, if you have the cash to poney up or the open-source know how, I recommend Flash as a good starting point.

Share this post


Link to post
Share on other sites
Quote:
Original post by Captain P
For example, you could find that your tile manager (sprite manager? tile manager sounds similar to tilemap, and that's not what you've got here) is not very practical if you can't determine it's width and height. And in another game, you could see that a tile manager would be more flexible if it had a position of it's own, allowing you to compose levels of multiple tile manager objects. And perhaps tile IDs are too cumbersome to work with? Perhaps drawing big tile collections isn't very efficient, and you'll want to store them in an internal spatial structure? These are things you'll only encounter when you're actually putting it to use.


Actually, there's only meant to be one tilemanager. Basically, a series of textures are stored (basically tilesets) and the tilemanager automatically divides the texture into pieces that can be used as tiles (think RPG maker). The size of the tiles is specified when the texture is loaded. Then tilenodes are created that store the coordinates of the tile's location on the map, the tileset id and the tile id (tileset id specifies which tileset, and the tile id specifies which piece of that tileset) determine what the graphic for that particular node would be.

So it's essentially like pasting a bunch of squares around the screen to make you level. It allows for tiles of different sizes that aren't required to be snapped to a grid of any kind; transparency; and per-tile options, such as visibility, solid/not-solid, etc. Also, a background for something like a classic space-shooter could be a single tilenode that takes up the whole map.

It's pretty nifty because I could write a piece of code to read and write to a file the data that represents a map, and when it comes time for drawing and such, the tilemanager helps automate everything.

I hope that better explains the purpose of the tilemanager. I hope for it to be quite useful for what I currently intend to do. I've decided to cut back on my original goal and first make a very simple 2D RPG and see how that goes. That should give me some more focus.

Quote:
Original post by juanpacoI can totally relate to that.


Flash worked for you and that's what this 3D engine is doing for me. Why am I using the 3D graphics engine to do this? It's quite simple: I want to make 3D games! But before I worry about models and levels, I want to understand what goes into making a game first other than the graphics. Irrlicht will streamline and simplify that aspect, so I can focus on other design aspects.

Quote:
What problems did you run into? Where did you get stuck? I'm sure we can give some specific advice. :)


The problems I ran into are those that I'm seeking to solve in this thread. If I make a game, I need to know all the general things that need to be handled. But I'm going to take the advice of starting with one game and generalizing as I go. I think that will probably be the best solution. Unfortunately, this seems to be a trial-and-error thing, as the resources for programming games online and in textbooks focus entirely too much on how to do graphics.

Share this post


Link to post
Share on other sites
I understood the purpose of your tilemanager - I've got a class somewhere that does more or less the same. Indeed, such things are easy to fill in from a file or some other input source, and easy to work with. :)

But my point was this: you may be happy with your current design, but it's only when you use it that you find out how good it really is. That's why I'm mentioning things like having multiple tilemanager objects and underlying optimizations - these are things I found out to be useful when I used my SpriteCollectionObject class in some games. So yeah, just streamline it when you need to. :)

In fact, after a few iterations, I came to a design that contained both a TilemapObject and a SpriteCollectionObject (and various other visual objects) - which can be used alongside each other, to create loosely patched levels divided into multiple areas. Now that I think of it, unloading a section would be quite easy: I only need to remove one SpriteCollectionObject (and the associated collision data and entities of course)...


Quote:
The problems I ran into are those that I'm seeking to solve in this thread. If I make a game, I need to know all the general things that need to be handled. But I'm going to take the advice of starting with one game and generalizing as I go. I think that will probably be the best solution. Unfortunately, this seems to be a trial-and-error thing, as the resources for programming games online and in textbooks focus entirely too much on how to do graphics.

May I suggest to start with a simple game - just the core elements? The average RPG is quite content-intensive - I'm just finishing up one and if you're not taking care of processing that data properly it'll quickly bite you. You'll need to think about tools and content management and all that, on top of getting a basic game structure up and running...

I mean, silly as it sounds, a 2D pong game still needs a main game loop, input handling, graphics and some game-logic. Without too much complexity to distract you you can focus on structuring that nicely. A state machine for the various menus, an input module that allows other code to listen for events rather than a polling system, game-code that doesn't rely too intimately on rendering implementation details... There's tutorials for these kind of games, you may benefit from them. Just get the basics right and work your way up from there. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Captain P
I mean, silly as it sounds, a 2D pong game still needs a main game loop, input handling, graphics and some game-logic. Without too much complexity to distract you you can focus on structuring that nicely. A state machine for the various menus, an input module that allows other code to listen for events rather than a polling system, game-code that doesn't rely too intimately on rendering implementation details... There's tutorials for these kind of games, you may benefit from them. Just get the basics right and work your way up from there. :)


Sounds good. I might do that. But I was really only going to do something as simple as having a small room that you can walk around in, a single NPC to talk to and perhaps a battle with the most simple monster AI I could write (basically hard-coded attack order). However, if you're able to link me to one of these tutorials, perhaps I'll definitely start with that to get me going.

I'm not sure what you meant by an input module and a polling system. Handling events is definitely one thing I'm iffy on, though. Irrlicht has a built in class that you derive from to handle events, such as input, that I was planning on using for now.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raislin

Sounds good. I might do that. But I was really only going to do something as simple as having a small room that you can walk around in, a single NPC to talk to and perhaps a battle with the most simple monster AI I could write (basically hard-coded attack order). However, if you're able to link me to one of these tutorials, perhaps I'll definitely start with that to get me going.

I'm not sure what you meant by an input module and a polling system. Handling events is definitely one thing I'm iffy on, though. Irrlicht has a built in class that you derive from to handle events, such as input, that I was planning on using for now.


I don't know much about this stuff (as you know I am still working on basic class stuff). However I talked to a friend (who knows how to code but is a grumpy bastard) awhile back about making a 2d rpg type deal like you are describing. I think what he said (and what others have said) is that a "room" is just a picture made out of tiles. When you hit the "d" key your avatar (in this case a sprite I think) changes positions and moves to that tile. (if (key_down = "LEFT"){myAvatarXCoord++;} or something along those lines. If you are just using 2d then maybe SFML/SDL or something like the garage games engine may fit what you need.

This may be completely off from what you are looking for but I thought I would try to help out :)

Share this post


Link to post
Share on other sites

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