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”


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.

King of Strikers – Intro Demo

I made this video for a pitch presentation for King of Strikers: Ultimate Pro Wrestling. It was a simple concept for a physics-based wrestling game for iOS/Android. I still plan on making a wrestling game but it might be less of a touch-based game and more like something playable on consoles or with a controller. My goal is to make a simple two player fighting game with simple controls.