Semester Project BA4: Trash Chicken

Concept Art 1

 

Trash Chicken is a Top-Down Shooter Destruction Fantasy.
The player is a giant chicken bent on destroying the evil foxes’ city, and freeing the captured chicks from them. As the chicks are being freed, they join the horde following the player and attacking the foxes until they become an unstoppable force.

Trash Chicken was created in my fourth Semester of studying at CGL as the collaborative project, with Rick Hoppman, Caterina Böhm and Omar Ruiz.

You can download the game HERE (PC, Mac, Linux).
Or you can watch a Gameplay Video HERE.
You can read about the development process HERE.

Final Presentation and Post Mortem (Week 6)

JULY 24 – JULY 28

The final presentation is on google drive HERE.

Final Presentation

We didn’t spend quite as much time on the final presentation as on the intermediate presentation, but we had time to go over it all together after Rick made the first draft, and since everyone mostly wrote their own parts, everyone was pretty confident in what they would say.

In the intermediate presentation Omar did a great job convincing the audience that our game was somewhat experimental and related to the topic of the three wise monkeys but this time it didn’t go that well.
We received repeated questions about how our game related to the theme and genre, and we could only admit that we didn’t manage to implement them well.

All in all I think the presentation went decently. All of our group members presented their own part well without any of the typical mistakes people tend to make. We played the prototype while waiting for questions, which didn’t seem to be a good idea at first, as people were paying attention to the gameplay, but a few questions came in at the end, and some feedback as well (more on feedback later).

Game Exhibition

The Game Exhibition was two days later, on Wednesday. For the exhibition, I did some balancing and added a few more buildings to the almost empty town, fixed the mac / Linux bug which made the cursor huge and added credits to the game, which we needed to credit some assets we bought or got to use for free.
We had a few issues setting up for the play-testing. The first pc we tried had graphics issues at a high quality setting, and at low settings the camera lerp didn’t work (due to my error). We couldn’t log in on the mac we tried next because someone else forgot to log out before. But the next pc we tried worked, and it was in a pretty good spot, so we had no issues with it.
Players & Feedback

I didn’t stay with the game much because I was still not confident it was fun and anyone would play it, and also I wanted to play other games. I did routinely check on it though, whenever I could, I threw a glance to see if anyone was playing. I saw one guy playing and decided to observe him inconspicuously. He was having a hard time but after losing the second time he moved from a relaxed legs-to-the-side position to a serious all-attention-on-the-game position. Just observing this made me feel a lot better about the game.

focus on destruction

He won the game that round. After he did, I walked up to him and acted like I wanted to play the game. I asked him how to play it, and he explained it as “basically just kill everything”. He gave me a hint on which weapon was the best (the automatic) and that I needed to kill the foxes and the fox spawners in particular. He didn’t tell me to kill the “foxes”, in fact he didn’t recognize them as such, he first thought they were rats, and later squirrels. He also didn’t really know what to do with the chicks, he thought they might be helping out, but wasn’t sure what they were doing.
He also told me not to pick up the rocket launcher, because it wasn’t as good as you would think.

I watched another player complete the game in a similar fashion and received similar feedback. When I told him I made the game, he said it was the coolest he’d played that day, the most like an actual game. Since that was exactly the goal of the project, his comment lifted my spirits.

I watched a few more people play, some of them left the game quickly because they died, but I saw the winning screen when I came back one time, meaning at least one more person must’ve beaten the game!

There was also this guy who tried four or five times, his companion getting visibly annoyed.

must kill foxes

Post Mortem

