Project Bolero Devlog 2

Work Since Last Devlog

  • Merged in basic sound and music playback functions.
  • Added scrolling to the platformer prototype, upgrading it to sidescroller status.
  • Made a list of actor tables that are processed every tick, and merged the player into this list. Made a couple of test objects: 200+ squares that approach the player, and warp to a random XY upon contact, and a moving platform that the player can ride.
  • Installed Tiled and confirmed that it works on my system.

I was concerned that I may have bitten off more than I can chew. Spaghetti code notwithstanding, I seem to have ticked all of the boxes (though I combined the ‘patrolling enemy’ and ‘moving platform’ into one entity.)



Halfway through the week, I decided I would be better off making one or two shorter games before embarking on even a mid-sized project. There is absolutely no shortage of things that need to be ironed out and refactored along the way. Better to get something out as I work through those issues, than to be toiling in the dark for who knows how long with nothing to show for it. I’m aiming to produce some kind of short project for EOY 2018, though I can’t guarantee if that will happen.

With that said, even a short project can’t really be formed without a working engine. I don’t want to be dealing with texture seam and collision detection issues while also working on gameplay rules, for example. These ideas need to be put into a box and left untouched until I have more of the base engine up and running.

Below are some more general thoughts that I wasn’t able to finish writing out last week due to time.


Perspective, and inventory vs physical objects

I have been splitting hairs over how to handle perspective in the game. There are a few ways you can go about doing this in a 2D pixel art environment. This article by Radek Koncewicz covers the most commons kinds of perspective used in 2D games.

I’ll be using some goofy purple houses with visible interiors (the viewer-facing wall being hidden) that I threw together to help illustrate what I’m thinking of:


A straight-forward view, which is pretty abstract and kind of alienating, but has the most flexibility in terms of hosting game object interactions. You know exactly where the solid tiles begin and end, and there is no confusion about what belongs to the background and what is the active plane.


A view where structures are tilted so that one additional side is visible. This is more visually appealing than the head-on view, but there is potential for the tilted parts of the structures to be mistaken for solid walls, if they share colors and texturing of the solid parts of the terrain. Depending on the amount of tilting, these decorative sides can also eat into the free space available on the screen.


Oblique projection, showing the ground’s surface in addition to the right side of walls. This looks the best of the three, but where exactly the game objects connect with the floor can sometimes be ambiguous, particularly when jumping from ledge to ledge. Ceilings and the left sides of walls may obscure objects slightly as well, depending on how they are implemented.

Besides the perspective of the floor and the side-walls, I’m also not sure how to deal with objects that are part of the background.

Take this door for example. What should the interior version of this building look like? Should the interior door be in the same position? Wouldn’t it need to be placed on the invisible wall that the end user is seeing through? Maybe the interior is just a flipped image?

Alternatively, I could avoid embedding objects into the background walls, and make everything that the player interacts with part of the solid plane. Again though, it’s not as presentable.


Here’s a different kind of object for comparison. The switch on the left would be part of the plane that the player object moves on, and could potentially be interacted with by other physical objects (like a projectile knocking the switch into its other position). The switch on the right is embedded into the background, and isn’t part of the collision layer, but is more presentable and less likely to clutter up layouts.


This extends to auxiliary methods of getting around the levels as well. Should staircases be passable, or completely solid?


Stairs could also be completely front-facing.


What about elevators — part of the background, or part of the active plane?


One more concern which is sort of related to the presentation of objects is whether to have an inventory system or not, and if those items should be equipped or passive, and if those items should be tangible objects with physical characteristics, or drawn as details. For example, a shield that is part of the player sprite, versus a shield that is overlaid on top of the sprite with its own hitbox for deflecting projectiles, and which could be set down in the environment, affecting other tangible objects.


Plans For Next Week

  • Load maps made in Tiled
  • Load and display tiles
  • Basic sprite animation, tagging sprites to actors
  • Cut the game world into discrete rooms with their own actor lists and room properties

Leave a Comment