‘The Tree and the Bashful City’

A reflection on the development and presentation of the game

Starting from scratch

When we were handed the details for this assignment, I quickly realised it was likely to be the most challenging module in the whole of our foundation year.  We were tasked with developing a game between the whole group (around 9 students at the start of the project) and ultimately to present and demonstrate the game in front of lecturers and masters level students, who would provide critical feedback on our efforts.

I think like everybody in the group I was both nervous and excited at the prospect of facing a new challenge.  This was the first time any of us had teamed up to make a game and unlike a solo project there was also the added fear of letting down your peers and not being able to make a valuable contribution to the game.

We started with a randomly generated title for the game ‘A Tree and the Bashful City’.  My initial reaction was that it was going to be a really tricky title to work with and had no instant thoughts as to the type of game we could make to fit the name.

Luckily everyone in the group was instantly enthusiastic and imaginative, with a group padlet used to express initial ideas for themes and gameplay.  Slowly we narrowed down something that might work as a playable game and fit the title.

Between us we quickly decided that a nature vs industrialisation theme would be both appropriate and unusual.  We wanted to do something more interesting than just a basic platformer and considered various types of game.  Considerations were given to genres including a ‘horde’ type game (similar to ‘We are billions’) and purer real time strategies like ‘Age of Empires’.

I was really impressed how quickly we were able to communicate well as a team.  There was to be nobody appointed as a project manager and I am glad this was the case as it meant that all ideas were given consideration and nothing outrightly dismissed unless the entire group agreed.

So, the initial plan was to create a RTS style game with a nature vs industrial pollution theme.  We were to use a basic game engine (Multimedia Fusion) to develop the game.  The game would be 2D, possibly with an isometric viewpoint and the art style would be pixel-art with brighter colours for the nature side, and drabber colours for the city.

Once we had a basic foundation in place, I felt encouraged that we could work well as a team and actually end up with a playable game.  Exciting times!

After a couple of team members drop out of the project, we were down to a hard-core of 7 people.  Fortunately, we had a fairly even split as to who would like to work on which area of the game with one member enthusiastic about providing a background story, three talented artists, and three (myself included) who would prefer to work on the development side (coding and mechanics etc).  This balance ultimately helped tremendously with the smooth creation of the game.

Initial feelings of trepidation when presented with nothing but a title to work with quickly disappeared as the mists cleared and a workable idea emerged.  I feel like I learnt a lot from this process, and the brainstorming padlet sessions and discussions were a valuable experience to carry forward to future team-based projects.

Multimedia Fusion development

Learning to work with a new game engine is a challenge in itself.  Multimedia Fusion, despite its relative simplicity is no different.  It does not involve coding in its purest sense, but a tick-box system to generate game objects and attach condition checks and events to them.

My only experience with game making had been a brief project making a simple platformer level with a very different engine (Gamemaker Studio).  The only similarity being that you are working with 2D sprites.

On first glance, I expected Fusion to be relatively easy to learn how to use but it is surprisingly versatile and complex on closer inspection.  Jack provided some excellent tutorials on the software and coupled with youtube videos and dedicated forums we were able to glean enough knowledge to make a start on gameplay.

As the development side of the team, one challenge which we anticipated and had to deal with was working separately on various areas and amalgamate our work into one final master copy.  Github was not an option, and I was worried this process would not go smoothly.  Close communication was key, and I think clearly defining our tasks on each sprint in Jira was essential to prevent us overlapping on certain areas of development.  Between us we managed to iron out any problems as we bound our tasks together.

Each week we improved on the version of the game, after initially using placeholder objects we were able to gradually implement the work of the art team and our efforts started to look and feel like a playable game.

I was impressed how quickly we made progress and I feel that our weekly meetings and use of SCRUM methodology was vitally important in this regard.  Tasks were clearly defined each week and meetings ensured we were all happy with the direction the game was going in. 

Ultimately Multimedia Fusion proved to be occasionally difficult to develop a game with.  It can be temperamental and leave you with the confusion of why something works one minute and then seems not to despite not having made any changes!  I think the three of us who were heavily involved in using the software all went through these moments of sheer frustration.

Another issue we encountered in using Fusion was optimisation issues.  For example, when too many enemy units were active on screen, the game would slow to a crawl and become unplayable.  This was due to the engine struggling with so many loops and events taking place every tick of the game.  This curbed our plan to make the game similar to ‘We are billions’.  The engine simply would not cope with huge hordes of enemy units and their health bars on screen so eventually we went with a tower defence type game, with limited numbers of enemies appearing in small waves at intervals.

As a team we were fairly flexible as to the end product, so the game adapted as we progressed through development.  I enjoyed this flexible approach and despite the occasional moments of frustration, I enjoyed using Fusion overall.  As a team we all collaborated well to deal with any problems or issues with getting the game running.  If one of us couldn’t find the solution, we looked to the others for help, and it was always forthcoming.  A great team working experience.

Demonstration day

The date for our presentation of the game felt like it came around far too quickly!  However, we were all happy that we had something that looked nice and kind of worked as a game.

There were a few outstanding bugs, some issues with animations and unit movements that we had to iron out at the last minute.  The story frame was added and we now had a main menu screen and win / lose screens in place too.

As a group we decided we would give a quick powerpoint slide show and say a few words about our overall contribution to the game.  We had hoped to rehearse this beforehand, but for one reason and another it didn’t happen.  In retrospect I think it would have been a much better presentation had we done this, as everyone was a little nervous and I was not alone in stumbling over my words slightly while speaking over the slide.

The demo of the game went ok, I think most of the elements in the game were on show and functionality was demonstrated.  We had mostly positive feedback afterwards and I think people were impressed by the artwork and the fact that the three artists style remained consistent so you couldn’t really tell it had been done by different people.

Gameplay needed a little polish and in retrospect I wish we had more time assigned for testing and balancing the game.  Testing the game on more players outside of the group throughout the whole process would also have provided valuable insight.

Final thoughts

In conclusion this assignment was a really enjoyable experience.  Extremely useful preparation for next year on our journey into learning game development. 

Becoming familiar with close communication, team working and SCRUM methodology / Jira will prove invaluable as we move forward onto more ambitious projects, and eventually the professional environment.

It was a pleasure to work with such enthusiastic team mates and I feel more confident in my own abilities as a result.

Would I make any changes to our approach next time?  Possibly only concentrating more on getting the game functioning perfectly early on in the process.  I think we got a little bit excited about implementing the artists work early on to make it look good and then ironed out issues with how the game functioned a little later on.  Using placeholder art until the game runs fine is probably the best way forward, but it was the first time any of us had been through this process so a lesson learned!