Bean Boy Postmortem

As Interactive Gaming students in our third semester I think it is fair to say we were all very eager to dive into making a video game this semester. The process has ended up being quite the learning experience; making games isn’t all fun and games. However, through many sleepless nights and mind boggling bugs, we emerge with a finished video game. 

A lesson we all share taking away from this project is definitely having a manageable scope. When we were initially planning out our game we all took turns throwing ideas into the mix until we concluded on a masterpiece collage of our collective personalities and gaming preferences. In the end many of these ideas were far too complex to implement in the time we had as well as not working well with the other main ideas. In the end the ideas that playtested the best and were the easiest to implement were the ones that remained but in fact quite a few aspects of the final game were designed mid project lifecycle.

To give you a quick summary of our final game: It is a sidescroller platformer meets space shooter. You play as bean boy, a lone astronaut, who can pilot a spaceship and explore space and five nearby planets. There are puzzles on each planet and enemies to encounter in space. The spaceship runs on fuel and must be refueled by exiting the ship and floating into space to retrieve the fuel. There are also collectables scattered across the whole map.

Here are some thoughts from each developer on what went right, what went wrong and what we would have changed about our development process.

James Li - Game Designer

With the project coming to a close, it is safe to say that it was a great experience creating a game of this caliber and the hard work that the team put together came out greater that we visioned. A lot of creative ideas came to mind as we shared our input towards the design of the game, many ideas were implemented, and others put aside for future add-ons. There were many positives and negatives throughout the project, and I would like to share my thoughts as the game designer.

One of the ideas that we focused on was the concept of designing a 2D side scroller, but also including a free roam aspect. These two main mechanics integrated very well, as the game reflects exploration in space. It also created diversity to the game, as the player needed to travel to different planets while avoiding enemies and obstacles, and creating mechanics for other planets. These two mechanics alone sparked a lot of creative ideas not just from me, but with the rest of the members too. Without this, the game would not be where it is today.

Other interesting mechanics added to the game was the gravitational pull on the planets, and the player movement, mainly focusing on space exploration. The player has a harder time flying off the planet, but also an easier time landing on the planet. The gravitational pull, although very minor, completes the aspects of the planet and makes the game more enjoyable. Player movement within space was a ‘must’ mechanic, but experimenting with the gravity and giving the player a “boost”, brought another aspect to the game.

A mechanic that we tried to implement, but ended up removing, was to give the player a gun during their exploration. The mechanic to give a player to shoot enemies was an idea that was meant to be included, but because of our checkpoint mechanic, implementing the gun was a lot tougher than expected. Because of the complexity added to the engineers, and also the small pool of enemies on the planets, we decided to take out the gun, and instead, create platform challenges and small puzzles to compensate.

In the end, everything came together and the end result was a positive one. We had a very broad idea of what we wanted to create and added new ideas along the way. Something I would of changed during the development process is to have a clearer and detailed scope of what we wanted our game to become. There were many additions to the game that were removed, resulting in wasted time, and also creating unnecessary stress for the team.

Scott Welsh - Project Manager

As the Producer/ Project Manager my roles are to overall manage the project, scheduling and tracking of tasks and group deadlines responsible for all documentation including the game design document, presentation files and other. The things that went right were the scheduling, making sure we hit the deadlines, and the discussing of ideas and having meetings early on in development. Early in development we were all very excited about the game come having meetings, coming up with ideas/ concepts was very easy for us. Many of us in the group are very motivated to make something we are proud of because of this making sure we hit deadlines wasn’t very difficult. 

