Game Jam Postmortem

My general leading philosophy with art is to show not tell (to the degree that any novice can have a hard stance on any thing, which is very little). In regards to that aspect alone, Scra-P is a failure through and through. Nothing is animated or conveyed visually, turn options are deluged in too much data, and the most exciting feature for me (part absorption) was never implemented. So where did things go wrong?

What went wrong

Arguably the first mistake was even attempting an RPG at my skill level since implementing the combat system ate so much time, but I think that is too reductive to be helpful for learning. So I’ll pose this differently- how could I have changed my priorities to make an at least somewhat unique RPG in one month?

My first avoidable mistake was after I laid out a draft of mechanics. My original idea looked something like this- the frame determines base power, HP, defense, and Speed (tie breaker for who moves first). Then the different apendages have their own actions that modify base power to determine attack strength, their own accuracy, etc. Sound familiar? Yeah, it’s Pokemon. Literally base stats and 4 moves, the only thing missing was type advantages and phys/special splits. But that in itself isn’t the problem; the problem is that I said “Oh well I can’t look that similar to Pokemon, lets do something else!”

A lot of us designers like to overthink designs, and get squirrely when we realize or perceive something we’re working on as too derivative. “This platformer is just reskinned Mario Bros” or “This metroidvania looks like 100 others in the genre” or in my case, “this RPG is just Pokemon”. It’s a creative poison because everything ever has been done at least once somewhere. There are no new ideas, only remixes. Once upon a time two people ran to another spot for fun, and every game since then is merely a remix. What I should have thought instead is “Oh cool people already know how pokemon works, this will be easy to pick-up” and started working through my differentiators.

What I did instead was I distributed HP and Defensive stats across all of the parts, (which honestly was a decent idea anyways), treated the frame as any other part with it’s own action, then tried to add strategic depth by having an interplay of durability, speed, and cooldown. In theory this should have led to situations where you need to decide between using your limited supply of powerful attacks, found places to pepper in fast attacks with long cooldowns, or swung hard with slow attacks that left you vulnerable to possibly multiple enemies attacks while it charged. These were uncommon concepts in an RPG, but common place in action and fighting games. In those contexts, you’d think of durability/speed/cooldown as MP/meter, start-up frames, and recovery frames. The problem is that start-up and recovery are accompanied in those games with ~animations~. You can watch the character wind up and wind down, you can mash buttons until the animation has finished. It conveys organically for any person to ever swing a stick or throw a rock, because we have an innate understanding of the physics and timing behind actions. Text output conveys none of that. The end result is that someone reads the instructions, tries to stuff that somewhere in their understanding, then inevitably just uses the button that deals the most pain reliably. Some animation would have helped, but I don’t think it works well conceptually with a turn based RPG.

What went right

My favorite implementation I used for this was actually in my state manager. It looks something like this-

game_states = {title, combat, pick_part} game_state = nil

function _init() game_state = title end

function _update60() game_state.state_update(); end

function _draw() cls(6) game_state.state_draw(); end

title = {}

function title.state_update() if btnp(5) then game_state = combat end end

function title.state_draw() print(“title draw”, 2,2,1) spr(4, 60, 60) end

This bypasses the need for somewhat messy “case statement”-esque code where the state variable is a string checked against all state possibilities until a match is found, executing the code in question. By setting a single variable (game_state) to the state I’m in, I can feed in generically named functions like state_update as well as store state specific variables outside of the global context.

I think my mid-way through pivot was a good idea- namely to deliver information through text. It was straight forward, the interface all fits on one page cleanly, and without it there was a mess of things happening that weren’t noticable otherwise. It’s ultimately a band-aid, but one that let me turn in a playable project.

I also didn’t refactor my very messy code! OCD brain didn’t win this particular fight!

The original idea still has some merit- you could even pitch it as “What if Pokemon but you steal the moves or bodies of your opponents after each battle”, which sounds kinda rad actually. I’d play that romhack. The execution and overcomplication was my downfall, but the idea will stay on my shelf for a while.

TL;DR: I should have ignored the inner voice that said my game would be a ripoff because everything starts as a ripoff until you add your own spin and flavor. Learned some cool new coding techniques and might try again some time, but at least half of the project isn’t worth salvaging.