We made a game that was more “game-like” than any other project this semester. There were other projects that were very ludic; TAST, Gridrunners and Unlight, but I think they were less mainstream than ours. In that regard we were successful.
However our game ended up being quite bland as a consequence. The chicks were fun and kind of novel, but as they lacked proper game design, they were not the focus of the game.
Besides making a ludic game, another goal I had was to have less influence in the game design, and not be the project leader, so I could focus more on the programming aspect.
In retrospect maybe I shouldn’t have joined Rick and Cata, since they didn’t have specific game design in mind, only this vision of a Godzilla-Chicken. As I’ve seen with projects all around, our game designers work best when they work on a project they came up with in the first place.
Sadly Omar was no exception, so he struggled a lot. I didn’t make it easier on him, as I -contrary to my prior intentions- wanted to have a lot of influence on the game design. I shot down most of the ideas Omar proposed because they didn’t fit with the vision I had in mind, it seems I was unwilling to bend it in a direction Omar could work with.
Once Omar stopped giving input the development process ground to a halt on my side, because I ran out of things to implement. It was only when I started to implement whatever, and see to the game mechanics later, that things started rolling again.
I failed as a project lead here, I did not talk to Omar properly as I should have, instead I asked him about his progress with his tasks, expecting nothing out of it.
I should have talked to him one-on-one to ask him what isn’t working for him and how we could fix it, but I only posted in the group chat, thinking he would speak up about it himself.
The biggest issue I have is that I, once again, have not put enough time into the project. I simply haven’t spend as much time on it as I could have, and that definitely affects the final quality of the game.

What’s Next

Rick has created a page on itch.io and we had planned to publish the game there. We decided not to go through with it though, as the game is lacking appeal.

In the end, I should’ve just gone with an experimental group and made something weird. Or I should’ve at least gone with an idea that was proposed by a game designer.
Either way, I don’t regret my choice, as I could find a few things to love about the game in the end.

 

CUTE CHICKS (Week 5)

July 16 – July 23

New week, still no creative input from game design. Omar did give feedback on the builds I sent the team which was important, but there was no initiative from him.

Animation

I got the final animation assets for the player and foxes, and realized my statemachine was too simple, so I reworked the system again.

foxanimator
The Fox Animator controller. Transitions are between left and right, and from walking normally (attacking = true) to walking scared (fleeing from player, attacking = false) and back.

I learned a lot about how the animation system in Unity works, and I’m glad I did, because animations were a thing I had struggled with before, and I’ll now be much more at ease dealing with them.

Chicks

Chicks were the first and only major addition to the game after Week three, but they’re my favourite feature in a game, in every aspect.

We planned on having little chicks in the game from the get go, they were in the first concept arts and they were a major part of the original vision.
However we did not decide on a way to implement them before. We had different ideas, each chick could give the player a small damage buff or they could act as meat shields, or they could be thrown as a special attack, or they could be directed by the player similar to the pikmin in Pikmin, or they could just beat up any enemies around them.
I thought the small damage buff would feel too insignificant and not connected to the chicks to feel good, Omar said them dealing direct damage would be too OP once the player has collected some chicks, and Rick noted that using the chicks as meatshields or projectiles would conflict with the player’s intention of saving them. We also couldn’t do the Pikmin approach, because that would need more Buttons and we wanted to keep the controls simple.

The first assets of the chicks I got from Rick had a walking animation, a happy and a sad animation. The sad animation was played while the chicks were in the cages, and the happy animation was played when they were freed.

Implementation

I implemented the animations first, having the chicks follow the player, still without knowing how we would implement them as a gamemechanic.

On the next day I decided to go with the idea I had liked best, so I gave them a little bit of contact damage. Since the chicks were simply following the player, this meant the player had to use the chicks as kind of a net, to maneuver them into the crowd of enemies where they would deal a lot of damage.
While this was in itself an interesting mechanic, it felt more like you were herding cows than leading an angry mob, so I gave the chicks some behaviour.

chickbehaviour
Chickbehaviour is split into two behaviours, the third (walkToPlayer) is more of a utility.

The chicks would now seek out nearby enemies and follow them to beat them up. But as they’re small chicks, they get scared when they lose sight of their mother, so they will scuttle back to the player when they are a certain distance away from the player.
For this purpose I asked Rick to make an attacking animation as well, and with all of it in place, I was extremely satisfied with the result. The chicks looked super cute and added meaningful gameplay to the game. Using their different animations allowed us to evoke some emotions in the player.

 

chickhappy
Happy Chick animation
chicksad
Sad Chick animation

