TIGSource Forums

Hey all,

I'm a third-year college student majoring in Game Design. My main interest in systems design, though I really enjoy core concept design, and even the administrative stuff (oddly enough). I do enjoy programming and I am somewhat capable of it, but there is one major roadblock that's always been in my way.

When it comes to an engine like Game Maker with a GUI element, making, say, a side-scrolling platformer is no problem. However, when it comes to actual code (i.e. no visual elements), I am completely stumped. For example, I have released one game for XBLIG which I had no problem coding, however it was a simple puzzle game so it didn't present a problem.

No matter how many tutorials I have read, I just can't seem to wrap my head around how to make a platforming game. I don't understand the concept of having a "camera" (it always seems like the world moves instead of the character or something?) and I don't understand how to actually "efficiently" set up a level (whether tile-based or not) and furthermore, how to efficiently detect collisions among each part of that world. I get the whole "gravity and physics" thing, but not the actual act of setting up the level and colliding with its elements.

The language I am most well-versed in is C# (using XnA Framework) which I have about a year of exp. in. I am also open to using things like Pygame and C++ & OpenGL (though that is considerably more complicated). I have been using Game Maker for 5 years or so but I want to stray away from that and do some "real" programming.

Any advice to shed some light on this for me? Sorry if this seems a bit generic -- feel free to ask for any additional details that could help.

This is not really responsive to your question, but if you don't really feel like you have enough of a grasp to make such things intuitive without a GUI tool, why not just upgrade to a platform that features both GUI tool and a higher-level language?

Unity (supports C#) or any of the Flash tools comes to mind.

Alternately you could try writing a simpler game first, like a space shooter or something, before moving on to platformers (which have tricky requirements like collision physics).

What I did the first time I wanted to make a platformer was I just downloaded a C++ rigid body physics engine and made that do all the work for me. After I'd spent some time "writing a game" while observing how the downloaded physics engine did things, I started to kind of get a sense of "oh, that's how it works" or I'd look at something I'd written and go "oh, there was a simpler way to do that". By the time I got to the end I was at the point where I could probably write a simple platformer engine myself.

Start simple. You can separate the "physics engine" aspect from the "scrolling platformer" aspect and deal with them individually. Try making a simple demo where you have a ball bouncing around inside of a box. That will require you to solve the basics of collision detection and response.

As far as physics is concerned, generally what you do boils down to these steps:

1) Move objects
2) Detect overlap
3) Back objects out until overlap no longer occurs
4) Respond to collision

(1) at its simplest just consists of adding the object's velocity to its position. Don't even worry about acceleration.

(2) at its simplest is just bounding boxes. Think of a bounding box as having a min and max X and Y value (i.e. the box occupies the space that is both between minX and maxX, and between minY and maxY). Two bounding boxes A and B intersect if none of the following is true: A's maxX is less than B's minX; A's minX is more than B's maxX; A's maxY is less than B's minY; A's minY is more than B's maxY.

(3) requires some basic math but you should be able to handle it. :)

(4) at its simplest can consist of simply destroying an object (e.g. bullet hits ship => bullet is destroyed, ship health decrements) or reversing motion.

Good luck!

Thanks for the help, guys. Always lots of great information at this forum.

I feel I should add a few things, though. The games I have done that involved more "pure" programming languages have involved collision. I understand detecting overlap, even pushing objects out of each other to some extent. I think the problem arises more from needing to know how to build the levels themselves. Detecting overlap and things in that vein only become a problem based on how I think the level should be set up.

It seems like with XnA, everyone is setting up levels using an array or similar data structure. Doesn't something like that become unwieldy? At the same time, what other alternatives are there -- creating platform objects and looking through them in a foreach()? Even that would become slow, I would think. Maybe I'm just looking in the wrong places, but coming from GM (where everything is just an object, and collisions can be detected directly with each object) it seems a little convoluted.

I have also tried learning some AS3, but again, the only tutorials I've found have involved setting up levels as arrays and that seems kind of odd for setting up games with sloped platforms, complex level layouts etc. etc. -- or are they just using tilesets?

Unity3D is something I have been learning, but I have been dying to try my hand at this in a straight-up programming language, just to see if I can do it. It seems like many people with even less experience than I do can grasp it (possibly because they started with these languages) whereas I don't get it at all, and I feel left behind.

It all kind of boggles my mind. It's weird. I can understand a lot of other, (seemingly) more complex things, but not this.

Again, thanks for the help guys.

EDIT: Also, will need to try looking into some physics engines, particularly for flash & C++. Thanks for that!

Generally for a 2D game, an array of tiles or a list of static objects is exactly how levels are stored. If you go the latter route, yeah, you'd just test the player (and enemies, and any other moving object) against each object using a big foreach loop. Unless your level and/or number of moving object is super-complex, efficiency shouldn't be a problem. Even if it is, there are a number of optimizations you can make to cut down on the number of tests - dividing your level into sections and only testing against objects in the particular section the player is in, for instance. If you go the tile route, you can easily compute which tiles the player could be colliding with and then only test against those.

