Collision Conundrum. Now that the map renderer is working, I recently turned my attention to the actor renderer. This should be an easier problem to solve, but there's a catch. I took out the original physics engine (which relied on Box2D). Because actor drawing order depends on collision resolution, the two systems have to work together. This means I need a working physics engine before I can complete the actor renderer.
Implementing Physics and Collisions. This problem has been tackled in a variety of ways. In older versions of the engine (2015, 2016), each actor was represented by two actors: a "peg" actor and an "image" actor. The "peg" actors existed on a 2D plane and were the actual actors as far as movement, hit detection, collision, etc., were concerned. The location of the "image" was computed based on the location of the "peg".
I wrote about using this approach
way back in 2015 and it is pretty reliable. One benefit is that you can use Stencyl's existing options, Box2D or simple physics, without writing additional code. The drawback for me is that my maps don't exist on a 2D plane. They're split between multiple 2D planes, each representing one floor in a taller structure. When an actor changes floor, they are "teleported" from one region on the 2D scene to another. This complicates collision detection when the player is moving up or down as well as horizontally... for example, jumping off of ledge.
I think I can modify this solution, but using an approach closer to what rob1221 described for
Isotiles. Rather than use collision shapes, I'll check for collisions using the graph that is constructed when the map is loaded.
Checking collisions on the graph solves a variety of problems. I don't need separate "image actors" for one. Also, the graph has all the necessary data needed for 3D collisions if I make the following assumptions:
* The collision solid for any moving actor is a cylinder (not necessarily of the same height, though)
* Every actor is represented by a single point.
These are the parameters I'm already used to, so I don't expect needing to change much of the code that depends on physics (such as enemy pathfinding, projectile collisions, etc.)
The difficulties, though, include handling drawing order resolution and writing my own collision detection system. The latter I'm working on, but I have a solution drawn up for drawing order resolution.
Resolving Actor-* Drawing Order. Because moving actors are presented by a single point, resolving the draw order between two actors or an actor and a wall is simple. Actor-actor drawing order can be resolved using the coordinate sum method already implemented. If actor 1 is located at (ux,uy,uz) and actor 2 at (vx,vy,vz), then compare the sum (ux+uy+uz) to (vx+vy+vz). The higher sum corresponds to the actor closest to the screen.
Resolving actor-wall drawing order isn't much more complicated. Every wall has a normal vector N, so I compute the dot product of the actor's position with N as well as the dot product of a vertex on the wall (any of them will do) and N. If the dot product for the actor is greater then the actor is in front of the wall.
The drawback of representing actors with a single point is that I can't have actors that are larger than one tile. This shouldn't break actor-wall resolution, but actors of arbitrary size will complicate actor-actor resolution. I could throw actors into the wall graph used for topological sort, but I'm not sure how efficient that will be. In any case, it doesn't matter because I simply don't need actors larger than one tile. The only exception would be the serpent I was planning for the original game--but that would require special coding anyway, and I think breaking it up into tile-sized chunks would be simple enough.
Doodling. While I've been researching collision systems, I took some time to sketch some mock-ups of the interface for the revised
Temple of Idosra.
One of the first things I needed was a new title screen that better reflected the direction I'm planning to take the storyline. Current screen:
The original game had no real player-object interaction. While I want to keep to the spirit of the original game, I think I can also update it to better fit in with the design of the current engine. For one, I liked the card system I implemented for player-object interactions. The player's "inventory" (not limited to tangible objects) is represented by a deck of cards. The first card is the player character itself.
For reference, this was the amber-color version:
(link)I think I can improve the decor and the buttons, but I like the general layout. Cards are 72x72--large enough to draw an icon that zooms in on an important detail. I like the font. The original font was the NES font. I think I need a brighter color, though (note that these are 1x images, but the game is rendered in 2x resolution).
The original game was one big 113-room level. I still like the idea of leaving the game mostly open, but I also wanted to have distinct chapters or acts. I came up with the idea of displaying a short title screen whenever the player completes a significant objective.
This way I can still keep the game's map open, but also still use chapter divisions to manage the storyline (rather, put in a storyline, since the original game had none). I don't plan to give the game a narrator, but I do like the third person POV. This decision allows me to let Marika "talk" to the player when necessary. Plus, despite the RPG elements of the game, there's only one player character. First person POV feels more appropriate for either a game where you can make your own character (or choose from an extensive list), or a game like Doom where the protagonist is so generic that it's easy for just about anyone to put themselves in the player character's place.