This has been one interesting year for me as far regarding game development, with an exciting new project I'm tackling with a very capable graphic artist and an equally good composer, a local multiplaer game about blind people and guide dogs I wormed on alongside a small team for a local game jam, and an interesting game competition I'm making a game for that ends on the first week of January. All that was interesting and helped me do some things I hadn't done before, but it also meant I didn't get to work on Quark Storm much, if at all.
^(moving the checkpoint there from its previous position will probably reduce the number of mice flung against walls by 47%)
However, that changed as the yearly Argentine Videogame Expo (EVA) crept closer, as I knew I wanted to have a demo ready for the event's Indie Showcase, and that showing the game on a tablet or smartphone would be a way better idea than having people play on my laptop. I had a goal.
^(having see-saw platforms on both sides was kind of a jerk move against anyone playing the game, so half of them became static platforms)
For quite a while, I had been thinking hard about what would be the best way to handle the game's brake system on touch devices, but none of my ideas were quite what the game needed. It was during the first day for the EVA, as I was showing the game to a fellow developer who was showcasing a game that reminded my friends and I of Quark Storm, when I mentioned the brake issue and my friend simply replied with "Why don't you register explosion firing when the touch is released rather than when it's pressed, so you can avoid accidentally creating an explosion whenever you wanted to brake?". The best solution had been right in front of my eyes all along, only I had looked for it in the wrong places! After hating myself a bit for not having come up with this solution myself, I thanked him and decided to try it out.
^(the drag-to-change control method for the settings screens work nicely for touch devices, I'd say)
The next day, I spent a few minutes at the start of my showcase shift to code the new input implementation, and lo and behold, it was really intuitive and also worked perfectly! Seeing people enjoying themselves as they played Quark Storm on my smartphone and tablet made me realize how much more intuitive the game's touch-based controls were in a platform based on that kind of input (to this day, I still remember how many people used to put their left hand on the WASD keys as soon as the game begun when I showed it on a PC the first time around).
^(Android playtesters said they couldn't find the left and right mouse buttons on my test devices, which made me realize it was time I got around to properly localizing hints for mobile devices)
Some people who tried the game had already played it on the previous EVAs' Indie Showcases, and it was good to heard they all thought this newer demo was a lot better than the previous ones. Two guys even told me they had played the browser version for a while, competing between each other to get the best times, which was an awesome thing to hear.
^(the goal screen as seen on a Samsung Galaxy Tab)
After the showcase was done, I went on to work on some other stuff, but I had promised a fellow developer I had met that I'd get him a playable demo, so I knew I'd be doing it relatively soon. During a weekend, I tweaked the GUI so that it'd scale regardless of the display's resolution, since Unity's default GUI wouldn't work there due to it being pixel-perfect; some days later, I tweaked the levels based on player feedback, and thus I was finally ready to release a new public demo!
^(the goal GUI as seen on my Sony Xperia Tipo's itty bitty display; the font's probably going to need some tweaking here)
- Tweaked levels 1-2, 1-3 and 2-1 according to playtesting feedback: 1-2 no longer requires as much wall-jumping as before, 1-3 is slightly easier and 2-1 no longer hates your guts and punishes you harshly for the smallest mistakes in the first section of the level
- It was fun while it lasted, but level 2-2's checkpoint no longer gives the player the ability to create explosions in midair after respawning. Seeing this bug in action reassured me that not allowing midair explosions was the right thing to do, since it was as broken as hell
- Remade the in-game GUI using a method that isn't pixel-perfect, and therefore works on anything, from 320x240 Android devices to 1920x1080 HD computer monitors and beyond (*)
- Changed the localization for Android devices so that it no longer references mouse buttons, and talks about touching the screen instead
- Made the input for Android devices fire explosions when you release a touch rather than when you press it, making the brake more useable
- Known bug: Level 2-2's checkpoint may randomly refuse to work, plunging the player character into an endless cycle of death and rebirth. While it does sound sort of poetic, it means you're effectively stuck there forever, and nobody wants that, right? To remedy it, press the Escape key on desktop builds or the back key on your Android device to bring up the pause screen, from where you can restart the level to try again or just go to the level select screen if you want (**)
(*): The GUI might not look that good when stretched to really large resolutions or squashed to really small ones, though. "Nearly anything" is a figure of speech, and doesn't include things such as PCs running on console-based operative systems, quantum computers, Nokia 1100 phones or squirrels.
(**): It's quite likely that very few people even knew about the pause menu existing at all since it isn't mentioned anywhere in the game, but that'll be fixed once I come up with a good way to handle it that works on both desktop and mobile builds, or perhaps some platform-specific implementation for each of them.
I'll probably be busy with my joint project and the game for the competition for a month or so, but once the competition's done and the joint project's further along, I'll go back to working on Quark Storm semi-regularily at the very least. I already have a few ideas I'd like to try, both for level designs and for new game elements, but that'll have to wait a bit until my schedule isn't as crowded as it is right now.
A minor update that fixes the Ouroboros Checkpoint Syndrome might be doable somewhat soon, mostly depending how deep I have to debug to find the source of the error and thwart it once and for all.