Tag: rpg

Refactoring, Boss Monsters, Loot and Locks

I’ve started to feel that the codebase for this game is getting to a point where the volume of code is having an effect on the complexity. It felt to me that every time I wanted to make a small change, regardless of how elegantly I felt I was doing so, I was doing more work than necessary to get it implemented.

Curious to back up my feelings, I imported my repository into a webapp called Gitential that helps visualize various datapoints around a project on Github. The app is fantastic, but what I found interesting was a certain graph that showed that, while the codebase was increasing in complexity initially, the complexity was trending downward over time as the volume of code increased.

The app maintains that the complexity increases as new code is added to the code base, but decreases as refactoring is done. I make sure to refactor as much as I can, leaving notes in places where a refactoring would be more troublesome.

An Improved Cast

One such refactoring was how we were handling Casts. Casts are how I am handling Entity to Entity interaction in the game world. Basically, an Entity will send out a Cast to query the map at a certain set of coordinates. If it finds something, it’ll trigger an interaction: a message will be displayed, a chest will open up, a warp tile will send you to another part of the map:

A brief overview of how casts work in the game.

A reference to a group of Casts that lived in the Scene object was passed around to every Entity object that exists on the Scene via their constructors. When an Entity “casted”, it added its Cast to this object directly. This tight coupling was very bad for complexity. It meant that my classes knew too much about other classes.

So I tore that Cast group out of the constructors of all of my Entities, and instead had the Entity emit a Cast event that the Scene was listening for. That way the implementation was decoupled.

I also gave the Cast a little bit more. I made an enum for the type of cast being casted– I wanted to differentiate between a cast that was sent out (up, down, left or right) from the Entity and a cast being sent below it to query underfoot. I named them reach and pressure Casts, respectively.

I also added an event to the Cast that will emit riiiight before it fizzles out and dies forever, sending back valuable information to the caster about the Entity that it found. This allows Entities to query other Entities.

Boss Monsters

One of my epic milestones was to create a a special type of battle for boss monsters. These would be battles that were triggered by NPCs on the world map, and upon winning would flip a Flag or series of Flags in the world.

I designed some bosses, wrote some dialog for them, and placed them on the world map. I wanted the boss’s death to trigger a key item to spawn in the space that it died on.

  • Cosmoknight
  • Laundromancer
  • Wanmonster

I wrote a method that would iterate through every Entity on the map and show or hide it based on whether the flag was flipped. When hidden, the Entity would query underfoot using a Cast before disappearing and turning the tile’s collision off.

The result was an experience where the player triggers a battle by talking to the boss monster, wins the battle, the boss Sprite is gone and in its place was an item to collect.

Loot

I created a new class of Item that is specifically made for selling: Loot. I designed things like jewels and precious gems and set some monsters to have a very small chance of dropping them.

When the store is implemented later, the player will be able to sell them for large amounts of gold.

Locked Doors and Chests

I also introduced a new type of Entity: locked doors and locked chests. These can be opened by collecting silver and gold keys respectively. The chests can contain great treasure like the above-mentioned Loot or KeyItems, and the locked doors can gate player progress.

These can be really useful tools for creating puzzles and guiding the player through the game.

Moving on, the next big step is adding some more features to the battle system. I’m in the middle of scoping this out and designing some of the new elements, but I look forward to sharing my progress there in the coming weeks!

An Anniversary Present

Last year I got my wife a trip to a glass blowing tour in Louisville Kentucky for her birthday. It was to be an awesome experience that showcased mankind’s unique ability to harness the power of heat to blow glass in his image. We were very excited.

On the morning of the tour, I realized I’d accidentally booked tickets to a glass crafts workshop directly across the way from the glass blowing tour. The idea of this workshop was to take pieces of glass that someone broke with a gross hammer and lay them out in a pattern, and then they’ll cook it or whatever and put a magnet on the back of it and you can throw it on your fridge for 30 bucks.

While we were playing with shards of colored glass, we couldn’t help but look over and see the incredible amounts of fun being had in the glass-blowing workshop. We both went home, our strange trinkets in brown paper bags, wondering what kind of cool experience we missed out on that day. I felt a little bad for letting her down.

This year is different. I decided I would like to make a game for my wife. The scope is ambitious, but not impossible:

  • I’d like to make a classic Game Boy Color RPG.
  • You will be able to traverse a grid (grid movement) and interact with the environment/NPC’s
  • There will be dialog
  • There will be dungeons.
  • There will be item management. Currency, consumables and equipment.
  • There will be battles.

I love JavaScript, and I like TypeScript even more. So that’s what I chose to use. It just so happens that there is a github repository with Phaser (a JavaScript/HTML5 game engine) set up to use TypeScript and webpack. Fantastic! Thanks digitsensitive!

I spun up a Trello board, wrote a small design document with the above bullet points, setup a few columns to manage workflow and added a few base todos to get the project rolling.

The current state of `the board`

To create tilemaps for use in the game, I am using tiled, a great little application that takes in a PNG tilemap, and spits out really pretty JSON objects that you can load directly into Phaser. For base tilemaps, I am using stand-ins from Pokemon Gold and Silver, with NPC’s I created in Piskel.

After a bit of messing about, I got a very basic scene of our living room using the tiles in a way I think the original designers never intended.

More or less what our barren apartment currently looks like, though replace ‘N64’ with ‘Nintendo Switch’

You can add meta-data directly to the map itself, which your game can then read and create objects from. I am attaching string messages to each object for now, but in the future, the idea is to decouple the metadata from the object, assigning it an ID instead so that you can query a database of objects.

{ "backgroundcolor":"#d4d49f",
 "height":10,
 "infinite":false,
 "layers":[...],// Object, background and foreground layers with associated metadata
 "nextlayerid":8,
 "nextobjectid":18,
 "orientation":"orthogonal",
 "renderorder":"left-down",
 "tiledversion":"1.2.3",
 "tileheight":16,
 "tilesets":[...],//You can choose to have the tilesets used to create the map embedded into the the map.  The tileset's individual tiles can hold their own metadata as well!
 "tilewidth":16,
 "type":"map",
 "version":1.2,
 "width":10
}

Cool!

And as with most side projects, I often can’t wait to get to the dessert before eating my vegetables. I had the idea to replace the standard Phaser loading screen with something a little more…traditional:

Do you get it? Because Game Boy Color.

More to come in the next installment, where we’ll be discussing grid movement.

Keep up with the development of the game at my github.