Walter’s Wizzard Wearhouse Post Mortem (ish) Report

This game was crated as a prototype over the week to answer the question of weather this game would be fun to play or not. The answer we found was yes, but only when things are changed to be more user friendly and when the puzzles are designed in a way that the user can work out the steps clearly.

As I am a programmer, I did the majority of the work with Richard towards the creation of all the mechanics within the game. Chris and Savik were the designers of the game and spent the week making some representational textures and models as well as working out what the puzzles would look like and how the will function. After their working of this, Rich and I outlined what items would be needed in the game (such as heavy crates, pressure plates, buttons etc.) and how they would work and be implemented.

Our goal was to make it so that the designers would be able to make the levels as easily as possible. To us, that meant they should be able to drop objects into the scene and they should be ready to use or mostly be ready. We were mostly successful with this, however, we had a game director that was needed for each level and the way it was designed, someone needed to drag in the camera and the transform component from all the minions in the scene and the main character. This was clunky and will need to be revised while polishing the game.

The project went smoothly between myself and Rich. We had good communication and were in contact everyday. This was crucial to getting the project done as we were working parallel on the project so to make sure we didn’t override stuff, we had to talk about what we were doing. This was also beneficial as it allowed up to discuss ways to implement stuff into the game. Asking his opinion on a way to implement something was insightful to me as we helped each other find easier ways then how we were going to go about our stuff.

Even though there wasn’t communication everyday with the designers, we were able to contact them anytime we needed. We have a group where we post work we have completed for everyone on the team and each team member had access to a shared folder on Google drive where all the documentation was stored. This was a good way of going about it as anyone can access the documentation anytime and get the information they need without having to rely on others.

Communication with the animators was a little bit harder. They took on two jobs each – one would model and the other would unwrap and texture them. The problem being that one of the team members didn’t have Facebook (which was our major was of communicating), so communication was difficult. We had to call a few times to get updates and even then, not constantly being able to ask when they are doing was difficult. In the future, if I have this problem again, I will have to plan beforehand a good time to call everyday and get an update on the work completed.

The work that was completed during this project really didn’t help my outcome of getting to learn AI better. There was none in this project, which meant I didn’t have a chance to work on it. I felt that adding it for the sake of me practicing wouldn’t be beneficial to the game so I decided to leave it alone this time. In future projects, I will be looking for more ways to add AI to the game without it feeling out of place or unnecessary.

We chose to use a repo to keep our projects in sync easily, however we ran into a few issues with it. It seemed out .gitignore files wasn’t working completely and was syncing a lot of unnecessary files which caused errors most times we would commit some work. This is because the files were trying to override and it didn’t like that. So we would continuously have to discard those files. Eventually we found a .gitignore files that worked a lot better and ignored majority of the unnecessary files, but still not all.

Using Unity to create the projected benefited up greatly as it saved us a lot of time when prototyping. We managed to get everything we scoped for done and then even a few extras such as making vents in the roof that once activated will drop boxes. With the ability for everyone to work at once, progress went fast to begin with as the levels were being grey boxed and the code was getting done. As we were all working in different scenes, we only ever experienced once where we had to manually merge work because it couldn’t do it properly. Overall, the use of unity allowed us to create the prototype rapidly and effectively.

During the playtesting, we learnt many things about our game with the major one being that we need to make things more clear with user feedback and design. We didn’t have very much user feedback during the testing, so we found that when people are pressing buttons, they didn’t know if they would be working or not. This caused them to press the button multiple times which would in result be opening and closing a door, which they had no knowledge of. This was a major flaw as many people didn’t make it out of the first level.

 

 

Build: https://drive.google.com/file/d/0B3jSePrZ157XSjVrNFBPbWFodU0/view?usp=sharing

Brisbane 48 Hour Game Comp

Over the weekend (October 3rd – October 5th, 2014) was the 8th annual Brisbane 48 hour game competition and it was amazing. This is one of my highlights with games during all the years I have been making them. It was truly an experience that should not be missed by anyone who is serious about making games. Apart from the immense amount of stuff you will learn, you have the chance to talk to other passionate people and even industry experts.

Our team originally consisted of three programmers, one designer and two animators, but unfortunately on the day one of our programmers were ill and wasn’t able to go. This was extremely unfortunate because he was looking forward to it and did most of the planning. However, even though it was last minute, we found someone who was able to stand in for him.

We got there, set up and it was a mess! There were cords everywhere: tangled and messy. Once that was done, all we could do is wait for the three words which were Sacrifice, Wave and Defend. These were the three words that we would talk about for the next 3-4 hours while planning. We went outside with out notebooks and began planning.

We planned for many hours, went shopping for some food, came back, planned more and finally finalised an idea. The game would be two-player with one player trying to find their way through a maze like place trying to get to the end to kill the boss. The other player would try to delay the player and the longer they successfully do that, the strong the boss got. The twist was, once the player got to the boss, the second player would take control and try to defeat the player. It seemed like a good idea at the time and we were all happy with it.

The one thing that I would change next time (I say this now, but I probably won’t act upon my own advice) is sleep more. We worked on 4 hours sleep every night, however when we got up, we spent two hours just staring at the screen tying not to fall asleep. Really, we should have just slept for the extra 2hours and we all would have been more productive. However, with the amount of sleep we did have, it was surprising that we were actually getting work done.

