James Johnson
Technical Designer
The Knight who Need No Steed
A short game about a flying knight battling an evil wizard tower
Project
-
Team Size: 7
-
Role: Project Lead, Design, 3D Modeling & Animation, Programming, Music
-
Tools: Unity, C#, Beep Box
-
Development Time: 1 week
-
Platform: PC, WebGL
-
Download Link: itch.io
The Team
Features List
-
Physics driven player movement
-
Two dangerous spells to evade
-
Three Levels of increasing difficulty
-
A custom soundtrack
The Beginning
For the 2025 GMTK jam we received the theme of 'Loop'. I led with a strong idea that I was confident in and so we added it to the workshop. After discussion, tweaks, and merging a few ideas together the team landed on a endless runner style game featuring a renegade knight who has cracked the secret of flight!
I would work on about every aspect of the project from task tracking, to programming, to music. My main job was to guide the vision of the project while developing systems and architecture to support each feature.
Running the project | Project Lead
There were a few challenges facing the team during the lead up to the jam
-
Many of the team had not worked with each other
-
All members were online and working out of three different time zones
-
Everyone except myself only had part of the week to work on the game
My goal was to get these six goofballs working on one project seamlessly. Luckily they made the process easy.
The development followed a flow similar to the graph below.
The 'Goofballs'
aka 'My Amazing Team!'
Each day we'd have a group meeting, play the build, and I'd hand out tasks to work on. With such a small window of time, each hour was precious, and it was up to me to figure out what was top priority.
The highest priority tasks satisfied 3 conditions:
-
Removed blockers for other tasks
-
Could be made without dependency on other systems.
-
Helped find the fun
After day 3 the core systems were set and the team was settled in. We focused on fleshing out what was already there.
Targeting these items first made this my first frictionless Game Jam. Five days of uninterrupted development, no dependency catastrophes, no freak bugs, and we finished several hours before the deadline.
I tracked the progress of the whole project on a standard sheet of A4 paper. Like a DM keeping players character sheets between sessions, I always had the task list right next to me. Physical task tracking has some kind of magical effect to make things run smoother.
I suspect it worked because of how rudimentary it was. If someone wanted to check the state of the project they knew they'd need to get the most up to date version from me. That dependency kept the team tight despite us all working remote.
Task tracking done quick and dirty
A Modular Approach | Programming
While developing the idea and design with the team I made sure to keep a few technical limits locked down.
-
Only 1 player character with only 1 hit point
-
A sequential level system
-
Unified start & end condition
These three constraints are my most efficient ways to stop technical scope from ballooning.
First system to tackle was levels and data.
I've had too many projects go through crisis right before the finish line because build order got changed in the final commit. I also don't like how Unity doesn't support serializing scenes.
Fixing that was a top priority. I set up a game manager singleton to handle scenes and the important data for the level.
The team could access important level data quickly and from a centralized location. It did not require initialization, didn't care about load order, and was easy to understand.
Far less complex than dependency injection, and much more organized than serialized fields. It was the perfectly sized system for the project at hand.
Both the level scripters and system programmers could interface with the level data without conflicts.
What's better is avoiding dependencies all together.
My main request to the systems programmers, Joel, Izzy, and Jake was "If it can work while only dependent on unity classes then it is inherently modular"
Rather than grabbing a reference to the player traps should simply respond to things which fly. If we were to add birds into the game then the towers should shoot at them also.
For this we used unity triggers & tags. The triggers worked well but the tags are prone to error and very limited. If I were to do it again, I'd use interfaces as identifiers.
Magic Missile Tower
3D on A Budget | Animation & Modeling
Without a 3D modeler on the team I decided to give it a go.
Without blender installed and with no rigging experience I decided to keep the main character's design simple.
The character was modeled out of cubes I morphed using ProBuilder.
Joint's made were made from a hierarchy of empty game objects.
A particle system with localized physics gave the knight his plume.
With our hero set up I was able to give him some simple FK animations.
Not bad for few hours of work.
As an added bonus, the in-engine rigging made it easy to make a ragdoll version.
Looking Back | One Year Later
The game was an absolute blast to work on and did very well in the Jam overall.
I didn't know it at the time but it's rare to get a workflow running as smooth as this. We had no interference, a good handle on scope, and systems which were fun from the get go, (I couldn't have asked for better team either).
Having gone from this project into a year long production I've found that there are a few key takeaways I should have recognized.
-
System complexity can limit creativity. Unless you make a interface to hide it people who use it will get bogged down. Keeping things simple and predictable can lead to surprising & creative solutions.
-
Never split the party. What goes for dnd goes for game dev. The more isolated your teammates are the harder it is to keep that creative magic alive.
-
If it's easy, do it! Undoing a change is as simple as git undo. There's so many cool things you can discover by experimenting with random systems.
Now go destroy some evil wizards!
