April Progress (1 year later)

I haven’t done much with the game in the past year other than revise some of the platforming physics and update the tileset graphics. I had a long list of neat ideas that I wanted to implement but they really distracted me from my original goal, which was to actually finish this project. With that in mind, I eliminated most of these tasks and I am determined to release this game, in whatever shape it’s in, by the end of this week (4/21/2019). I have other projects that I would like to work on and never finishing this game has bothered me greatly because of how much time I have poured into it.

Area Prefabs and the Dungeon Builder

I spent today updating the ‘area reader’ code and it evolved into a replacement for my previous level generator object. I combined the code into a single loop so that once the areas have been dumped into DS grids and the Hamilton path has been generated, the game goes through the maze in order and builds the dungeon. This is far more efficient than my previous versions of this process for a couple reasons. The first reason, as mentioned previously, is that the code no longer needs to reorganize the dungeon layout into a top-down arrangement. The second reason is that I created special area transition objects that make constructing pathways between rooms much easier.

Instead of checking specific indices in an array, I can now simply place objects in the area templates that determine which areas are valid exits.

// If the object is a transition, see if it matches an exit in that room
if (object_get_parent(_object_id) == o_transition) {
  if (exit_exists(path_,_room_count,_object_id)) {
    _object_id = noone;
  } else {
    _object_id = o_solid;
  }
}

The object o_transition has four children: o_transition_north, o_transition_south, o_transition_east, and o_transition_west. If _object_id is a transition, we check to see if this transition’s direction is one of the exits in the area we are currently building. If there’s a match, we skip placing an o_solid object in that transition object’s location. In the future I plan on changing this procedure so that it uses predefined transition regions rather than explicit transition objects. This will allow for greater flexibility in the application of my area templates. For example, I could define a region that would create a tunnel or passageway if such an exit was needed.

March Progress

I hit a bit of a snag recently with some of the refactoring I had been meaning to do with my code. Basically, I was relying on a system of 2D arrays for most of my level creation code, which was fine, but it turned my code into a disorganized mess. I spent more time writing code to untangle arrays within arrays within arrays than actually making my game. I suppose this is probably a normal feeling but rather than trudge forward into something I was unhappy with, I spent most of the past few weeks rewriting my random dungeon creation code.  Continue reading “March Progress”

Platformer

random level layout.png

I changed the Everyday Tower project quite a bit. I kept adding stuff and settled on something simple but with actual gameplay. Right now it is a simple platformer but the levels are randomly generated using a Hamiltonian Path. The way the code is currently written, I can generate levels with n² rooms. The variable n = 4 in the image above. Each level is linear, with one start point and one end point, and the path will cross each vertex (in this case, each room) exactly once. This code works in the following manner:

Continue reading “Platformer”

King of Suplex

This is from a game I have been working on for a couple months. My next plan is to finish a character and then create the level art. It’s a fairly simple concept but it will still require a lot of work to get finished.