4.1 JetCat
Team size: 11 (3 Programmers, 3 Artists, and 5 Designers)
Duration: 6 days (2 weeks)
JetCat is the perfect marriage between Frogger and the the genre we all come to love; endless runners,
all neatly packaged in a multiplayer wrapper. The primary player controls Jet Cat a cat with a Jetpack trying
overcome the dangers of the modern world and his mortal enemies, gas spewing cars.A second player can join in any time to make life even more difficult for Jet Cat by taking control of said cars.
4.2 Goals
I wore the hat of the programming lead as well as the product owner; we started by discussing limitations. It quickly became evident that our two biggest concerns were the narrow timeframe and our experience as game developers; for many, it was the first time within Unity; luckily, both I and the other programmers had previous experience both in C# and Unity and felt like seasoned veterans in comparison. To be able to pull this off, we needed to focus on implementing features all the way rather than handing off systems that needed much work from the designers. Therefore, our first pillar was Gameplay Centric
We knew that the biggest issue was the time constraint; we had to get a working beta in three days. We could not get around it; we knew that we could keep our cost per change (which, in this case, directly translates to time per change) due to the duration of the project, as shown by the cost-by-change graph.
Therefore, we agreed that we should focus on prototype-like code. As a result, our second pillar was: "Shitty" Code
Cost Per Change Graph
4.3 The Plan
We aimed to create a foundation to help us write fast, modular code while helping our designers be more creative; we established that our three biggest hurdles were time, inexperience, and team composition. Therefore, we figured that deploying existing patterns and doing much of what we already know would expedite the architecture process and be vital for the success of the project. Going in with a plan was better than going in "blind" and ending up with the big old spaghetti bowl (See Spaghetti bowl Graph).
Spaghetti bowl graph
4.4 Execution
The architecture as a whole was a mess, with lots of singletons that had called to each other, but sometimes you just have to say it works, and for a six-day project, that was fine. As programming lead, I was involved and had to take responsibility for most of the code, especially the shitty code, since I was a part of the creating the infrastructure and implementation of every script.
I would like to present a small system that regards activating the second player. The first player tried to make his way to the end and would be controlling the character the entire time, but the second player could join at any time. If the player didn't give any input, the cars in the scene would go about as normal. The system is small but speaks to the architecture of the project.
4.4.1 Car
There are two types of vehicles within the game, both inherit from the deep abstract base class CarBehavior. The only things differentiating the cars are the models and whether or not a player can control them. The base class follows the Monolithic Persistence Antipattern and is responsible for everything from the waypoint, movement, and the damaged logic.
​
The Basic Car is the vehicle that can be controlled by the player and is therefore added to the List<CarBehaviour> within the Game Manager. (an extra bracket was added for symmetry; the class contains a lot more)
Car
4.4.2 Sort
In order for the player to just join in at any time an arrow will show what car the player can chose to join in with, the scene contains hundreds of cars basic cars which the player in theory can control, for the player to be able to choose an appropriate car, a new collection is created based on criteria then sorten by the time the cars lifetime.
Game Manager
4.4.3 Input
Set suitable cars, choses what the first car in the collection and sends it to the input manager which makes it the current car which the player can control if any input is given.
Input
4.5 Post Mortem
I really do believe that the project was a success even though corners had to be cut; we encountered bottlenecks and much of what we intended to do programming-wise turned into a big bowl of spaghetti. We successfully met all supertight milestones and presented our game at the National Museum of Science and Technology. In the end, we created all the requested features.
​
We set out to write shitty code, and we learned the hard way that prototype code should not be part of the production; we had to put out fires as they arrived. I'm not entirely sure whether this was a good approach as we had to return and fix quite a lot of stuff, even with just a few days-long project. A more organized approach would probably have saved us time and made it possible to spend more time polishing features. ​