Embody Game

For my UF course, CAP4053 AI for Computer Games, I was placed in a group and tasked with creating a shippable game as the semester project. At the start of the course, every student submitted a “pitch video” which was a video describing an idea for a game. These pitch videos would then be vetted by the professor, and some would be approved to be created into games.

My Game Pitch

My pitch was for a top down, shooter, roughlike, dungeon explorer, with a quirky mechanic where the player has a sight cone and enemies will only aggro if they detect the player. So enemies around corners or behind you would be invisible. I felt like this would add a spooky or scary element to the game, as well as a stealthy element if the player managed to remain undetected. Of course, for the sake of the pitch and the project this was slightly simplified so that it would be doable by a couple of amateur game devs in a couple of months.

My pitch for Spectral Bullets

Although my pitch was approved, I decided to join a friend’s group and work on his game instead. The other game is Embody, and it’s pitch is very similar to mine, just without the sight mechanic, and with a more Binding of Isaac artistic style. My game idea was never completed as there were more ideas than there were groups.

Embody Game Group

Image result for binding of isaac red room
Reference picture the creative lead wanted for the game

After joining the group, work began immediately on creating a prototype for the game. My group had 4 developers with no artists. Other groups had some artists on their team (Digital arts course was working together with our course), but unfortunately there weren’t enough artists for every group.

I was chosen as the programming lead, to be in charge of the general programming architecture for the classes in our game. As well as in charge of being in charge of the Github development workflow, and most of the code reviews for changes to be merged into appropriate branches. I was the only person in the group who had experience making a Unity game in the past (For my CEN3031 Intro to Software Engineering course I was in a group making a Unity game), as well as the person with the most experience and knowledge using git and Github.

Development Workflow

Git Flow Workflow - Release Branches
Chart from Atlassian’s page showing feature/release branch flows

The workflow we used was based on Atlassian’s Gitflow Workflow. To me, this workflow makes sense and I find it easy to implement and follow. Since I was in charge of the Github repo, I secured the develop and master branches so that only pull requests could be made them, and the requests required 1-2 reviewers to ok it before being allowed to merge. Although this may have seemed to slow down development for some of the team members at first. The workflow definitely allowed us to catch each other’s errors, and ensure that coding standards and syntax was consistent across the code base.

On Github, I used their Projects feature to create a mix of Kanban boards with the project themselves being a Scrum sprint. Github issues were used as tasks within the board, and assigned to team members to complete and follow through. This allowed our team to remain organized and prioritize specific features or bugs. The boards also showed us how much work we had left to do along with the due date, so that we could reassess our progress and possibly cut or add features.

Every weekend I would arrange a group meeting in a sort of agile stand-up sort of way. I would lead the meeting, with every group member recounting their progress that week and any tasks they are currently working on going into the following week. This was the moment where I would update the Github project board. After the meeting, if it seemed like we were not going to meet the deadline with some tasks, I would discuss how we wanted to address and prioritize the tasks we had in order to ensure important items were complete for the deadline. This allowed our team to remain efficient and deliver a complete and bug free game at the end of the semester.

Embody Prototype

Picture of prototype for the Embody game

Immediately after groups were formed, we were tasked with creating a prototype for our game pitch. The prototype was created in the span of 1 or 2 weeks. Due to the nature of the prototype, it was created in it’s own “throw away” Github repository.

The actual game was created in a different repository. The professor intended for the prototype code to be thrown away, and new code be created for the actual game. I thought it was a great idea, since good deal of the prototype code is kinda hardcoded and unextendable. Though, some of my teammates disagreed, and thought it was just a waste of time to recreate the code for the full game.

Embody Game Presentations

For the most part of the semester, our task was to work on and complete the full game. Most of my work was focused on the enemies and weapons. I architectured them in such a way that it was relatively simple to extend or create new enemies/weapons. You can view the source code for the completed game at it’s Github repository (EmbodyGame). You can also just download the final release of the game (Only for windows).

Vertical Slice video

Half-way through the semester we gave a vertical slice presentation. The purpose of this presentation was to demonstrate the progress of our game.

Final Presentation

At the end of the semester we had to give another, final presentation of the game. This presentation was slightly more comprehensive, though we still felt that the time limitation for the video forced us to rush through a lot of the game’s details.

Final Presentation video for Embody

Game Art

Due to the fact that our team had no artists, we were forced to create (or find) the art for our game ourselves. I decided to try my hand at modeling and sound design. A good bit of the in house art in the game was made by me.

Enemy Models

Image result for blender logo

I created 3 of the enemy models, along with their textures and animations. The models, textures, and animations were all created in Blender. Took me quite a while to learn blender, but I got to a point where I felt comfortable making meshes, rigging them, and animating them. It’s actually really satisfying to create a mesh, and animate it so that it looks like it has been given live.

This enemy is called Kat. The model doesn’t really have any textures apart from the gray color. This was the first model and animation I made with blender.

This enemy is called Tenti. The enemy is a stationary turret enemy, so I didn’t have to make a walking animation. Instead it just has a breathing animation.

This enemy is called Cruz. This was the most ambitious model due to it’s walking/hopping animation.

Game Sounds & Music

The game as a couple sound effects, as well as a menu and main game background music. The music used during gameplay was created by me. To create the music I used the Open Source DAW LMMS. It was really fun learning and playing around with different sounds and beats. You can listen to it below.

Final Thoughts

Overall, I loved the experience of creating a game with a group. I enjoyed both creating code and the art. Most importantly I enjoyed learning to create different aspects of the game. During the project I learned and used Unity, Gimp, Blender, and LMMS. As well as my new favorite editor Visual Studio Code, with VIM keybindings of course 🙂 . All of my team members were excellent and I feel like we were all able to learn and help each other out during the project.

Leave a Reply