Category: Main
-
Now Available: Mörkal Komborg
Mörkal Komborg now available in print on Exalted Funeral (with free PDF copy!) -
Game Released
I tidied up the game to make it fit to release. It’s mostly a tech demo; at this point, it is a relic regarding GameMaker Studio’s capabilities. For example, functions and methods did not exist during development, so I used a system of script arguments to replicate the functionality. Additionally, I used the built-in level-making tools to make my own “Prefabs,” which I was familiar with from using Unity. There is more information about that process in this post.
-
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. (more…)
-
February Progress
I derived a new method of determining wall placement that will be easier to manage and apply to a variety of features. I first created macros that define each type of exit direction. -
Platformer
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: