Skip to content

June Project Update

Last updated on 11/06/2019

You might recall from my last post that I said I’d be working on an RPG combat system during the month of June. I found that time boxing my personal projects seemed to be a good way for me to get work done, but I was eager to go back to working on projects that I knew would take far more than a single month to complete. So, for June I’m trying to go from “there’s no combat system here” to “we can enter a combat and jump back out after a win or loss”.

Here’s our party in a menu
Here they are in combat

This is where we’ve gotten to in the first week:

  • The battle field loads with a set of enemies and the current set of party members
  • Enemy name displays are populated from the enemies on the combat field
  • Party names and hps are populated from the current party

Getting enemies in took a little more fumbling than I thought it would. I had a couple of difficult decisions to make with where the framework for the game stops and the game begins. Ultimately, I want to use the underlying RPG framework to build several games with. As such, I want to have a pretty clear demarcation between “this is what it means to be an RPG in this style” and “this is specific to the particular instance of this kind of RPG”. I’m getting ready to go through the same exercise with item definitions, as they’re a big part of the combat interaction.

There’s a lot of work left to do before I’m happy with a first pass of the battler. Here’s what we’re looking at, and in roughly this order I think:

  • Port over the turn taking logic
  • Port over weapon definitions
  • Port over to hit, damage calculations
  • Add in win / loss behavior
  • Add in hit, evade animations
  • Port over skill / spell definitions
  • Add in skill / spell animations
  • Add in different combat layouts
  • Add in action scene enemy -> combat transition
  • Add in over-world random encounter tables

When I say port over the X, I mean bringing it over from a simulator I wrote. I’m not sure if it’s incompetence, ignorance, or design, but testing things in gamemaker is hard. As far as I can tell, you option is “add a debug room, and play the game in slices”. Combat is important, and balance is hard, so I wrote a combat simulator in python. I found that helped me balance a bunch of the equations to give the sort of power curves that I wanted. Below are some sample outputs from the simulations.

Action points by level grow fast, but flatten out at the end
Trying to balance bursty weapons versus reliable lower DoT ones
Chance of victory at 10 level disadvantage with random actions

The hope is that I can more easily balance the combat in the python base simulator than I can in the gamemaker code. Now, I can make sure that the likely outcomes of 10,000 combats are what I think they should be, but I can’t say from the python code whether or not I think that’s any fun to play; these simulations are meant to serve as a starting point for balance and refinement.

The other thing to note is that I’m not worried about the lack of quality art assets. Place holders are totally fine for now, so long as they convey critical information like facing. My friend Steve and my wife Rachel have been so kind as to supply the art assets in the game so far. Here’s some concept art for enemies that are in the works.

Box Turtle, Falchion, Hallowed Stump
Published inGame Development