Walls? Why Did It Have To Be Walls?

Devblog #7

Walls. Walls are the problem. Every day I have a new problem and today it’s walls. Because I’ve forced my chosen perspective to have a very low horizon compared to most top-down games my objects obstruct each other more. In a game like Stardew Valley you don’t worry much about walls because you’re looking straight(ish) down and can see all the objects next to the wall. Not for me.

I started to get an inkling that I would have to tackle this issue back when I created the office from The Office (such a dumb sentence). If you see my last post the room only had walls on the top and left sides for that reason. So I went back to the ol’ Sketchup and created a new test room. A single level apartment with a bunch of interior walls.

And I purposely designed it to have rooms a little tighter and smaller than the rooms I intend for my game. That way this functions as a “worst case scenario” of sorts. I converted the entire apartment to my 35% oblique sexiness to see what I was really fighting with:

Yikes. If that doesn’t prove the issue with walls I don’t know what will. I decided at this point to start converting the furniture individually and moving the 2D images into Photoshop. Way easier to start sliding things around and manipulating the Y-dimensional spacing. The X actually doesn’t change much. After a few hours I had this:

I added some light bits of colour to make things easier on my eyes. Each piece of furniture is it’s own layer to mimic the depth sorting I mentioned at the end of Dev Blog #4. It actually proved really effective for testing because instead of programing collisions and movements for my character I simply gave the player it’s own layer in photoshop and slid him around with the mouse.

And finally I experimented with 4 options for how to handle a wall blocking the character:

-Image A also doubles as the default for the game. You walk behind and nothing changes.
-I was personally the biggest fan of option B.
-Option C is similar to The Sims which is a very popular game.
-And option D is very common in high-end games like Shadowrun Returns.

When I put these images on Tweeter, Phasebook and Instantgram I assumed D would win but literally every vote was for B. As of writing this that’s 21 votes so I’m going to call that a win. I was a little worried about the logistics of setting up collisions and triggers for activating the transparency but I think I accidentally dreamed up 3 lines of code that will take care of it so easily. I’ll mention in a future blog if I’m successful.

For a lot of scenes and places in my game I’m going to try not to use interior walls anyway. That would make a lot of this effort completely useless. But at the start of the game when you have smaller spaceships it’ll be nice to know I have the option of making them feel compact without actually hiding away the details.

Also these last 4 images show a closer representation of the scale of the game. All my office and apartment shots are really zoomed out so you see the whole room. The real game will be much closer to the action. The camera will pan as the character moves. This way you can interact with more objects in a smaller area like an oven, microwave, sink and fridge all in the kitchen, for example.

I’m hoping to start updating more often again. I clocked 302 hours in 32 days at work because of an auction but it’s just about wrapped up. Truthfully I haven’t written a line of code in 2 months so I’m completely lost again. I’m going to have to reread everything I’ve done to figure out where I am. Wish me luck.

Michael

Trigonometry For Children

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