My Cool Playdate Mech RPG

devlogs
,
1

Hi everyone! I’ve been putting off sharing anything about the game until it was Visually Presentable, but finally accepted this is still years away. So let’s document the progress as it happens. Alright, let me channel my best nintendo direct impression:

My Cool Playdate Mech RPG (working title) is a game of Strategy, Romance, and Giant Robots for the Panic Playdate video game console. Set in a sci-fi world of space feudalism, where great Noble Houses wage civil war over scraps of imperial periphery, create your own Mech Pilot and assemble a ragtag team of Nobles, Mercenaries, Pirates, and more! Customize your fleet of Mechs and take it into tactical, turn-based battles, both planet-side and in outer space. Strengthen bonds between your squadmates by having them fight side-by-side on the battlefield, and in the off-time get to know them through visual-novel style story scenes. Forge frienships, rivalries, and maybe something more? Mount your Mechs and shape the fate of the galaxy in My Cool Playdate Mech RPG (working title), coming to Panic Playdate at uhhhhh some point. Like 2029 or something

Screenshots (literally all of the visuals are currently placeholder)

select unit

engagement preview

dialogue

options

Ok enough of that bit. MCPMRPG(wt) is an SRPG, chiefly inspired by Fire Emblem and Lancer. It has character creation, grid-based tactical combat, build-crafting through equipment, and cross-unit relationships (both player-companion and companion-companion). It will have dialogue options for role-playing purposes, but most likely no significant branching in the story.

I’ve started on this project in May of 2024. Been wanting to make something for the Playdate since basically it’s announcement, and wanted to make something mech-related, and playing Fire Emblem Fates at the time I thought “Here is a simple and exciting idea – Fire Emblem + Mechs! It’s just a series of stand-alone maps with straight-forward turn-based mechanics, how long could it possibly take? Like 2-3 years tops?”. Turns out, unfortunately, a game even of this modest complexity still takes one person working part-time like 5-6 years (and that’s still an optimistic number at this point).

By the end of 2024 I’ve had both combat and dialogue systems pretty much working. And since then I’ve been stuck making everything else around it! Menus, turns out, take a really long time.

List of what’s currenty in the game:

  • Main menu
    • With the ‘Press Any Button’ message! Surprisingly satisfying to implement one yourself, makes me think about video game conventions, how arbitrary they actually are, and yet how we continue re-create and perpetuate them. Every ‘Press Any Button’ screen in every game before did not magically appear on its own. A human looked at other games, thought “we need one too”, and diligantly re-crafted it from scratch in the image of those other games. I kinda love that
  • Save/load menu
    • With support for multiple characters, manual saves, and separate categories of auto-saves (before starting mission, before deploying to combat, start of each turn)
  • Basic character creation
    • Currently you can enter your name, mech name, and choose both third- and first-person pronouns. A handy preview demonstrates an example sentence to show how those will look in-game. Editing your character’s visuals will happen at some point.
  • Mission selection screen
    • Currently just a list of names of available missions. At some point I plan to make it more visually interesting
  • Mech equipment management menu
    • Unit can equip a number of weapons, Systems (passive-ish bonuses, aka perks aka feats etc.), and a Frame (determines stats + can come with pre-installed Systems)
  • Relationship menu
    • Check relationship levels and access unlocked scenes
  • Combat
    • So many things implemented here, attacking, aiding, pathfinding, status effects, enemy ai, VFXs, etc.
  • Cutscenes
    • I’ve ported my dialogue system from Godot to Playdate, and so can use my Dialogue Editor to write branching dialogues. Additionally I’ve implemented a veeery simple scripting language to direct simple cutscenes (move units around, move camera around, etc) and integrated it into the dialogue system.

List of things curiously still missing :

  • All of the art
  • All of the sound
  • All of the writing

Whoops! Turns out I made the rookie mistake of getitng stuck in pre-production hell and am yet to start actually making the actual game. All the visuals including UI are currently placeholder. Current mech sprites are by blobertson. I did technically have some writing done – world-building and a rough outline, but those hardly count.

Thank you for reading! I have several posts planned about technical and design aspects that I found neat, and will try to log my future progress as it happens.

2

Since you’ve also talked about the dialogue editor here I’d be interested to read about this process. How much of the original work was stuck in gdscript/c# etc? Does the work of “porting” mostly just mean implementing something that can parse files?

Also, importantly: what do you use the crank for in this?

3

Yay, RPG! How did you program the enemy AI?

4

I’m also here to ask how the crank is going to be incorporated!

I very much hear what you’re saying in terms of “my whole life is menus”, it feels like UI work is never-ending. I try to remind myself that the way players interact with the game UI kind of IS the whole game, particularly if you’re making a more menu-driven game like you’ve described.

Anyway, I’m looking forward to seeing how your work progresses!

5

Thank you for your intereset!

For the sake of porting, the dialogue system is three parts - the editor, the files it produces, and the runtime logic that works with those files. Editor logic remained basically untouched. Runtime-logic was ported over a long weekend of copy-pasting classes one by one from GDScript to Lua and adjusting the syntax lmao. As for files, I really did not want to parse Godot’s .tres format. So for the editor I implemented a JSON exporter, and then in Lua I parse those .json files into runtime data. The current workflow is: I open a Godot project (since i still haven’t had the time to fully sever my editor from it), work with “source” .tres files in my editor, and upon saving they are automatically exported as .json into a corresponding folder in my Lua project. Not the cleanest, but it gets the job done.

Enemy AI is nothing fancy, enemies don’t coordinate with each other nor think several moves ahead. I’ve implemented essentially a simple utility-based AI. There are two verbs - attack and aid. On its turn, unit looks at every target it could attack and every position it could do so from, same with aid. Then for each position it evaluates a scoring function. For example attacking score depends on how much health attacked unit will have left, whether you get counter attacked or not, how far you need to move to get there, etc. Then it just moves to the highest-scoring position and performs that action on target unit.

Game design-wise I’d say this is good enough. State of the board changes too dramatically turn-to-turn for multi-turn planning to be meaningful. And some complicated enemy coordination is not communicated to the player, so would remain barely noticible anyway. At most I’m considering a heuristic where units with buff/debuff abilities should act first, and regular attackers should act second.

Regarding the crank, currently there are no plans for it. I find it best suited for inputs that require analog precision, which is simply not a thing in a very discrete turn-grid-based game. I’ve considered it for maybe radial menus, or as a mini-game to charge up powerful attacks, but ultimately these all seem like gimmicks. Not particularly additive to the experience and could become tiresome, solutions in search of a problem.

Personally, I was never especially enthusiastic about the crank. Playdate instantly enamored me with its 1-bit screen, form-factor, and independent nature, but the crank, while fine, fun even, is just not useful for the types of games that I like and want to make.

6

I think you could make some truly creative crank-based attack-charging mini games if you wanted too, like in Paper Mario. But if that’s not the kind of game you want to make, then that’s totally fair!

7

I find games on Nintendo platforms to be frequently annoying because they try to find a use for Nintendo’s goofy hardware, whether it makes sense or not, and it tends to detract from the game. I see the crank as a similar thing, but even more weirdly specific. I make pretty straightforward games and unusual modes of input do not interest me, so I doubt I’d ever have a use for it.