Looking back and to the future.

Looking back at this project I have come to the realization that time management and management of the team members is the most important thing. Initially everything was great. We were all so excited to create a game with our own narrative spin. The first thing that went right was the fact that we are agreed on one game and we all allocated ourselves to tasks we felt we would be able to accomplish.

So First good thing was -Diplomacy.

The second great thing to happen was source control. Erin and Noah introduced me to source tree (a program I didn’t know existed), it allows for pushes/pulls of any files. Pushing puts your own files in a repository. While pulling, grabs your teammates “push”. This made getting everything together way easier than I had previously imagined possible.

Second good thing -Source Control.

Here is where things get messy. Management was a serious and critical problem I felt throughout this entire development cycle. That’s all I’m going to say. The amount of resources we had to work with was poor and the team management didn’t help. I have learned from watching that if I eventually want to lead my own studio, task completion must be iron-clad and things need to be addressed from the beginning. If something needs to get done, do not give them a option, get it done. We should not be dancing around features with 3 weeks left.

First bad thing – Poor Resources/Management

Second thing that destroyed many of us was time. I do not feel that with my workload on top of this class that creating a fleshed out game is even possible. We did not have the time or knowledge to get to where we wanted. While I’m very happy with my team and what we have accomplished. This was just too much. Some people working on one day finishing a task only to here that something is missing because someone wasn’t working yet. When you go to test everything breaks and you spend the rest of the waking hours bleeding your eyes out. I personally felt this when I had to recreate our level. I can only imagine what Noah felt like the past 5 weeks. Since, he held to main build for the entire project.

Second bad thing – Time (not enough)

So after that semi-rant, a couple of lessons I have taken from this is one. Rule with an iron fist or your employees may procrastinate/complete tasks leisurely. Leading to a worm hole of problems and sleep deprivation. But more importantly, make sure that if you set a release date for your game that it is actually possibly to attain. Give your team adequate time to make your game/vision possible.

In the end this was our first time creating a game, for some, first time touching unity, first time leading, first time animating, and first time programming for a game.

-John Harvey

15 hours of starvation

John Harvey, Week 11 Journal

Week 11, the final week to get everything together.

This week my team and I needed our game to be somewhat complete. Looking at the level we had and what was supposed to be expected, I realize very quickly it needed heavy reconstruction.

So, this week I became the majestic level designer I’ve always wanted to be. I sat down in my chair at noon on Friday and cranked out a completely overhauled level. I didn’t eat for 15 hours, because food is for chumps (I ate immediately right after). I contacted the art department earlier in the week, got the assets, started importing, and created prefabs. This alone took 5 hours (500+ additional assets). Once the assets were in, I began the level design. I set up to level to allow players to learn a new mechanic than move on, while trying to keep the up-down up-down climatic events my team requested. At 4:33am the level was finished and I gave my team the go ahead to start fixing/polishing anything that needed it.

I’m happy.

Positive: Level is done, it runs around 4 minutes. My team is back on track. We have a working level!!!!!!!!!!!

Negative: It took 15 hours of straight work to get to this point. Assets took way to long to get into the engine. Unity crashes/Pc failures.

Enemies and Secondary Assets, Week 5, Chris

Since the art assets for the brother and sister have been finalized and sent to the animation department, and the first three enemies also have finalized art, it’s time to be working on the art for the other assets in the game. Usually I do foundational sketches and formatting in Photoshop, which then gets sent to Syd to be vectorized. These last couple of weeks though, we’ve realized that the environment is way too short. She’s swamped altering that, and I do have Illustrator, so I’ve also been helping to vectorize now. Basic power-up sprites and projectiles for the enemies and heroes were made this week, and the Clam and Eel enemies were also finalized. Since in these final weeks we don’t need as much concept work as before, I’ve also begun helping in other areas, mainly finding royalty free fonts that match the mood of our game, and also royalty free sound effects.

Positive: We’re definitely moving away from getting concepts into the game and into polishing and perfecting what we have.

Negative: As we move forward, a lot of older things we did need to be updated, and it’s also surprisingly hard to find royalty free sound effects that don’t get irritating after hearing them a couple times.

Menus, Powerups, Updates in General

It’s the end of another week of development. One week until the end of the project.

These past two weeks, we’ve been working towards getting all of our features in.

I added in a main menu and audio options for the player.

