Conclusion Chapter - Fruit Smashers

Nemanja Bartolovic, Matej Hamas, Daniel Keyes, Delio Vicini

June 3, 2016

1

1 Introduction

It has been a hectic last few weeks, but we have reached the end of the course.We made several changes in the week immediately following the playtestingsession, in order to polish the final product for the Gobo release. We also spentquite a bit of time honing our cinematographer skills; for one afternoon, werecorded game footage, which we then refined over several days into our finaltrailer. We have provided more detailed feedback below, but overall we enjoyedthe course very much.

2 Changes since the Alpha Release

Most major changes we did after the alpha release are already documented inthe playtesting report. However additional bug fixes and tweaks were added tothe final version of the game after playtesting and they are listed in the followingsubsections.

2.1 Graphical User Interface

The most important changes introduced in the GUI system were redesign of themain menu screen, as well as addition of the key bindings screen to showcasecontrols for the car during the game. Both screens are presented below.

Figure 1: The final design for the main menu of the game. It symbolicallyrepresents the game more accurately than previous iterations and has overallbetter aesthetic appeal.

2

Figure 2: Key bindings screen accessed through the main menu. A similarpicture is also visible in the settings.

Additional tweaks were done on several interface elements in game as well.The minimap was changed to always show the locations of all the cars in thegame. Toast messages were organized in a better way with the goal to show themost important in-game events and information for every player, depending onthe game state and situation.

Besides these, 3D health bars were also added for all other cars relative tothe player. This allows him to see hit points of the other cars more clearly inhis viewport, which improves the gameplay.

Figure 3: 3D health bars in game

3

2.2 Gameplay Mechanics

Besides user interface changes, car physics were also tweaked to match thedesired behavior. We believe that the latest iteration of tweaks and changesto the driving mechanics and car physics system in general greatly improvesgameplay by allowing the players to perform drifting and handbrake turns.

3 Screenshots from the Final Game

Figure 4: A screenshot featuring physically based fruit stand destruction.

4

Figure 5: A screenshot featuring defensive flower pots.

Figure 6: A screenshot featuring the church placed as a distinctive landmark.

5

Figure 7: A screenshot featuring carefully placed banana spill.

Figure 8: A screenshot featuring car approaching the fruit stand.

6

Figure 9: A screenshot featuring physically based fruit stand destruction.

Figure 10: A screenshot featuring different power ups.

7

Figure 11: A screenshot featuring 1 on 1 gameplay.

Figure 12: A screenshot featuring 2 on 2 gameplay.

8

4 Development Experience

In general we believe that the initial ideas for our project materialized very wellin the final game. We were able to successfully follow the development schedule.The schedule was quite tough in general, but not too unrealistic. In the endmany things probably took longer than the initial hour estimates, but oftentimesthat was also due to our dedication to make things as good as possible. The onlything we did really underestimate was the amount of work required to give theplayer enough feedback about the game. Also the whole user interface turnedout to be more complex than we expected, since there are a lot of edge cases todeal with.

The different elements of the project structure mostly helped to keep uson track. Only the physical prototype felt unnecessary, since it was only avery rough approximation of the actual gameplay. Sometimes it also felt a bitredundant to both write a report and give a presentation in class about theexact same thing. It would be nice if it was specified even a bit more clearlyhow long and detailed the different reports should be.

5 Personal Impression of the Course

5.1 What was the biggest technical difficulty during theproject?

We spent a lot of time on the development of the AI, as this was our technicalachievement. Also getting real-time performance was a bit tricky, since weaimed for very good graphics.

5.2 What was your impression of working with the theme?

We did not particularly like the theme, even though it really helps to enhancecreativity. We obviously would never have created a game centered arounddestroying fruit stands if it wasn’t for the theme.

5.3 Do you think the theme enhanced your game, or wouldyou have been happier with total freedom?

That seems to depend a lot on the theme itself. Again, we did not like thisyear’s theme that much.

5.4 What would you do differently in your next gameproject?

For the next game project in the same time frame we would try even harder tosimplify things. Having less technical complexity in the game would allow tohave more time to tweak and improve game mechanics.

9

5.5 What was your greatest success during the project?

There were many small successes throughout development. In the end, thegreatest success was to have a working product. It was very nice to see peopleplay after the final presentation. They were able to play the game without anyinput from our side. This was the greatest success during this project.

Figure 13: Players enjoying the game during the apero. Success!

5.6 Are you happy with the final result of your project?

Yes.

5.7 Do you consider the project a success?

Yes.

5.8 To what extend did you meet your project plan andmilestones (not at all, partly, mostly, always)?

We almost always were in time. This was very important, since our game isquite complex and we all had a very busy semester of around 30 ECTS each.

10

5.9 What improvements would you suggest for the courseorganization? (perhaps in D1 evaluation)?

The organization seems quite good. We like that there are a few milestoneswhich force you to have some presentable version of your game. We thinkhowever that the development should start slightly earlier in the semester. Atthe point where Monogame was explained in the lecture we already startedworking with it on our own, since otherwise it would probably not have beenpossible to meet the deadlines.

Also just as a general feedback on the course: we feel a lot of the lecturesin the course were quite game design heavy. It would have been very cool tolearn more about current game technology and how things are done in AAAgames (e.g. by highlighting some recent research works in the area or discussingcommon strategies for typical engineering problems in game programming).

5.10 Did you like the Monogame framework?

We have mixed feelings about it, since not everything in the framework is per-fectly polished just yet. On the other hand, there don’t seem to be many goodalternatives which fill this niche. It certainly makes sense to not use a completeengine such as Unity, since there the learning effect would be much smaller wethink. On the other hand it also was very pleasant that we did not have to startfrom scratch completely and things such as content management and simplewrappers around GPU functionality are already provided.

11