Here is a post for wrapping up this game which I motivated myself to write to not repeat issues in my next game:
Things I would do differently next time
After completing my first published game The Princess And The Tower, here is what I would do differently the next time.
Experienced devs will probably tell me that is "Captain Obvious" stuff, but I wished I had done it from the start in my first game.
Some facts
- Game style was a point and click adventure (NSFW) with some minigames / strategy elements
- The game was a renpy game, but mostly written directly in python (70%)
- Did not count the code, but probably 20.000 lines of code and 10.000 lines of renpy dialogue
- It was a single person project and I spent about 700 hours on it for 7 months or so (was kind of a holiday project)
- Art was done with Blender, DAZ and Photoshop.
- Sounds/music I used available assets.
- It was released in 7 monthly releases with incremental content updates.
What I will do better from the start next time
- Proper Art Asset Management (in SDE and in game folders): "OCD-ish" naming convention for all dev files and finished assets, properly structured subfolders and asset "house cleaning" every month or so. At the end I couldn't find assets, had inconsistencies across 3D character and item files and also only one flat in-game folder with a zillion image files.
- Quest System I: Use a state based quest system from the start, high quest granularity, "auto-update" layer that runs through the state machines and quest DB instead ofrelying to kick off individual quest transitions in the code. Also use the state transitions to autofill quest / help logs and direct control flow. Introduced that from V0.7, had to rewrite the old crappy quest code for weeks and wish I'd done that from the start.
- Quest System II: Bundle all quest data objects (which include title, quest help text, trigger and completion conditions) in a single file, so I can "write" the quest logic in one single location and not lose track
- Grinding/Convenience: Consider players with no beforehand game knowledge / replay experience and make quick progression not so dependent on game experience. Maybe add some redundant pointers to dialogues to push new players in the right direction
- Appeal/Accessability: More "visual" aids for the NSFW appeal (not everyone can run scenes 'in his/her' head). And of course more animations are always welcome.
- Game Flow: When doing multiple endings, plan them properly, make sure there is no interweaving of endgame quest-lines or secret items that unlock endings without mentioning them. This was quite messy for endings two and three and also the cause for a bunch of softlocks, player frustration and the need for bugfixversion (which was 0.9c), etc.
What went well and I'll do it again
- CRM: OCD-ish state based CRQ list (any excel list will do, ...) with target version planning, effort estimates, CRQ-state
- Testing: Find interested and capable Beta Testers, which help greatly in meeting deadlines
- Planning: "Release date first", postpone content elements to next update if schedule would slip
- Staggered release (beta testers -> patreon power users -> all patreon users ->public) to not be flooded with feedback & bugs
- Story: Focus on few characters rather than a large bunch of forgettable randos
- Feedback: Collect feedback on dev sites to content & features. Sites I used for that were F95Zone, itch.io and of course Patreon, definitely worth engaging there with the community
Maybe there is more, but this is what came to mind. The whole marketing / promotion angle I didn't assess, probably could have done most there to (was far away from 10-15% of time and earnings rule of thumb)
I published the game to force myself to finish something and not leave it 20% done (as my previous non published stuff) and move on to the next thing. That part worked
Thanks to everyone for feedback to the game and suggestions!