I also used Rick’s rig for a pose in the presentation which I’m really proud of.

thinking
Concerned chick thinking about their future

Also…

Another important change was made to the camera. The camera is no longer locked with the player at the middle, instead it is now focused between the player and the cursor. This really increases how much the player can see, without increasing the size of the camera anymore. Increasing the camera size (field of view) any more would result in the player appearing smaller, conflicting with our “the player is a huge chicken” ideal.

I also made a whole bunch of minor changes this week, including animations for weapons, tweaks to guns and movement.

changelist
Full list of changes for this week (click to view)

 

Slow Progress (Week 4)

July 8 – July 15

Progress was kind of slow this week. There was no creative input from game design for the entire week, he made no progress on the level design we tasked him with, and no ideas for new game mechanics, which meant I had to just try whatever I could think of and see if it could work.

Changed Some Stuff

I could finally transition from whatever asset scale I had before to the planned 100px per meter scale, because I finally had a player animation. This meant I could adjust movespeed parameters and weapon ranges to somewhat near the final values.

The corrected scale also meant that the player was now larger than the buildings around him, as was planned. I decided to increase the camera size to show more of the area around the player, the game felt a little claustrophobic, and the small field of view meant that either enemies would shoot at the player from outside their vision range, or the enemies’ range would have to be very short.

I cleaned up the scene and some Scripts, exposing a few parameters and adding Tooltips to the Inspector. I did this mainly to make it easy for the game designer to change parameters in order to do some balance work, but unfortunately he never downloaded the project files.

Added Some Stuff

I implemented two new weapons, the hunting rifle and the shotgun. The shotgun shoots 16 bullets in a cone, each doing little damage, but it is devastating to groups of enemies.

The hunting rifle has a low rate of fire, but has penetrating shots. In this implementation the projectile had a maximum amount of damage it could deal (750). When it hit an enemy, the maximum damage would be reduced by as much as it dealt, and then continue flying until the remaining damage was reduced to zero. This meant the bullet could kill 5 enemies (150hp) in a row, or destroy 3 buildings (250hp) or deal 750 damage to a fox spawner (1000hp). This would be reworked later.

With the additional weapons I implemented weapon swapping. Guns would be distributed throughout the city, and collecting one drops the currently equipped weapon as a new pickup.

Post Presentation Playtest

After the Intermediate Presentation I proposed a playtesting session with the others in the semester and we had 4 or 5 different groups who wanted playtesting done, including Trash Chicken. I received a bunch of really helpful feedback.

The most important feedback that we focused on was that the players felt extremely weak, they spent all their time running away and kiting the ranged enemies, trying to survive.
This was completely contrary to the vision we had originally, so I told the team we had to focus on making the game a power fantasy!

In order to achieve this I changed a few mechanics. I made the player not collide with the foxes anymore, because being pushed around by them felt really bad to our playtesters.
I also gave the player contact damage, representing them just stomping over the smaller foxes.

 

Gamefeel and Healthbars (Week 3)

JUNE 30 – JULY 07

Design

Design was still lagging behind, I didn’t feel like the game was particularly fun to play other than the fact that stuff exploded, it was still not much of a game. I spent this week mostly trying out some things to see if they could work.

Programming

Game Feel

Rick linked me a very good talk about Game Feel by Jan Willem Nijman from Vlambeer. I was very impressed by how much difference the accumulation of these little details did to improve the game, even if the core game mechanics did not change. So I started implementing a bunch of these things. I added screenshake, camera lerp, damage flashes, bullet inaccuracy, and plan to add more as I go along.

AI

I also implemented a new enemy. A ranged fox who will try to keep his distance from the player, instead of running at them like the melee enemies I made before.

foxRanged
Ranged enemy. #programmerArt
rangedFoxAI
Ranged Fox Behaviour is split into three priorities.

Initially I was kind of afraid of writing “AI” because I thought it would be this super high-level thing, but as it turned out, you can do a lot with very simple behaviour, so I’m now pretty excited about adding different enemies with different behaviours!

Healthbars

