views:

3253

answers:

15

Ok, so I ended up writing my own game engine based on top of XNA, and I am just wondering what else I need to make a complete engine.

This is what's in the engine:

  • Physics (Farseer Physics)
  • Particle Engine (Mercury Project)
  • 2D Cameras
  • Input Handling
  • Screen Management (Menus, Pause Screen, etc.)
  • Sprite ( Animation, Sprite Sheets)
  • And XNA stuff like Sound.

Am I missing anything that might be crucial to a game engine?

+1  A: 

3d Acceleration should be in a 2D engine.

Using the 3d hardware that most people have these days is the best way to get amazing performance for your 2D games...

dicroce
Do you have an example of how that would occur?
Khalid Abuhakmeh
Xna already use 3d acc. So this is automaticly build in. Really this just mean that it uses the gpu - in my understanding
Jesper Blad Jensen aka. Deldy
Indeed, XNA Sprites are already done through 3D acceleration, so you don't need to worry about this.
Marcel J.
As mentioned use XNA. Of course, you can always think of a sprite as a texture on a surface that is perpendicular to the screen with some alpha. Doing things this way means you get scaling and rotation nerarly for free, and loads of HW acceleration.
dicroce
+6  A: 

A couple ideas:

  • Artificial intelligence (perhaps just simple AI utilities, like pathfinding algorithms)
  • Saving all or part of the game state (for suspending and restarting at a later time or saving high scores).
gnovice
AI for a generic game engine is a bit difficult. AI is too specific to the actual game, so I'm not sure how useful it would be to try and create a generic one that's part of the engine itself.
Herms
I was thinking more along the lines of simple AI algorithms (like an enemy that always moves towards you) as well as utilities (i.e. pathfinding algorithms).
gnovice
+1: very nice a* tutorial. Thanks for sharing it.
Callum Rogers
+8  A: 

A few more things:

  • Path finding - very useful for AI
  • AI - possibly - depends on how generic you want the engine to be.
  • High scores
  • Replays - makes high scores much more interesting, as you can actually watch them.
Zifre
Do you know of any good XNA/C# libraries for path finding? Or do you just recommend reading up on the algorithms involved and creating a solution that works for the particular game?
Venesectrix
I have never used XNA, so I don't really know of any good libraries. I'm sure there already are many great ones, but sometimes it is good to read about the algorithms and implement it yourself.
Zifre
@Venesectrix: Pathfinding (A* is the most popular algorithm) is very simple to implement and there are plenty of resources for it. See http://www.ziggyware.com/readarticle.php?article_id=162 for an XNA-related one.
Noldorin
Thanks for the tips guys!
Venesectrix
+1  A: 
  • Animation framework so that you can say: take this sprite, move it in this direction, folowing this path using this speed, acceleration and such
  • Basic GUI system. Don't implement a whole Windows, but basic things like a pointer and a button, and such - keep it basic
  • Debugging component for displaying FPS, numbers of sprites and such

Also a good thing is to make some games, and then you will quicky see what things you repeat doing for each game, and then look into how to can get that into the engine.

Jesper Blad Jensen aka. Deldy
+11  A: 

A theme or market for your engine. If you're doing anything beyond basic your basic graphics engine, you'll want to concentrate on a market for your engine, like RPG, strategy, puzzle, platformer, action, or FPS (ok, not FPS).

This will help you point yourself in the direction you need to go in order to make further enhancements to the engine without asking us. An engine like say, the Unreal Engine, can do multiple things, but what it tends to do best is what it's made for, FPS games. Likewise, you should tailor your engine so that it suits a particular field of interest, and therefore is picked up for that type of gameplay.

You can make it general to a point, but realize the more generalized your engine is, the harder it is to program, both time wise and skill wise. Other programmers are also less likely to pick up a general engine (unless that's all there is) if a more specific platform is available. Or to just write their own since modifying a generalized engine is about as hard as creating your own.

Organiccat
+1 Case in point with the Unreal Engine: The Last Remnant. Great game (RPG), but the graphics were so chuggy at points you wouldn't believe. All this comes from the fact that RPGs tend to have a lot more pretty effects going on at once compared to an FPS, and so need to have better degredation in the particle engine when there's multiple effects going on at once!
Ed Woodcock
A: 

A tile repeat tool. Something that allows the user to add/create a tile, and manipulate the edges for a smooth repeath pattern.

Neil N
+2  A: 

It depends on the game, but another thing often needed is a good networking framework.

Many modern games, including 2D games, seem to have some form of networking in place.

Reed Copsey
+3  A: 

I think that you covered the general requirements of a 2D engine. The only thing I would miss in that list would be:

  • GUI Library

Also to make development processes easier:

You might also add another layer on top of XNA's existing stuff:

  • A quite bareboned Network/Lobby implementation
  • More abstract handling of multiple controllers (DropIn/DropOut during gaming sessions, like see Resident Evil 5 Coop) - maybe event-based

Finally you might add some "ready2use" shaders. Maybe get some inspiration from the discontinued FaceWound (from the "Garry's Mod" developer).

Marcel J.
+1 for mentioning a GUI
Brian Ortiz
+1  A: 

Good collision detection is very helpful. If you implement it efficiently, it really reduces the time required for every frame. Besides that, in my engine (for Pygame) I have a method of separating the main screen into a number of subscreens, which I find useful.

Nikwin
A: 

Depending on the target game type, include Navigation Graph(s) with node and edge annotations. (Good for many games, but not so much for the token side scrollers that are made with 2D graphics engines)

  • A component to generate them (via a flood fill algorithm).
  • Be sure to include all of the major path finding/planning algorithms (A*/Dijkstra/etc.) to traverse those graphs.

The pitfall of this is that you will have to define what a 'map' is for the engine, which might limit users of the engine.

Related things:

  • Location based triggers (player enters an invisible circle and something happens - queue cutscene, start ambush, etc.). I would say provide a base class for the trigger and implement some basic ones to show how it's done (ie. weapon pickups etc.)
  • Some game engines implement networking (though this is kind of part of the 'xna stuff')
SnOrfus
A: 

The most useful thing to include above all else would be tools to easily use your engine. Maybe use your engine to create the tools. I'm sure you would find a lot of flaws that way.

Dunk
+1  A: 

Simple pixelperfect collision detection. NOT Farseer Physics. Simple drawing routines like drawline, drawcircle etc.

A: 

Um. This list is an "internals" list. To make great engine is to make great "external" list. Look at UE3 for example -- it is here because of great tools. You need tools for world creation, to create optimal packages of resources (it should be in internal list too ;-)), for collision object specification etc. Plus, to add to Organiccat answer you should decide on tech level. You can go for simple sprites or you can want fancy effects (so shaders are needed, and with this you need infrastructure)

+21  A: 

You're approaching it in an upside-down manner.

What should be in your engine is the following:

All the code that turned out to be common between your first and your second game.

First, write a game. Don't write an engine, because, as you have found out, you don't know what it should contain, or how it should be designed. Write a game instead.

Once you have that game, write another game. Then, when you have done that, examine the second game's code. How much of it was reused from the first game?

Anything that was reused should then be refactored out into a separate project. That project is now your game engine.

jalf
+2  A: 

A physics engine that can do a half-way decent boob wave motion, like in that DOA basketball game.

GenericMeatUnit