Devblog # 4
Dair Deary (spelling?),
The last two weeks have been a real challenge. I had finally moved into actually programming this darn game. Before that it was a lot of notes on paper or sketches/experiments in photoshop. Since I know very little about programming and I’m learning as I go I’m relying a lot on guides and tutorials and a million bookmarks of the engine manual. Unfortunately for me there are not very many tutorials, if any, for creating a 2D oblique perspective game. So I’m combining a lot of tutorials for top-down and isometric games.
Right now I’m racing to a point where I can actually show progress in game. Actual video game stuff. I needed to program how the game runs first. It’s a completely 2D game but it will look 3D(ish). You can walk left and right and away and towards. You can walk in front of objects and behind objects. As a quick visual experiment to make sure my chosen perspective works I drew this:
The rabbit you should recognize from some random comics I’ve drawn. He’s almost certainly not going to be in the game. But you can see my intended goal as far as setting up a scene. In order to make the character walk AROUND the objects but not THROUGH the objects I needed to set up collisions for the ground under the cubes. In order to do that I needed to break down the object and tackle each part separately.
The game engine allows you to create a rectangular “collision mask” for sprites that use very little CPU power. It’s only tracking 4 points in space (the corners of a box). Unfortunately this does not include angles.
I needed to program in a new collision area for every object and I wanted it to be very low cost to the CPU. Fortunately I got lucky because I chose a 45 degree angle for the side perspective. Using the very simple formula for perfect right angle triangles I simply took the side dimension of our collision mask and extended outwards from the top right corner and bottom left corners. This created a new area that I can track.
Now to find out if my character is in fact inside of that area I used the “Point in Triangle” formula. It’s a way of finding out if any given point is inside a triangle by measuring the combined areas it makes. If a point is INSIDE a triangle the area stays the same. If the point is OUTSIDE a triangle the areas get larger. (I’m a math junky and it’s so awesome being able to use these formulas in real life now).
Yes you can use the formula of A = ab / 2 for the first triangle but since you can’t for the other three I didn’t put it in the picture. The silly thing is that I was half way through coding these formulas into the game when I found out that I can use a command literally called “rectangle_in_triangle” which did all the math for me. I just needed to set up the original coordinates of the triangle points and player bounding box. Really saved me a lot of time. Well not really. I had done most of the math already…
There was still one small glitch though. As it turns out the “Rectangle” actually doesn’t trigger when it hits the “triangle”. It only does if one of the corners meets the triangle. Effectively it was doing 4 “point in triangle” calculations. So to compensate for it I use a “point_in_rectangle” using the furthest point of the triangles and the players bounding box. I’d made a graphic for it but I’m tired and can’t be bothered. If anyone out there ever actually does follow what I’m doing they can ask me to clarify if they don’t already get it.
I spent days. Maybe weeks. working on this. I could recreate it now in a matter of minutes but with only a basic grasp of how to program what I’m thinking the smallest mistake can cost me hours while I try to diagnose the problem. In order to really know I had to finish another issue I had. The depth of objects. When objects or characters move around they need to be shown behind or in front of objects depending on the situation.
I followed an awesome guide from Friendly Cosmonaut to create a grid that will load all objects with a lower Y coordinate first and higher numbers after. This puts them in the correct order going down the screen. This works for most RPG type games like Stardew Valley or Final Fantasy because you don’t see any of the sides of the box.
So close. I went searching for a solution but I wasn’t quickly able to find one. People asked similar questions about how to order all the X coordinates before moving to the next Y coordinate and some of the answers they got were complicated and heavy. For mine I just simply added a ZERO to the end of the Y coordinate for each object and added the X coordinate. So now instead of 15 objects having an identical Y coordinate (ex 1). Then they each get their own like 11, 12, 13 -> (all 15 objects) before moving to the next Y coordinate to find new boxes.
Long story short it worked like a dream. For a few minutes before I found ANOTHER problem. This works great for objects that have the same size footprint. And with a very small modification I made it work for longer items. But items that reach forward and back completely break it. Here’s a grid I created in photoshop with a bunch of different sized and shaped 45 degree parallelograms (the shape my boxes make in the end).
I have dozens of pictures like this from experimenting. It’s ridiculous. If all the objects loaded in the way I needed it to this grid would create a scene like this:
But the largest boxes that extend backwards and forwards the most mess it all up. I haven’t yet come up with a formula that will correct that for me. I’ve had a few experiments come close but nothing perfect. For now I’ll have to just cut up large sprites into multiple objects or tiles so I can continue on with my game. My google searches have just about convinced me that a one-line formula is not likely to fix this. A solution in javascript I found was 200 lines of code and I have no idea how to start using it. I’ll have to come back to it.
But now I’m excited because I can finally start producing assets and show off what this game actually is. I’M SO CLOSE!
Love Michael
