2D Game Engine

[xander333]

I'm currently writing my own game engine in SFML and I was thinking: what exactly does a game engine NEED?

So far, i have:
- State Management
- Resource Management

Not much, I know but I'm just starting out!
Please suggest some features :)

[hanst99]

I figured that a good way to start writing a game engine would to be write some games, find patterns and put them together in some reusable form.

[xander333]

I did, and those 2 things were the only thing they resembled...

EDIT: 500 posts :)

[hamsterman]

Assuming a platform game, you'll probably want to write some collision code, something to simplify writing ai, which could extend to writing a, possibly event based, system for handling animations and sounds, and maybe simple physics.
Assuming a 3d thing, there is a ton to do with graphics too.

[chrisname]

It depends on how complex you want to make it.

Other things to consider than what you have already:
1. A rendering engine (wrap SFML); this might come under resource management
2. A physics engine
3. A scripting engine (embed Python or Lua)
4. Interfaces (IDrawable, , etc.) and base classes (Sprite, Actor, etc.)
5. Tools (ideally written in something other than C++; I think C# is commonly used in the industry)

I'm currently trying to write a game engine in C# with IronPython as a scripting language (someone here unkowingly gave me the idea) which uses the OpenTK library (a .Net wrapper for OpenGL, OpenAL and some other libraries), the .Net framework (obviously), IronPython, and Microsoft's Scripting library.

[hanst99]

I'd probably write something to make integration of Haskell functions easier. But that's me.

[chrisname]

Why Haskell?

[Computergeek01]

I'm doing something like this myself with SFML and I have yet to run into the need for a scripting language. Is this just a round about way to not have to recompile your code? Maybe what I'm writing isn't so much a "Game Engine" as it is a game written in C++.

@ xander333: Like I said I'm doing something simular and I'd have to say the most useful component I've planned out is my Image parser. What I plan on doing is taking the first pixel at 0,0 with "GetPixel()" and then searching for that color along the top row ('X') of pixels in the image, while 'X' is less then the value returned by "GetWidth()", to determine the width of the frames for my sprites. This prevents me from having to hardcode the width of each frame for each Actor in my game. Since my collision detection is done by offsetting the height and width of the value from from "GetPosition()" on the Sprite I might even do something with variable sizes of the Sprite, like is he laying down? or standing up? It's the little stuff like this that makes planning a game engine fun for me.

[chrisname]

Computergeek01 wrote:

I have yet to run into the need for a scripting language. Is this just a round about way to not have to recompile your code?

Scripting languages are good for a few things:
- Scripted events
- Actors' AI (I'm using F# for that probably; maybe Lisp if there's a Lisp.Net compiler or something :P)
- Game modifications
- Simplifying game development (non-performance-critical parts of games can be written in a higher-level language)
- Game engine scripts (describing to the engine what it needs to load, etc.; this wouldn't be a true scripting language, but something far simpler).

Computergeek01 wrote:

taking the first pixel at 0,0 with "GetPixel()" and then searching for that color along the top row ('X') of pixels in the image, while 'X' is less then the value returned by "GetWidth()"

I don't understand.

[Computergeek01]

"GetPixel()" is an SFML function that returns a color code from the image you use it on based on the color of the pixel indicated by the position you pass it. My Image parser isn't done yet but I plan on building it around this idea. Something like this:

FRAME::FRAME(sf::Image* img, FRAME Frame): Top(0), Left(Frame.Right), Bottom(img->GetHeight())
{
   Right = 0;
   
  sf::Color Parse(img->GetPixel(0,0);
   
   int X = 1;
   while(img->GetPixel(X, 0) != Parse && X < img->GetWidth())
   {
        X++;
    }

    Right = X;
}

Or something like that. It's not finished yet, and I don't have the code in front of me (I'm at work) but this is what I remember. Basically I have the class 'FRAME' holding four integers that describe for my Sprite the dimensions of each frame based soley on the image I feed it. This frees me from hard coding the dimensions and allows me to do different things based on the size and shape of the images.

[chrisname]

What I don't understand is how that helps you calculate the width of the frame. Why not just store sprites as .gif images and use the size of the largest frame? GIF images also support transparency.

[Computergeek01]

I guess I just didn't do that :p. The origional idea behind doing it this way was that I thought I might have the same Sprite\Actor using multiple frame sizes based on wiether they are standing up, laying down, jumping, ducking etc. My collision detection is based on the offset of the Sprites position plus the height and width of the currently loaded frame.

[chrisname]

I don't get how that method does what you say it does, though.

Here's an idea:
You have an archive file which contains a text file containing a list of frames, and for each frame there is a .tga image and a .dat file. The .tga image is the actual frame, and the .dat file describes the drawable part of the frame.

That's what I'm going to do.

[Computergeek01]

That's seems workable, I'll keep it in mind when my graphics become more advanced in case my current model isn't workable anymore. Right now I'm litterally using stick figures that I hand drew in .PNG format on MS Paint as stand ins. Like I said before I'm not a graphics guy, if this project looks like it will go somewhere I'll consider comissioning someone to draw the pretty pictures for me.

I am kind of proud that as of right now with 200+ Actors drawn to the screen and interacting with eachother my memory Working Set hovers somewhere around 8MB :D! This may have more to do with the simplicity of my images then my programming skill but I thought it was cool.

[chrisname]

That's impressive only if the sum of the sizes of the images is more than or equal to 8 MB.

[hanst99]

@chrisname

Because some things are just ridiculously easy to implement in Haskell. Of course it's not actually a necessary component, but I like the language a lot so I'd love to have some easy way of incorporating high level components written in Haskell into C++ (right now I do it in some strange kinda way where I have to write C wrappers for the wrappers created by GHC, and then finally write another C++ wrapper around it... that's kinda messy though).

[Computergeek01]

I would say that hitting the disk every time you need to load an image is actually the opposite of impressive. But I think I get what you are saying in that only loading the parts or your project that you are working with is an indication of your skill. In my case I'm only currently working with 3 PNG files, the overhead from SFML is actually the majority of my footprint so what you are suggesting isn't physically possible... yet. I have a butt load of optimizing to do, and probably some questions to ask in regards to in-lining virtual functions, but I do plan on posting my code here eventually for anyone who cares enough to laugh at it :P.

[chrisname]

Yeah, I was joking :P

If the size of the images was >= 8 MB there'd be no memory for anything else.

[ireni]

Just take a look here :

http://hge.relishgames.com/

It's a free opensource C++ 2D game engine based upon DirectX.

An OpenGL UNIX port is available here :

http://icculus.org/hge-unix/

Enjoy.

[1yR4jE8b]

(someone here unkowingly gave me the idea)

Don't worry, I'm completely aware ;)