Although we were all motivated to make the game and get things on time, because of other factors like school and personal life, meeting up to talk about the game and overall communication between members became increasingly difficult. Although we managed, it was an obstacle we had to overcome for sure. Something else that went wrong during development was once we realised how difficult it would be to implement something we really wanted, we would have to get rid of the idea. Scrapping ideas we originally came up with later on in development happened quite frequently, this could cause a domino effect and we would have to get rid of other aspects of the game and would have to backtrack. When ideas were scrapped, and communication was difficult at the time, people in the group would be misinformed or confused because of the changes. For me, I found that because of this I would have to constantly get rid of things on the Game Design Doc, or completely get rid of something. Although everyone did their parts for the deadlines, I made a pretty drastic error I feel bad for. There was some miscommunication, juggling work from after the strike, I was so used to the deadlines being more equally spaced out I missed one of the versions for the game design document. 

For the development process, I would change the way I schedule things. I often write things down. But I find that it doesn’t work very well for me. What I recently started doing as a result of me missing a deadline for the game doc, is that I write notes on my phone and type in reminders, so I get notifications and won’t forget things. I Definitely wish I used this method early on in the development, because after the strike trying to get everything done on time and remembering dates/assignments became very difficult. I would have liked for us to have more meetings that involved all the group members throughout the development. It would be useful for throwing out more ideas and keeping each other more up to date with changes.

Brandon Koo - Play Tester

In the development of the game there were couple of things that went right and things that went wrong. While I was testing the game the things that went right was the visuals, the mechanics, and the level designs. 

The visuals has a cartoonish feel to it when playing the game and there were no other sprites or background in the game that feels out of place. The mechanics in the game that I enjoyed using.

The mechanics that enjoyed were the ship, the jetpack, and the map. In the ship you can fly around and shoot the enemies in space. Even the enemy’s lasers that can be shot down when you are engaging them. While you fly out there exploring you have the fuel bar to worry about. If you find yourself out of fuel there are gascan flowing out there. You can leave out the ship let beanboy fly around by using the jetpack to grab the gascan and then bring it back to fuel up your ship. Player can use the map function to show where player is current at and the planets there are. So using the map to plan your flight to planet to planet making it feel rewarding if you make it. When you reach a planet I like that you can’t land anywhere except the landing pads and landing on the landing pads is forgiven that you don’t have to exactly touching.

After you land on the planets I like how each planet is different from each other. There were no same puzzle to them and they have their own uniqueness to them. Although some of the level can be improved upon but they are interesting to complete the puzzles. 

However, there were some things that went wrong while developing the game. I believe that went wrong were the planning, time management, and a bug that was found. For the planning of the development of the game is that it was when doing mechanic in the game. It was too time consuming or complicated to complete it that it ended up not being used most of the time. The time management of the development was a little discorded. The timing of completing parts of the game got delayed thus disrupt the flow of the development. Lastly, do to the disruption of the time management there were some bugs that were found in the end. There was one type of enemy that doesn’t seem to move when I flew next to it. 

However, the enemy will work after it respawn when you kill it. 

Overall, working together to develop this game with the team was an interesting experience. Due to the rights and wrongs that happen in the development of the game it came out alright in the end.

Eskender Memetov - Software Engineer

This year we took a different approach in developing the game, by the requirement we all had to choose our roles and dedicate ourselves into this project, even though we all tried to contribute as much as we could by only doing what we are supposed to, we often took each others back and helped one another. Definitely there were thing that went just great yet sometimes we had our struggles. 

Developing such a game and be a part of this group was a great honor, I felt very satisfied when i was able to help my teammates to accomplish a specific task and was thankful when they could solve my problems. A great aspect of developing this game was that we all faced challenges that we never experienced before, we found a great solution to them and always kept in touch. Sometimes we would break our heads over just one bug for days and than felt such a relief when we finally solved it. Sometimes building process was just very smooth and easy. And when u experience such thing you start appreciating your work, people you work with and the overall goal that you put in front of you. Definitely the greatest thing about this game is what we have learned, writing code, creating media for the game, working in a team, managing GitHub, meeting our deadlines. Maybe it does not really makes us some great developers, yet I brings us one step closer to become them one day. I love the game we created out or just word that have been loudly screamed during our first meeting. I said “Bean Boy!” and Scott Welsh said “No, Bean Me Up!” and this is what gave a great start to it. Than we started planning how we want to see the game, what it would be, and how we will implement it. However, here comes the downfall, the ideas that we had were just way to complicated and there was just to many of them, during the development process we often faced that some of the mechanics are just too hard for us to implement or we do not have enough time. That is why some of the ideas were cut the others were added, game slowly started changing and even though we did not make exactly what we wanted, I feel that we have created a great title that we definitely not ashamed to show others.    

