I've decided to resurrect an old game idea I had years ago. I currently have zero experience with programming, but I'm going to begin studying either C#, Python or both in the near future.
The issue I'm currently facing is that what I plan on making is an isometric Metroidvania-type game, similar to that old GBA title Scurge: Hive on a very basic level. Naturally, this means that there will be some emphasis on platforming. The problem is, I hear that programming those kinds of physics into a 2D game is highly impractical. General consensus, from what I've seen, seems to be that it's easier to just make isometric games in 3D so that programming collision detection and the like is simpler.
I really want this to be a 2D game, as I have absolutely no experience with 3D modeling. Yet I also don't want to have to build the entire underlying physics engine from scratch. I've looked around a bit and there don't seem to be any engines for this type of game that are compatible with C# or Python. There are isometric engines, but most seemed to be geared toward 3D games and RPGs.
So I guess what I'm trying to ask is, are there any engines available that would make it easier to program an isometric 2D platformer? Or would I have to do the collision detection coding myself?
(As an aside, while I'm considering both #C and Python, I'm leaning toward Python due to the fact that it's multiplatform and apparently better for beginners. So please take that into consideration if possible.)
Edit: After some more research, I've chosen to go with Lua, but I may still study Python and C# as well if possible. Hopefully I'm not biting off more than I can chew.
Answer
Whoever's general consensus you have, is wrong. There is nothing special needed to implement collision detection in an isometric game. It is no different from implementing collision detection in Robotron or even Pitfall. This is a common misconception, and one that often leads to a lot of struggling. On contract recently I met a senior developer who couldn't for the life of him fix a broken isometric engine's collision detection, and furthermore refused to rewrite the thing, because he didn't grok what I am about to tell you.
Consider an isometrically-rendered space. Is that space, the actual space, what you see on the screen? No, that is just a representation. In reality it is a set of underlying data in memory, and that data is a 2D array (or a set of them, layered by height). From a visual perspective, that space could just as easily be imagined as an orthogonal top down view (a la Robotron), with left=-x, right=+x, up=-y, down=+y, -z=out, +z=in, and it is pragmatic to visualize your data structure as such. In other words, imagine the game as orthogonal top-down, do all physics and other logic in that mode, but then perform transformations into an isometric format for the purposes of rendering only. I advise you to first render as vectors i.e. using points/lines/squares: An article like this one will help you get the basics right for point placement using isometric transformations, and subsequent line drawing between those points. Then after some tweaking you will see from your drawn lines, what your isometric tile sizes and character sizes should be. You could then take screenshots (or save bitmap data to disk) and use these ("diamonds") as the bases for your sprites.
The key distinction to be made here is that what you see is not the data model of your game. It is only a representation thereof. No special engine is required to do any of what you want to do, easily.
No comments:
Post a Comment