The great borrowed warhorse desktop PC first slowed, then froze, then constantly needed a restart, then failed to start at all. Could be anything from a bad C drive to the CPU finally failing under the first real heat of the year.
I'm back on my trusty laptop, and Unity project progress will have to hang until I can get a decent replacement. I was in the middle of saving for something else so I'm not inclined to rush down to Fry's and take care of the problem immediately.
I'll continue to post here about other projects in the meantime, I'm sure I'll keep something going.
Sunday, June 9, 2013
I've managed to completely avoid my backlog for a couple of weeks, due to some combination of
- 60 hr work weeks
- Dark Souls
- Arrested Development
- making Counter-Strike maps
- working on music
- teaching myself to use Twine
- helping a friend with a screenplay
- "social life"
I had a long running note on my list that the player was too robust, too hard to kill. One easy improvement was to drop the number of lives from 4 to 3, but that didn't really do it. I had set the player up with a sort of health bar system, and no enemy was likely to bump into a player more than once, so you had to kind of deliberately let enemies hit you in order to even test the health system. It looked like one of those tasks I might have to shrug at, and compensate by making the game harder in later levels.
At the same time I was finally getting around to drawing three different bullet types for the three playable characters. The bullet, as I may have mentioned, was a total freebie, all I did was draw a very small texture on it and then I scale the object up as it moves, bounce it off things, and it looks moderately OK, at least in context with the other graphics.
When I had plugged these in and was messing around in-game to see how they looked (I eventually ended up darkening the background tile spritesheet so they would stand out more), I was brought uneasily back to another design problem from earlier in the project: I had this sort of neat feature of sound-wave like bullets bouncing off things and each other, but apart from the fun visual you get when you spam a bunch of these, there's not really any point to it, and the player can just wander around the map spewing these cones of death that obliterate any enemy in sight. I had turned over the idea of limiting the player's shot frequency or introducing some kind of "energy" mechanic that shots would deplete, but that all felt pretty half-assed and I was loathe to go there.
Now, these two problems came together in my mind and I impulsively made two changes: I added the player bullet to the list of things that would damage the player, and I made it so that the player would lose their weapon when damaged, rather than when killed.
Suddenly, I had a different game. The character could still greet every threat with a massive fusillade of sound waves, but when those waves bounced back the player could get hit, which would remove their weapon. The player can pick up another weapon, but that means finding the right platform and making it there without being touched by an enemy, and doing so will eat up precious time ... suddenly there is some gameplay where there wasn't any before. It's not the most compelling experience in the world, sure, but now there's something to do, there are risks, there are potential strategies even.
There are two things that I intend to take away from this:
- You don't have to solve every problem right now. If I had forced my way to a solution to the "player too robust" issue earlier, I might not have had the opportunity to try out this new mechanic. Because I trusted I'd be able to improve it eventually, and kept my mind open, I was able to recognize a solution when it presented itself
- You do have to keep all the various aspects of your project in mind, as much of the time as you can. This "problems solving each other" thing only happens when you are simultaneously down in the weeds and looking around at the bigger picture. It's easy to put blinders on and just chip away at a single feature until its finished, but it might make more sense, and produce better results, to see all features as co-dependent, and allow changes in one to suggest possible refinements to any or all of the others.