It is definitely a thing to say that we did not have enough time, and I would say that there is much more to do in this game, since there is never a perfection, I hope that my teammates and me will move on and start working on new projects, so they can prove themselves in game development, i hope we all be able to have a huge portfolio of games before we graduate from Centennial College. But for now I just wish that we all keep in touch, and continue working on this project to bring it an ich closer to perfection and maybe then we can publish it, so everyone gets to see our work.         

Daniel Stokes - Software Engineer

Now that this project is nearly over I feel so much relief. This game truly feels like a labour of love emphasis on the labour. I have learned a lot from this experience and can’t wait to start my next project.

There are quite a few things that I am very pleased about with this project. 

Our implementation of the openworld concept in my opinion is a success. The player can explore the game openly in any order and pace that they choose. They can revisit planets and have the freedom to leave their ship any time they wish. The openworld mechanic of our game is supported by our implementation of the map and respawn system that prevents the player from ever getting stuck/lost as well as the spacewalking mechanic which gives the player the feeling that they can venture into uncharted areas. This system was not initially implemented in this fashion; at first you could only choose a planet to land on and the ship auto piloted to the surface and the player would be exited from the ship. Upon play testing I discovered it was more fun to manually land the ship on the planet and have the ability to exit the ship at anytime.

I am really proud of the space enemies that I coded for the game. They are fun to encounter and fight for the player but they were also a fun challenge for me to program. I enjoyed experimenting with different movement and behaviours. The movement of the enemies was achieved without complex pathfinding algorithms yet still feels dynamic and fun to encounter. 

Due to a member of our group leaving mid semester I tried my hand at making some art for some of our characters. I ended up creating the sprites and animations for bean boy and two of the enemies and really enjoyed that challenge and I feel that the results are pretty good. I developed a good workflow using Blender to create the sprites and using simple rigging tools to make the animations. I look forward to taking on more challenges like this in the future. 

One the subject of workflows I also created some editor tools to aid in the planet level creation. This saved us a lot of time and headaches when creating the levels.

There are also a lot of things that I am not pleased with and wish we could change. To start the platforming movement on the planets doesn't feel very responsive. There are a lot of factors that contribute to this and a solution would require a large rewrite of code that we simply didn't have time for. I also wish we could have added more things to encounter and discover in space. The space portion feels a little empty and spread out.

A more major flaw with our game is motivating and guiding the player. There is is currently no end game or progression for the player. The only motivation for the player to play our game is curiosity and if they get frustrated at anypoint then they will abandon that goal and stop playing. If we could implement some sort of leveling progression system using the ship and bean boosters we could create more of a focus for players. Another solution to the end game problem could be collecting all the bean boosters and returning them to the starting planet.

Another aspect of the game that I am unsatisfied with is the tutorial system. With a better tutorial system the player could become comfortable with the gameplay mechanics and controls and utilize them better and enjoy the game more.

I also learned a lot about the game development process. Some things that I learned and will change for my next project are: Have a smaller, more manageable scope. Our initial idea was far too complex and included too many things that didn't add to the fun of the game. If we could have developed a prototype beforehand we could have then discovered what was fun and what was not worth keeping faster. A prototype would have also helped us create better programmed systems as we didn't know the extent of each system as we were developing them. Finally I think having a singular vision for the game would have greatly sped up and reduced wasted time and we would have been left with a game that is clearly defined rather than a collage of all of our gaming preferences.