How has the Month been for Stillness –
about as productive as expected for a month involving the end of a particularly brutal school year. a little work was done a the months start, then dried up completely in the middle, and only now has started to resurface at the end. So my projections for myself were pretty spot on.
What I said I would do (and did it get done) –
- make a clear “end” for playtsting purposes – (done)
- make playtest survey for online playtests – (done)
- general playtest at least 3 times (hopefully more) – ( sent out 5+, got 3 playtests back)
What got done-
thanks to the playtest data I got, several little bugs or other issues I didn’t know about were fixed in the build. unfortunately, I only barely got as many as I wanted, though I sent it out to a fair few builds. in general, playtesting served as useful finding bugs. as the sole person working on the project up to this point, I know what everything is “supposed” to do, and act accordingly in my own tests, so there are plenty of things I simply cannot find on my own.
for example: Saving breaks the game!
because the how the game handles saved data, I have kept it in debug mode for 90% of my tests, which actually clears out several potential order of operations issues you won’t encounter playing the game, but will encounter testing. unfortunately, it did create some of its own issues, as testing found out. since how I’m currently debugging is, I’m wiping the save file each time, I never would have found that having played a previous build of the game will break the current one! yeah, they’re both accessing the same file, but newer builds have changed save values, causing a crashing error! I was able to quick fix it for the tester, but it is something I need to be aware of, going forward.
I will probably include the wiping of any previous save file in any playtest build from now on, just to be safe. it would basically disable saving as function, but that is currently not that big a deal, since there isn’t enough content as of yet to justify saving.
another issue with saving, as I found out near the month’s end was it crashes the game in another, separate way! basically, Unity is very particular with what it’ll serialize, and sprite’s ain’t one of them. so, a simple (if slightly time consuming) fix, and that issue should be dealth with.
I won’t go over every bug testing found, and fixed, but I do want to examine on other thing playtesting highlighted thatI was afraid of. A lot of the game’s mechanics are not clearly explained! specifically, the game’s more unique mechanics like the thought system. as is, interacting with the system is… clunky, to be nice.
part of that has to do with the fact that Unity’s Canvas system was just not designed to be used how the I wanted the thought system to function. having what amounted to dynamic, moving, intractable buttons on a UI canvas is, in retrospect, a bad decision. Hindsight, I suppose.
there are other issues present to how thoughts are handled right now, beyond that systemic issue. movement of Thoughts is near nonexistent (a product of making them on the canvas). how I am calculating their lifetime was very askew-ed, resulting in really low lifetimes. finally, how long they are held in the player’s “memory” is really low, resulting in long stretches of time where no thoughts were on screen.
so, in fixing that issue, I’ve moved the thoughts system to no longer require the UI canvas, and redid all the math behind the system, to (hopefully) be more satisfying, and easier to use. it is definitely easier to work with on my end at least, and should allow for some more fun expanding of its abilities in the coming months.
on the design side, I hit a pretty big milestone, wrapping up phase 2 of the main narrative outline. I’ve been approaching the narrative design of the game in a sort of 3 phase approach. phase 1 was the outlining the theme’s, wants, and key scenes for a particular quest line or what have you, and is usually pretty light and disjointed. phase 2 is where the general beats and flow of the story are nailed down. what I want to happen in the story, and making sure they align with the theme’s nailed down in phase 1. and phase 3, is the more granular details of those beats. the exact puzzles, and player actions which will lead the player thru the narratives.
even then, this approach is tackled at different levels at different times. the intro, for example, which is what the build is currently working thru, has had its outline finished thru this system since before the semester started, while the side-quests, minor, smaller stuff I wanna include, are all somewhere in the phase 1, early phase 2 department.
this approach is also really useful for me in terms of scoping out the size of the project. currently, the intro comprises what would be 7 beats under this outline. a main quest-line, having now completed it, hits 12 beats on average, and a side quest, is currently averaging at 4 beats. so, assuming each beat has an approximate range of time/energy work needed to complete, I can predict the length of production with a degree of reliability.
finally, this beat conscious approach is needed for the game’s cyclic state system of punishment. I want certain types of failure, like social failure, to carry a certain degree of permanency without being too punishing on the player. a permanent-lite, if you will. to achieve this, I devised the games cyclic state system, where punishment for failure at certain points locks the player out of the rest of that quest line, until the player hits a reset condition, and all unfinished quest lines revert to their previous completed beat. this is, in fact, one of the game’s central project pillars, and as such, informs a lot of the design. (which reminds me, mayhaps I should make a post about Stillness‘s project pillars)
btw, if your curious, he current production build covers 2 of the intro’s 7 beats in full, with a 3rd technically implemented, but turned off.
Time Spent –
the “hard” work, I clocked as follows:
- prepped build for playtesting – 2.5 hours
- Art for bathroom, main room, and washroom – 4 hours
- Refactoring thought system to use objects over UI – 4 hours
- Remaking using thoughts, so its more like the inventory system in clarity – 4 hours
- “Emotional math” for behind the scenes thought calculations – 4 hours
- Finishing extending the thought system and emotional math – 4 hours
- Fixing the saving serialization sprite bugs – 1 hour
the “softer” stuff, the pre-production stuff, I didn’t clock. so I will be spit-balling it:
- GDD narrative outline – 4 hours on and off
What to do next-
I have 2 goals for May. one is further playtesting. I set up the framework I can rely on for repeat playtesting at the moment, so continuing to use it will be my goal. Additionally, now that school is over, many of the potential testers I can tap would be significantly more willing to give their time to test.
the other main goal I have for May is to finally refactor the last 2 big mechanics that need refactoring, the Conversation System and Progression system, to be more usable and have greater functionality than they currently do. With those polished up, content development should be the next immediate hurdle, polishing up, and detailing those beats for the Intro.
- Further Playtesting (5 more)
- Refactor Conversation System
- Refactor Progression System
Closing Notes-
sorry I got no pictures this time. not enough changed visually for me to feel justify taking time to do it.
Jesse Lozano 