Even before watching the video by Jan I knew I had to give the player feedback for when he deals damage to an enemy. We discussed in the team without *really* finding a solution we agreed on, but in the end I went with healthbars, because they gave the player all the information they needed. But even the healthbars were not that simple, There were a bunch of ways to implement them, and I asked the others for feedback.

healthbar styles
Different styles of Healthbars. We went with the center-aligned + background.

Initial Game Design (Week 2)

JUNE 22 – JUNE 29

Game Jam

We wanted to make a Game Jam early on in order to set a few things in place like the main gameplay mechanics, and the feel we wanted to achieve as well as the art style. We set the date for it to the 22nd and 23rd of June, we planned to meet at 10am and finish around 6pm each day.

Because of several complications delaying some of us, the last person arrived at around 4pm, and we couldn’t really start without them, so we ended up discussing for three hours instead of eight, which meant our results were much fewer than I hoped. At we decided not to meet on the second day, because our Game Designer had to work, and I wanted the artists to get their style down.

Switch from 3D to 2D

We realised that making a full 3D game wasn’t really feasible, since our artists were both 2D focussed, with no or barely any 3D experience. So we switched, which sadly meant that I had to scrap my earlier prototype.

After some discussion we decided on an orthographic style, similar to Pokemon or the old Zelda games.

ortographic camera
Pokemon Ruby left and Link to the Past on the Right. This is the kind of camera angle we’re going for.
Art Style

For the artstyle we will go with a Vaporwave/Cyberpunk kind of look.

vaporwave_moodboard1
Vaporwave Moodboard

I’m still not convinced whether this look will work for our game, but our artist are excited to do it, so that’s what we’re going with.

Game Mechanics

For our core gameplay we decided on a sort of Beat ’em up / SHMUP sort of design. The player will be presented with an objective for each level, most of them will involving destroying buildings and killing enemies. Other objectives may be freeing or protecting little chicks.

Production

Like last semester, I want to be somewhat organised this semester, so I have started a few production documents on our Google Drive. One important document is the Asset Conventions doc. Since we weren’t clear on the specifics of our art style I wanted to help avoid confusion with this document.

Art Assets Conventions
Art Assets Conventions Document

Another Document is the Bugtracker. Since my intention is to prototype early, I need a document to keep track of all bugs. I used the same system as last semester. I quickly explained the system to my team members, and they were already using it for the two builds I had sent them.

Bug Tracker
Bug Tracker with color coding and explanations (click to enlarge)

I also made a TODO list for everyone to use, and compare progress, and Rick made a document for needed art assets.

Programming

As we switched from 3D to 2D, I had to rebuild the prototype from scratch. I got some Pokemon backgrounds and buildings and a large Link sprite sheet and started putting them together.

Animation

I built a simple state machine for the animation, which I had to redo, when I realized that connecting all states from the “Any” state, would mean you cannot really have a proper “attack” state. Since we have a top-down 2D game, the characters need animations for all four directions, so I needed to put that into the state machine. The way I finally implemented is that each substate (idle, walk, attack) begins with a “start” state, and then the direction is taken into account from there.

statemachine
Statemachine for player character

And this is what it looks like with the temporary art assets: (the video is quite choppy, not the game though)

Pathfinding

Unfortunately Unity’s built-in Pathfinding system, the NavMesh, is not compatible with Unity’s built-in 2D physics and graphics system. The 2D physics system works on the XY-Plane, while unity’s NavMesh only works on the XZ-Plane. Unity doesn’t seem to b able to fix this issue.
I decided that pathfinding is quite important, so I flipped the project on its side to the XZ-Plane, and it is now using Unity’s 3D physics system. This brings some issues with it, I have to rotate all sprite renderers, which means I cannot see them in the prefab folder.

prefabfolder
Prefab folder, blank images for most prefabs.

I can now use the NavMesh though, which means I don’t have to write my own pathfinding code, or buy some from the asset store.

Code

Most code I wrote so far is pretty standard. I have an InputManager, a GameController, Health Scripts for enemies and the player, EnemySpawner and Mover, the Scripts doing the explosions and some helper scripts like Lifetime (destroy after time) and Deactivator (disable after time). I don’t really have any interesting code but I quite like the design for the melee attack  came up with.

