Quick Post-Mortem about FalconEx

I created FalconEx for the BlackthornProdJam. It took about a week to make. 

Goals

• Improve my game-dev skills
• Continue to learn the Godot game engine.
• Get sidebars working in Godot (so I can add them to my other projects)
• Make a game with upgrade mechanics
• Improve my game-feel (juice) skills and aesthetic instincts

What went right:

No player death! When the player gets shot, they lose inventory and cash. I wanted to have a fun game without timers or death mechanics. Pirates stop harassing the player when their inventory is empty. That feels honest for a trading simulation. 

Every game needs a challenge. In this game, the "challenge" is hitting the tiny planets. Smaller planets give better prices, but it's surprisingly hard to hit them with your ship in a low-friction (damping) environment.

I kept the scope pretty small and dropped high-concept features if they weren't fun. It turned out to be a relatively basic space-shooter. Most of the controller code for space-shooters is available in many tutorials. The only unique or challenging components were: 1) selecting planets from a list on a sidebar, 2) having point gravity with orbital star systems, 3) buying and selling commodities. During development, it seemed like a big challenging indie concept game, but in the end its a pretty standard game. I didn't push the envelope too hard.

I set up infrastructure right away: dialog boxes, sidebars, viewports. That meant I didn't have to worry too much about those details at the end of the submission period.

Using a ttsreader to generate voiceover is perfect for science fiction games.

Upgrades feel really good. Most of the upgrades provide immediate visual and auditory feedback. (storage and magnets are a bit boring compared to the rest)

What went wrong:

For a jam-game, I wasted a lot of time on trivial problems instead of finding workarounds

• pause menu - lerping animations and position in canvaslayer wrt multiple screen resolutions (The pause menu was meant to slide up from the bottom of the screen, but I put it on the wrong scene. It should have been on the root scene and should have reused code from the other sidebars.)
• DampedSpringJoint2D node lengths and stiffness (planets kept falling behind their stars, so they trailed the star like comet trails. I had to ramp up their velocity and tighten their springs to make them keep up with the stars.)
•  _draw() function global coordinates vs local coordinates (which object should draw this line?) (lines appear in inexplicable places because the _draw function expects local coordinates instead of global coordinates. It should be easy to fix with to_local(), but that didn't always produce reliable results. So it's important to select the best possible node for performing draw() actions )
• html export doesn't render well on chrome - probably because of multiple viewports (My own fault for using beta builds. But I wasted a lot of time troubleshooting and refactoring for this. In the end, I just had to turn off the html export.)
• the inscrutable Control nodes and size flags (getting gui elements in the right place seems like voodoo. I had to cheat by inserting node2d nodes between some control nodes which allowed absolute positioning.)
• parallax backgrounds don't work well with camera zooming (When the camera was zoomed, it created a lot of texture shifting, as if the character was moving, even though the camera margins were set such that the character stayed in the center of the sreen. Probably a simple flag on the textures, but I didn't have time to investigate it. So I took out the parallax backgrounds.)

leaving music to the last minute was a problem. I like to do everything myself, but I didn't have time to compose my own music.

I should have created multiple enemies from day 1. Having a single type of enemy makes the game feel a bit flat. I ran out of time to add more enemy types. 

I added game-feel elements a bit too early. Once the game starts to feel polished, it seems like every new feature breaks a lot of work, so instead of refactoring to fix architecture, I was reluctant to add new features.

The game might be too easy for the hardcore crowd.

I started using github too late in the process. Next time, I should make the github project right away.

There's one lingering bug which is really frustrating. Sometimes the game doesn't respect your destination selection. If you click a planet from the list, it'll light up, but then it'll switch planets on you. If you're en route to a planet, sometimes it'll drop the destination. If you attempt to sell to a planet that appears to be highlighted, sometimes it won't sell. I can't figure out if the bug is in the UI code, the inventory code, the planet code, or wherever else it might be. If you're reading this and have an interest, take a look at the source and let me know if you can figure it out.

Features I had to drop, and might like to add back in if I continue development:

• Dynamic economy: planets should change their prices based on supply and demand.
• Enemies should have more behaviour: grab commodities, attack planets, flock when attacked.
• Galaxy should have a "heat" system to increase the threat level based on the situation (player upgrades, cash, inventory)
• Planets should fight back against threats.
• Each star should have its own point gravity.
• Options to make the game more difficult
• Warping to new galaxies
• Boss battles
• Quests
• Game options, particularly difficulty modes.