In general, don't underestimate the power of modern computers. Understand the runtime complexity of your algorithms (knowing about big-O and stuff like that is quite helpful) and understand the size of your data set, and you should have a rough idea of whether or not a particular approach would be a problem.

Adding scrolling/cameras introduces a number of complications in practice, but in theory the idea is easy. Each object in the world has a "world location". When you render, the camera takes those world locations and translates them into a "screen location", based on where the camera is pointing. Try drawing a little diagram on some scrap paper. Assuming 0,0 is in the top left, if your dude is located at world position (1000, 1000), and the top left of the camera is at position (800, 800), then your dude would be at position (200, 200) on screen. Does that make sense?

Arrays are your friends, especially with collision. When collision lines up exactly along tile boundaries - which has to be the case when using an array - you are guaranteed that characters only overlap so many tiles, that they fall or snap within certain boundaries, etc. With arbitrary objects, they can potentially intersect with an infinite number of things, which makes the collision response more difficult.

(In general, this is the most reliable character-against-environment response strategy: If you project a future position with velocity values, instead of pushing out after position has changed, and run a lot of detection passes, each one changing the velocity vector with a pushout, until the vector no longer changes, you can guarantee correct behavior. Other methods are less reliable but can be faster. Faster usually isn't needed, not these days.)

Field-based structures - structs/objects/etc. are (in essence, if not in implementation) arrays with named indexes. And in the low-level theoretical view of memory, it's just one big bit array, baby 8)

Your guess about tilesets being used for angles, etc., are correct. They are achieved by combining the rectangle tests used for tile collision with either pixel-perfect or additional geometric tests.

I am working on this game, (http://www.magnategame.com) which has a very sophisticated notion of tiles, right now. It has many arrays - arrays for pathfinding, arrays for cached tile data, arrays for collision/behavior, arrays for skinning/visuals, arrays for the tall pieces, arrays for the markers on top of tiles, arrays for the displayed tiles(separate from the internal map tiles)...

I'm not happy with all of it but I've hardly hit a limit on complexity yet. The limit is basically "you are too scared to continue."

Thanks guys. A lot of this has been very, very useful. I feel like maybe if I push real hard, I can put together a platformer in C#. The camera will need to come after, I suppose, but if I start small...

One final question: I know it makes things a lot easier to just have a level editor. Is that in a class all its own (in that it's significantly harder to code? Is it better to save out levels as different files and load them in like that?

A friend and I worked on a platformer way back, he made a simple GUI that you loaded a bitmap into, then you clicked around to draw "floors" and "walls". There was an output tab that spat out all the code neccesary for them, like

generateFloor(0,200,300,500)
generateWall(30,100,100,1) (X/Y, height, can wall grab).

Then we just pasted that into the switch for the level generation.

For starters, make sure you can get a player moving, jumping and falling against a hard-coded "Ground" Y value. Then start making arrays of floors and check to see if..

player.x >= floor.origin.x && player.x <= floor.origin.x+floor.width && player.y < floor.y-player.height

and if so, set the players "platform" variable to = the floor's index, or tag. Then set the player to a grounded state.

Something similar to this that I have seen is to store level data as svg images. The advantages to the svg approach would be that you could use readily available tools to edit the files graphically, as well as parse them in your game(svg images are basically just xml). The cost would be that the svg standard isn't really the greatest file format for levels, but for an experimental prototype project, cutting out the dev time developing editing tools may be desirable.

Another thing you can do is just use a standard image editor and map each of the different kinds of tile you have to a different color. Then you load the image in your program and read the pixels, and use that to decide where to put tiles. Obviously this only really works at all well for a strict tile-based approach, but it can make for very fast mapmaking since you have access to all sorts of useful drawing tools.

The need for tools depends (like everything) on the gameplay.

Some Basic type-in games found in 1980s computer magazines would actually use a bunch of print statements to set up a tile-based level, and then read the display to instance the game objects. A slightly more sophisticated version is to read in a text file; this is great as long as you have a small tileset and you don't need lots of layers. Text editors are great level editors, and JSON is a great general data format(XML and CSV are not as good, but still acceptable).

Building the "ideal editor" for most games involves getting the edit/test cycle as short as possible, which typically leads to something integrated in the game itself. I don't recommend doing anything else if you plan on building your own editor. The main point of confusion is that you tend to have to convert the editor representation of data into the runtime data when the level loads.

There are some generic tools for maps around, as well as processes based on bitmaps or vector art as mentioned above. Some are art-oriented (e.g. the tilemap editor in Pro Motion (http://www.cosmigo.com/promotion/index.php)) and others are more useful for gameplay (Ogmo (http://ogmoeditor.com/)) All of the "generic tool" processes tend to get a bit clunky at some point - converting formats, missing features, etc. But they've also got their uses, if your game fits into their mold.

Yeah, that sounds like a decent way to go for quickly drawing something.

OP: The advantage of making a tool is that you can draw anything and your walls/floors are invisible layers over that. But doing SVG (or hell, even hardcoding a couple of floors) would be faster.

For ages I was really confused about just what a camera was. Im sure it can be cool and complicated but like _smashers sayin dawg, it can boil down to like draw(obj.img, obj.x+world_x, obj.y+world_y) and then all you have to do is translate mouse input.