My main roles for the game were to work on a few of the enemies, the player character and the level generation. The other programmer worked on the second player, the other enemies and the systems within the game such as the way the boss scaled. We finished the characters within a few hours of starting, the we decided to utilise the controllers that we had. This was our first major time waster. We were setting up input in unity for them, then after testing the game on another computer, we realised they were not working. After a few hours of trying to get them working, we realised that the controllers were in different slots everytime they were inserted into the computer. Sometimes unity would think they were in slot 1, other times slot 12. It wasn’t until the second day we found out about xinput which was amazingly useful. After spending so long trying to get the controllers to be consistent, finding such an easy way to use them was a relief.

The next major time waster was the level generation system. The idea was that there will be rooms with different amount of doors to fit all situations. Here is a mock-up I did that represents all the rooms that would be required:

With that in mind, I began the code. After spending upwards of 10hours on the code, writing it 3 times and fixing it over and over, it was almost done. It seemed to be working most of the time, however, every now and then, there were hiccups in it and doors wouldn’t spawn next to each other. We had a guy from halfbrick come over and have to a look and another one of the pros, but there was no obvious answer and I didn’t want to waste their precious 48hours. So in the end, we decided to scratch the idea all together and create preset levels. Overall, I am actually not disappointing with the wasted time as I feel like I learnt a lot form that. At the beginning of the day, I had no idea how to tackle the problem. With help form the team, we worked towards solving it and I almost fully implemented it. In the future, I actually want to go back to the code and see if I can get it working properly. That would be nice. This is how it was supposed to look:

There was one more problem we ran into, and it was a major problem. On the last day, we decided it would be easier to integrate everything on one computer. After that, we just continued working together at that computer, which was a terrible idea. We imported a package, which somehow over-wrote a load of files that had completely different names to those in the package. I am still not sure how it happened, but it did. Thus, we lost a few hours of work in the last 5 hours of the competition. We were pretty much done and ready for balancing, but that was never done due to having to make those lost items again. This has taught me a valuable lesson about backing stuff up. Since returning from the comp, I have backed up all my projects that I would have to lose to another hard drive and then uploaded them all to bitbucket. That way, I have version control if I want to keep working on them to prevent large amounts of data being lost.

At the end of the comp, we all felt relieved that it was over and that we actually somewhat fixed our game. It was in a playable state. However, it was not at all what we wanted it to be. Looking at all the other games people made was great. There were some really excellent games made in such a short amount of time. We didn’t win anything during the comp, but I have come back with more skills then I left with, made some new friends and got a chance to talk to many people who actually work in the industry. Overall, it was time well spent and I really look forward to doing it all over again next year…but with more success 😀

Now for some pics of the game:

 

 

Loot-To-Boot Prototype

Loot-To-Boot is a loot collector game which set out to answer the question of Will this gameplay of collecting loot be addictive? The process of developing this started with us discussing what our strengths were, what roles we wanted and which work we should all complete. I learnt that this is a valuable step at the beginning of the process from previous projects which I deemed successes. Before we began making the game at all, we made sure we all knew exactly what the game was going to be by working on a Game Design Doc together. Once we knew what work was getting done and who was doing it, development began.

Due to this projected being a prototype being made over a week, some of the code became sloppy. I found that we neglected commenting mostly which even for a prototype I think is bad. We wasted time by looking over the code and wondering what it even does and why it exists. This could have been prevented with just 1 line comments for functions that need some sort of explanation.

Communication was pretty good between two members in the team, but there was very little communication from the third. After not hearing from the person for a couple of days, I had to call them and find out what was wrong and where the work was up to. Thankfully, after that communication became a lot better and work was completed in time.

During the final night when trying to add new features, something happened to the project between the two programmers which caused many problems. Unity decided that it needed to re-build the library but it couldn’t do it properly. It would only add a few of the assets into the library meaning that work on the project wasn’t possible. I believe the problem was with the repository that we were not transferring a critical file, but the source of the error could not be determined which is unfortunate as it means that walls cannot be put in place to prevent this problem from occuring in the future. I plan on continuing to find an answer to the problem so it can be prevented in future projects.

Not everything during the process of the project was negative. I used this opportunity to learn about repositories and how to use them. Prior to this project, when working in a group, we used dropbox to keep the project safe. However, this caused a lot of problems by only allowing one person in the project at the time or things are getting overwritten everywhere and that merging work was a lot of trouble. The repository was extremely helpful for majority of the projected, until we ran into that error, which may not have been caused by it. Being able to see what was added in each update with the comments from the person who committed the work was extremely helpful in keeping track of features implemented. Overall, it was an extremely positive experience and I will continue to use repositories for future projects.

I found an opportunity to work on very basic AI during this project. The team agreed that we could add in some sort of very basic AI so I could work on it. The goblins in the game were all made by me and there are three different forms. Once travels across the screen towards the closes loot and picks it up, the second swings a sword to hit the chest and throws loot everywhere and finally the third one aims at the chest with it’s bow and shoots in every now and then. These were very simple to make and didn’t even require a state-based system. However, I did learn how to get things to rotate and look at other objects in a 2D environment.

Overall, I would deem the project a success. I have learnt from previous errors and managed to prevent lots of problems with this one. The feedback from everyone was mostly positive with one piece of criticism sticking with me: The game feels fast paced but the shop seems out of place as it takes you out of that experience. I really like the warm-cool feedback system and you get everyone else’s opinion of the game in an open environment where you don’t feel like you should say nothing.

Title screen – loot everywhere

Loot all over the ground in-game

Particles when hitting the chest!

 

Build: https://drive.google.com/folderview?id=0B3jSePrZ157XeXVyYllUY25LU3c&usp=sharing