© 2023 by Andrew Jonhardt. Proudly created with Wix.com

  • Andrew Jonhardt

Scheduling and double-tapping

My efforts this past week have been focused on 4 things:

Scheduling.

Planning assets.

Coordinating an art test.

An initial version of the main character for Project Splatter.


I actually started with the asset planning, oddly enough. Project Splatter has been bouncing around in my head for years, and I'm fairly confident in what I want:

  • Top-down 2D perspective

  • 16 levels

  • 5 Bosses

  • 9 Base foes

  • 5 environmental hazards

  • Powerups

  • 1 Attack

  • 8 directional movement

  • The ability to dodge instead of jump

Working from this baseline, and in combination with a very basic game design document, I've built out a list of (currently) 1035 assets. Floor tiles, with variation, sprites to be assembled into animations, and a handful of 1-panel scenes to be combined with text to serve as cutscenes.


I'm doing my best to plan for reduced cost in production, but I also know it's too early to be betting on the final asset count. The point is the experience of pre-production, something I don't think I've ever attempted on a project before. Even Redline was born of an existing board game prototype, and couldn't effectively be planned out due to my own questions regarding my Unity skill.


The biggest aid in figuring out how I want pre-production to go has been the potential for a collaborator, even if that collaborator is essentially a contractor. If Project Splatter were just me, I'd care far less about scheduling and just get started. Trouble is, especially when money is involved, half-assed scheduling feels like a recipe for pain.


The art test I assembled for my potential artist is very basic. It was simply extrapolated from my existing needs. Sprites, tiles, a big scene. I've been working with him to confirm what I want from the test, and to iron out confusion points. Even if our collaboration fails to materialize, I'm confident we're both learning a great deal from this experience. He's learning more about the technical side of game assets, and I'm learning how the heck to explain what I'm looking for.


In addition to all of the scheduling and art-planning, I took time out to begin prototyping my main character. I, of course, want him to feel good to drive. I don't think I'm quite there yet, but I got enough done this last weekend to move on to the next set of prototype assets.


Meet Jack:


At the moment, Jack can:

Move in 8 directions.

Punch in 4 directions.

Dodge (that red flashing) in 4 directions.


Punching took a bit of effort. I want 1-button punching, but there's 8 directions to deal with, so I've got Boolean variables tied to the current direction Jack is moving in. If he's moving forward, he'll punch forward, etc. Eventually, I'm going to expand on this system to allow Jack to punch in 8 directions.


The biggest headache in getting Jack working has been the dodging. I originally wanted dodging to be tied to the movement keys through double-taps. Tap, say, the A or Left Arrow key on the keyboard twice, and Jack would suddenly dodge left.


After some investigation, I've decided double-tapping may not be the way to go.


Firstly, double-tapping is a bigger technical headache than I expected. It's possible to jerry-rig something with a bunch of timers and Booleans, and I got a basic version of such a system working, but the result took a ton of work and was really bloated, ugly code.


Secondly, there's a community of people who hate double-tapping in PC action games. For some, it's a question of preference. For others, however, double-tapping is a physical hurtle that impedes accessibility.


My current version of dodging relies on holding down 1 extra button while pressing a movement direction. Some additional work will be required to allow dodging in 8 directions, but the work isn't what worries me. What worries me is that holding down 1 button doesn't feel good.


In every other action game I've ever played with a dodge option, the button you use to dodge is simply a block button whenever you hold it down and don't move. It's only when you attempt to move while holding the block button that you realize you can roll or whatever. Still other action games, console games, map the roll function to the left stick on a control pad.


I don't like either of these options for my game. I wanted to keep things simple: attack or dodge. No standing in place, no pretending you're safe, always moving.


I'm considering the idea of a default dodge direction you can alter by holding movement keys. I'm not convinced this would provide players with the most accurate option. However, regardless of my feelings and wish to experiment, I need to move on.


This weekend, I'll begin prototyping player tracking and the first in-game enemy. The plan is 1 to 3 large programming goals/foe prototypes per weekend for the next 7 months. If all goes well, this prototype will be done by the end of February, and I can immediately transition to beta testing and bug squashing.


Until next week.