The art team made some pretty assets for the main menu.

I also set up the game’s audio system this sprint. I’m using Unity’s AudioMixer to determine the difference between background music and sound effects. Audio sources within the engine are marked to either play using “BGM” or “SFX” settings. This way, the player can reduce BGM to a lower volume, and it’ll affect all sounds marked BGM without having to edit them individually. I want the code base to require as little busy work as possible, because bugs can easily happen when you miss something you forgot to keep track of.

I also worked on power-ups. I made an abstract “Powerup” class, which contains something of a blueprint for specific Powerup classes to fill in the blanks for. For example, the Powerup class has a abstract method ApplyPowerup(). Different powerups will do different things, but all powerups will have some sort of effect. So by marking ApplyPowerup() as an abstract method, I am requiring any inheriting class to have an implementation of ApplyPowerup() to be a valid powerup.

We also got new environment from the art team, so I replaced the old sketches with the new assets.

It’s a beach.

I also helped the other programmers with some code updates. The old bullet shooting code was instantiating way too many bullets at once. There could be twenty bullets taking up the same space. There’s supposed to be a bullet fire delay, but the delay wasn’t having any affect. This is because the delay was being called by the bullets themselves, so there wasn’t anything being delayed. I changed it so that the delay was called by the slingshot instead, so a bullet would not be able to be fire so long as the slingshot was in a “in delay” state.

There were also some problems with the old powerup code. There was too much coupling, which meant that the code was too dependent on other classes to function. Updating powerups would mean you would have to update several methods in several classes that you might not realize are related.

Next week’s when it’s all due! Please look forward to it.

Time your shots

John Harvey, Week 10 Journal

Week 10 the hopeful final stretch for my shield & sling code!!!

This week a very brief reflection notifier on the shield. The shield will flash during the frames it is able to reflect. Frame perfect. Adding the notifier actually enabled me to see a bug in my code that made the shield just continuously switch between states. This was resolved immediately, without stress. The little brother’s sling should now shoot only a set amount of bullets in a set amount of time. ex: 3 bullet per second.

So, I again used a IEnumerator to assign the RapidFire state to a limited time, 2 seconds. It switches a bool statement, stateSwitch, so the Sling script knows when to fire bullets faster.


Positive: Easier to code, since I already had this previous knowledge from last week. I spent about 2 hours fixing this and finding possible solutions to bugs that were found. Code was merged properly and works.

Negative: A few bugs popped up that were resolved except one. This one has to do with that fact that I’m having the sling be thee collider with the power up instead of the character..

I am aware this is a problem.


I hate physics. I hated physics 101. I hated physics 102. I hated physics 201 – BOTH attempts, mind you.

I also can now add “unity physics” to that list.

The past weeks have seen me attempting to get collisions to work between objects. I tried various methods of doing this, from triggers to tag references to layer comparisons. If there was a unity support thread about it, I tried it. Well it turns out, the key to my frustrations was this little drop-down every object has in its 2D collider. Unity has three built-in physics models: Static, Kinematic, and Dynamic. We had been using kinematic for all of our enemies and players. It turns out one of the features of kinematic physics is – drum roll please:

They don’t support collisions.

Switching to the dynamic model meant all the collisions coded in now worked as intended…mostly. A side-effect of the switch is that now EVERYTHING collides with EVERYTHING. Enemies get caught on everything, bullets bounce everywhere. It’s a whole new beast that I kind of worked around for some stuff. The environment is whole other can of eels but I think I can get that knocked out in the next day or three.

Anyways, health basically works. We just need to tweak the numbers to make sure the game is playable. Power-ups are this close, too. Again, it comes down to value tweaks and having the art.

But yeah. Week 10. As the kids say:

It’s lit.


Sydney’s Journal

Chris and I ended up slamming out all the enemy art and finalized the siblings as well. We’ve gotten all the enemies to the animation department and I’ve started on the environment final art. Each environment tile has a middle ground, background, and if time permits a foreground. I got the splash page of the main menu done too!

Chris has also made art for the different kinds of projectiles and we got some music into the game.

Positive: Final art on all characters and enemies are finished. The environment is on its way and the organization of our folders is still strong somehow.

Negative: There’s a lot of environment to get done and I’m not sure I can put as much work into texturing as I want to.

  • Production, Art Assets, Week 9, Sydney Oswald