REM Phase 1: How it went

With gold completed for REM. And us taking a break from the project for a few week I have decided to go over what went right and wrong with the game.

REM being a game first person endless runner means there is very few games on the market like it. With this we where going into this project almost blind our only thing to look at for reference where Mirrors Edge which we looked upon for the first person park our and Fotonica which was a first person level based runner on mobile with a lack luster endless mode.  With this I had doubt going into this project that it will be something fun to play. On the other hand I was excited by the fact that there was little on the market so we had free reign to do as we wish with the game in an attempt to pull it off.

The prototyping phase was interesting I spent a lot going back and forth with my designers Simon and Julian (Yes Simon is listed as producer however he also jumped in and done a lot of design stuff and has earned my respect with the amount he has put into this) trying to figure out how the game was going to work. After doing this I ended up putting together an initial prototype for the game as seen here. This was used when pitching the idea to the teachers and a few people from the video game industry. It was really well received by both the teachers and the industry which really surprised us.

As alpha approached I finished up the technical documentation and started rebuilding the code base from the prototype to be more suitable to build up. A lot of this was spent getting soft landing and death detection implemented.

When beta came around the core mechanics where in the game and I was assigned to building the generation for the game and managed to build it in a few hours which really surprised me. Even more surprising was it worked the first time. With the generation done in a few hours I managed to single handedly destroy the schedule for the project and put us in a snow ball that caused us to be ahead of schedule. The artists wanted to get chromatic abberation in the game however this was extremely slow in the standard assets and brought a lot of phones to their knees on its own so what I ended up doing was taking the chromatic abberation out of the shader so it was only it then added desaturation to the shader and doing that we where able to get a much better shader and higher frame rates. After a while into the development of the game I discovered a major bug where on rare occasions the walk locking would not engage. I spent several days trying to fix the bug with no success and after a while I remembered that Unity’s rigid bodies freeze constraints are not actually a freeze but a reset so I used fixed rotation for the calculation and viola fixed. After I knew that I put the calculation across several frames and put the calculation back to what it was which caused the awkward slide down walls for a few moments then start wall running but also brought back allowing rotation at any angle.  With this we done a bunch of testing and I had to rewrite the jumping code several times in response from testing. The first time we did it was to hide a bug with slopes so we needed a way to create variation in the jumping height. The second time was when we were receiving feed back from the testing they said the charging for the jump was slow and not very straight forward this caused us to look to the Super Mario games for the jumping for those that don’t know this is when you press the jump button it will give you upward force and as you hold it down it will keep adding upwards force until you let go or reach the peak of your jump. Near the end of beta I had to setup the intro transition in such a way that would hide the track generating I achieved this by having the player spawn in the air and do a flip while falling when the player lands I unlock the controls and let the player run along like normal problem was players would not like falling every time so I had to have the game play like usual when the player restarts a bit disappointing seeing as the whole reason of it was to hide the track generating. Other then that I was tasked with implementing the audio and animation which wasn’t anything significant.

When gold came around it was mostly bug fixes but the majority of the bugs where squashed as we where going so it was pretty chill until the final week then we discovered that the frame rate was horrendous with the latest build at 15 frames a second with this we set out with the optimization hammer taking on everything slow in sight *cough* motion blur *cough* please no *cough* we ended up going through merging a lot of the meshes getting rid of any extra colliders and somehow managed to get it up to 60 fps in less then a stressful week.

Through out the entire project I ended up having a war with source tree which got worse as the time went by to the point of almost losing our work on several occasions. I did not know a application could crash 15 times in a row but apparently it is possible. Unity wasn’t innocent with the crashing either but at least I could hit the ground running again when it did.

In the end the first phase of REM was a big learning experience and for the second phase I will use this knowledge to try and improve the game. I will also be looking for new version control software if I see source tree crash one more time I will have had it.

TLDR Was calm at the start and picked up in panic near the end.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s