MeleeAttack()
MeleeAttack Method

All it does is check the direction the player is facing and activate the collider for that direction. The collider deactivates itself after about half a second, and the damage is handled by the EnemyHealth Script.

PlayerMelee
Part of the OnCollide Method of the EnemyHealth Script.

 

Personal Goals and Group Formation (Week 1)

June 14 – June 21

Expectations and plans

For this semester project I had one clear goal in mind. I wanted to make a game that was easy to pick up and play, at least for people who are somewhat used to playing games.
I also didn’t want to be a “creative director” this time, I would prefer to be able to take a backseat in the game design process, in order to work more on actually programming the game.
I wanted to make a prototype as soon as possible, unlike last semester, and I wanted to use it to give the entire team a clear vision of what state the game is at.
Unfortunately, this semester’s theme of Experimental Games didn’t really seem to favor my goal.

Team Building

During the Kickoff-Day brainstorm period I tried to find the group with the most game-like idea. Most of the ideas seemed to be experiences rather than games, Rick and Caterina’s concept was the one I could most imagine to be actually playful. I didn’t fully commit to their group yet, because I wanted to listen to all of the pitches first, but after the first pitches, their idea still seemed the one closest to my goal. I then found out that Rick had a similar goal to mine, to make a game that can simply be played and enjoyed, without need of specific hardware.
I ‘officially’ joined their group at the end of the day, and met with Rick two days later to do some initial brainstorming.

Omar joined after the initial presentation on June 20, because he also wanted to make a proper game and – like me – felt that Trash Chicken was the project most suitable for it.

Initial Prototype

Rick and I initially thought about making the game in the Unreal Engine, because it can look a lot better, and because I wanted to learn it anyways. However due to the short amount of time we had for this project, we decided that I would try it out on the weekend, and decide whether I think I can do it or not afterwards.
I decided I couldn’t do it. The Unreal Engine is surprisingly much different from Unity, and since our game wouldn’t be the most simple, and since the game design would need a lot of work still, I decided that I had too little time to learn the engine AND make the game work in time.

So on Monday I started work on the prototype – it would be cool if we could have something to show for the first pitch.
I started off with a Toy approach. I made a simple chicken from unity primitives, a cylinder and some spheres, and built a physics based character controller for it.

derpy the derp
Angry Chicken, ready to destroy the city!

I also started implementing the destructible buildings. I used unity primitives again, this time cubes. When the player came in contact with the buildings, they would be destroy()’ed and fragments would fly around. The fragments (same cube, but an eighth of the size) would fly in all directions, but funnily, one of the 8 fragments would launch straight up almost like a rocket.

Building fragments raining from the sky

After the initial presentation on the 20th I asked Rick to play the prototype, and one thing we found out, was that the blocks feel too heavy and big, it wasn’t that much fun to play around with them. That day and the day after I spent more time on the prototype. I improved the look of the explosion, and I modified the explosion fragments. Instead of solid blocks, they were now more like boards, which actually made more sense, since real buildings have walls, and are not solid blocks either. That meant the fragment count had gone up from eight to seventeen. I also changed it so that the fragments wouldn’t explode away on collision with the player, instead they could stand in place if the collision wasn’t very strong. This looked very cool, because there would be buildings that were still half standing, after pushing through the city with the giant chicken.

half standing buildings
Some ruined but not completely flat buildings.

This did however removed the fun of the super-chain-destruction that was in before, where the fragments of just one destroyed building exploding out were enough to chain-react destroy the entire city.

chain destruction
Looks awesome, great fun but cannot work in a goal-oriented game.

In the end I was quite satisfied with what I had, The explosions looked decent considering the particle asset was a simple white circle, and it was satisfying to see the trail of destruction behind you.

trail of destruction
Trail of destruction. Still explosions going off.

And that was pretty much the end of the prototype. The day after we met for our ‘Game Jam‘ in which we decided to switch to 2D, so this prototype would go into the bin.