Other than our introduction post, we haven’t talked much about the systems we have created or plan to create. This post is going to go through what we currently have functional, what we’re still missing, and some of our thoughts along the way.
Background and Builds
We’re a few years into part-time development. All of us still have full time jobs during normal business hours. A few nights each week, we remotely meet up and get some game dev work in. We’re still only putting out private alpha builds, but we have some stats to share:
Android Alpha builds: 132
Commits: 5451
Days: 1669 (since we started, not worked)
Drinks: 418 (started tracking this very late)
World and Generation
Our initial goal was an infinite world that was procedurally generated and seamlessly connected. We always wanted to go very big with world size. After we had functional generation and could estimate actual disk usage, to avoid using someone’s entire device storage, we decided to limit the total world size to what would take up a reasonable amount of disk storage if someone took the time to explore every chunk of an entire world. A “normal” play though would be significantly smaller.
As we’ve covered in some of our generation posts, our world is made up of tiles. 64x64 tiles makes up a single chunk. Chunks are the unit we use for saving, loading, and generating. The current world is limited to 82x82x41 chunks. It’s possible this limit will go up or down based on play testing though. While there isn’t a need to reach the edge of the world to “win”, we don’t want a bunch of content that no one ever gets to experience.
We built our generation to run incrementally as the player moves around the world. The player only gets a loading screen on a new game, taking stairs/teleporting into an un-generated area, or launching an existing game that had some scheduled generation left over.
After a lot of discussion, we decided to go with different biome “rings” with unique layouts and npcs. These biomes will spawn based on player distance from the starting point. The player begins at the center of the world, biomes change in rings as the player moves out and/or down. (technically, biomes change out in a half sphere / bowl shape based on 3D distance from start, but we’ll keep calling them rings).
The generation systems are complete, but we’re still missing the config for most biomes. We only recently put together what will be the progression of npc types and environments.
Characters
As far as character behavior and abilities, we have a lot of very flexible systems in place already. We decided we wanted to introduce new npc abilities and mechanics gradually as the player progressed out through the biome rings. Our npcs can currently be configured to fly, walk through walls, perform melee or ranged attacks, leave trails of fire/oil/lava as they move, have custom AI / custom attacks, or run a variety of events based on a variety of triggers. There are so many options that we don’t want to immediately overwhelm new players. The goal is to make it so that as players progress though the game, enemies are unique, challenging, and dangerous. There should always be a feeling of progression while playing the game.
We don’t want to give away too many details about specific npcs at this time, as we would rather players discover them naturally as they progress. While we have a full list of npcs and their abilities defined in our design docs, we only have placeholder and testing npcs fully configured now. We’re still missing the majority of what we’d like to see across all biomes.
Items and Equipment
We’ve been blessed/cursed with a lot of interesting ideas for food, drink, wands, scrolls, potions, and miscellaneous items. We’ve implemented a handful at this point, but would like many more before we ship. The majority of our can’t-ship-without tickets left are for new items, new npcs, and “more of X” for an item type.
We’ve also changed our combat and damage mechanics a bit in the last few months. We’re constantly trying to find new ways to make combat more interesting, unique, and fun. We think we’ve found a good balance between what people are used to and our own spin on turn based tile combat. A big part of this is introducing the concept of attack patterns based on weapon type. We talked about this some previously, but the gist of it is that different weapons have the ability to attack in different patterns. For instance, while a dagger may attack a single tile, a long sword may hit multiple adjacent tiles in an arc. This system is still a work in progress, and it may see changes and improvements as we balance the gameplay.
We’ve only made 1 real balance pass so far. Odds are we still have a few more passes with a good amount of play testing with each. Right now, we very much are in a throw everything at the wall and see what sticks mentality. So ... things could change...
Bosses and Winning
With bosses, we wanted to make unique and interesting gameplay experiences that are played out in a more controlled setting than the procedurally generated game world. For this purpose, we have designed a boss system that allows us to build out boss encounters as a series of scripted events that play out using unique boss AI and combinations of events and effects that may not be encountered anywhere else in the game. One of our core pillars for boss design was that bosses cannot simply be sword sponges or dish out large amounts of damage. A boss encounter should be something that you must use the skills you have developed and an understanding of gameplay mechanics to win.
We’ve had a lot of back and forth on what the story and goal of the game really is. We’re still figuring this one out a bit as we go. We definitely want a consistent narrative from game opening to ending that encourages the player to keep playing. Bosses should have a consistent scaling of difficulty as you progress through the game. Each boss should be thematically relevant and should enforce abilities introduced in the biome they relate to.
At this point, we have 5 boss fights that we’re happy with and 7 planned biomes. So, one more boss fight and a final, over the top end game, boss encounter are still left to put together.
Art - Seriously
We still need art. Everywhere. We’re running placeholders with limited animations, some purchased art packs, and a lot of thrown together temp art at the moment. If you’ve seen screenshots - don’t judge. It turns out locking down an artist for contract work is difficult and a bit of a dice roll.
Music / SFX
Music and sound scaping is one of the areas we are really excited about. Our musician in residence, Roger, has been working hard to create some excellent original scoring and sound effects to provide an overall amazing audio theme. We have always liked the idea of a thrash-metal centric score for boss encounters as well as some more laid back exploration loops. We’re excited to showcase some of his work in future blog posts, so stay tuned.
Controls / User Interface
When making decisions about how to design our user interface, we had a few golden rules that we wanted to follow.
First, we wanted to keep the controls as simple as possible. Traditionally, roguelikes have leaned pretty heavily on complexity as a way to introduce depth. While this can be rewarding when you put the time into learning the systems (see dwarf fortress), we felt it would be too complex for a mobile game. For that reason we tried to move as many actions as possible into a context aware setting rather than explicitly mapped button presses or complex menu systems. In the simplest case, if you tap a locked door, we assume that you intend to use the appropriate key in your inventory to open it.
Second, when designing our inventory, stats, and equipment menus, we made a conscious effort to limit the number of taps necessary to perform actions as much as possible. The more common an action is to perform, the less taps it should take to execute. Less common actions, however, may be allowed to require deeper menu traversal for the sake of keeping the layout clean.
Third, the main gameplay screen should be as clean as possible. Some games seem to want to take up the main screen with excessive dialogs and menus. In some cases, those games limit the actual play space to a small subset of the screen in favor of extraneous text descriptions, minimaps, statistics, buttons, etc. As a mobile game that uses touch controls, we can move things like the minimap into a zoom LOD. That way the minimap is not interfering with game play, but is easily accessible via a quick pinch to zoom action. Likewise, while we have a game log that is accessible via the stats menu, we prefer to have all gameplay events like damage, debuffs, projectiles, enchantments, etc be graphically represented in game so that players aren’t required to read a log to know what happened during a turn.
While we feel that we have mapped out some pretty good rules to follow, there are still some rough edges we need to polish. Especially the current equip and comparison menus that some play testers have found to be confusing.
If Time was No Concern
We have a ton of things we’d love to do, but we don’t want to delay release for. Here are a few:
iOS version. We’re going to do it - just not first
Some form of daily quests
Cosmetic items and textures (if only art was easier)
Different play modes. Infinite exploration, wave combat, and/or some form of increasing difficulty
More new and unique biome generation algorithms
More elaborate item and environmental interactions
Pets? Maybe?
Anything else Kyle can scope creep
Wrap Up and Dodge a Solid Release Date
At this point, we’ve built out a lot of systems to let us do what we think would work well. We’ve also prototyped a good amount of what we’d like to see in the final version. We are wrapping up feature development and starting our final stretch of configure, play test, polish, and repeat.
We hope you enjoyed our fairly long description of what we’ve accomplished and where we’re heading. Hopefully you’re as excited for release as we are.
Love Always,
Much Software
Comments