2.5D Beat em' Up Development Theory

This topic is 2537 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hi everyone,

I am an independent aspiring developer attempting to create a Actionscript 3 Flash game.
Currently I am working on a project I can describe as a 2.5 dimensional Beat 'em Up game, similar to games like Castle Crashers and the Double Dragon series. This means two dimensional graphics with three dimensional gameplay. I am still in the early stages of development, and am working primarily on the programming aspects as of yet.

My questions arise from deciding how to implement this style of 2D graphics and 3D gameplay. I'm curious if there's a proper way of designing and architecting such a project.
Some solutions I've contemplated are:

• Implement a 3D engine and use 2D-esque models and skins, similar to a paper puppet show. Some pros of this are that things like physics and depth are native components that come with using 3D, making those aspects pretty easy on me as a programmer. However, I imagine this would be pretty resource intensive, and maybe even unnecessary. It seems to me like an overweight solution, and I don't know if this is a viable strategy. I haven't tried this yet and can't really offer any more thoughts on this.
• Use 2D graphics and a 2D physics engine and simulate depth (what I am currently using). The idea behind this is to separate the mathematics (collision, depth) half from the graphics half. The 2D engine uses geometric shapes to represent the gameplay objects, and they interact with each other from a top-down perspective, with physics, like the minimap of a real-time strategy game. The graphics are handled separately.
The graphics half takes the information of the geometric shapes, and translates it into a side-scroller perspective: the x coordinates of the shapes are the same as their graphic, while their y coordinate translates into the 'depth' of the graphic and makes it move along the ground along a 'z axis', as we view it from a 45 degree angle (by moving their y coordinate proportionately). For this method, any given object is a combination of the physics object and the graphic. This process helps out well with dealing with collision from the engine, since checking collision against the graphics would be unreliable.
Cons of this include that I essentially lose out on a y axis on the graphic side, since all the information comes from a top down view where it deals in the x and z axis, making things like jumping impossible thus far. Also, translating mouse input between the graphics and the physics engine is proving difficult. Furthermore, it's made for some bulky and bloated code architecture since an object is essentially a physics model, graphic, and wrapper.
If anyone has any thoughts on these strategies, or new ones to offer, I would very much like to hear them. I would like to know if there is a proper technique for this. If anyone knows the method used in successful examples of Beat 'em Up games (like Castle Crashers), I would also appreciate hearing that. As well, if anyone can suggest research material, I'd be more to happy to take a look.

If anyone needs more clarification on what I'm trying to do and what I'm currently doing for this project, please mention it.

Share on other sites
The "proper" way is a 3D physics engine because your world is 3D, but your assumption that 3D implies "overweight" and "resource intensive" is very unfounded. Both code complexity and computational cost depend on what you need your 3D physics to do.
Old games like Final Fight probably used cheap collision detection of axis-aligned boxes, which has only up to 50% more work to do in 3D than in 2D (one more coordinate to test and sort by, but only sometimes), simple rules (if his foot box intersects my head box, X damage and I stagger back N pixels) and scripted animations.
You can increase quality and effort from this cheap and effective baseline in several controllable ways: use triangles or generic convex polygons (prisms or general meshes) to follow body shapes more faithfully; allow interactions that displace entities laterally, like a kick from the side; introduce missiles with general 3D trajectories; add poses and animations (e.g. 4 or 8 directions of facing instead of only forward and backward); and so on. It will still be collision detection between a modest number of entities that move in preprogrammed ways: far simpler, cheaper and more reliable than a full dynamic simulation, either 2D or 3D.

Share on other sites
Implement the game logic in 3D. Processing a third number when dealing with displacement/velocity/collision is not going to kill performance.

1. 1
2. 2
3. 3
Rutin
22
4. 4
JoeJ
17
5. 5

• 14
• 30
• 13
• 11
• 11
• Forum Statistics

• Total Topics
631774
• Total Posts
3002295
×