Posted in Uncategorized

Exhibition Cram.

Working in a rushed state of mind , and from recent experience is something that should be  avoided. Last Wednesday before our Brass Razoo! exhibition we were pushed for time and had a lot outstanding implementation on Sommeliers.

We needed Sommeliers to be in a playable state, so not only a core mechanic that was playable but a game loop also. We needed to show our core game play loop and demonstrate our design of this core loop and how it would be experienced within the game, however for this to be effective our mechanics needed to be polished and implemented fully  Now let look at where it fell down slightly.


What Went Wrong

Repository conflicts: the great repository issues of 2016. These have been present several past projects and feature here in “what went wrong” round ups i have, but this issues cost us a lot of time work that was on polish to the menu scenes visually and functionality. While work on the scene was happen a members deleted a button within the same scene as it was linked to other functionally that they were working on. This caused all sorts of push and pull issues within our repository and resulted in loss of work that was made on the project.

Player movement: a key thing in most game however it wasn’t as function as we would have liked. During production on Sommeliers we had character movement implemented but it was consistently buggy,  the player would get stuck in the game space on virtually Nothing that we could see  and in other insistence it  would just float away out of the play space. One of the predominate errors that we faced with our player movement was the uncontrolled force that would push the player back once they had turned around within the game, this was game breaking and was top of the list to fix.

Drinking effects: this was a aspect our game loop the need to work for the intended experience. We had it implemented somewhat and they looked like they worked correctly but once our test build was made it would consistently fail to execute correctly. We wanted these implemented for exhibition as it is a major interaction and win state of our game. There are vital indicator in game as they would trigger when a bottle of wine had been drunk by the player, with these not working, our players would be lost and not know when they had done something.

fire exercise

What We Did About It

At the time there wasn’t much that we could do to save the changes that had been made to the updated scenes, so we had to roll with that punch at the time. Lucky although not great they were only cosmetic changes and easy controller commands that could be fixed easily as apposed to large amounts of game play or key areas. We pulled what we could from the changes and move on with more important issues. The polished elements would have been great to draw people to our game during our exhibition, you can learn from all out come and situation.

We intended to have our horizontal and vertical axis movement working also we desperately needed our horizontal movement implemented so that players could strafe, as this was something that from play tests play wanted because that is what they felt was natural. Fixing this issue was relatively simple, as we figured that the majority of problems were in the setting for the x and y movement and then calling them one after the other, meaning that they were being overridden.

We had one of our drinking effects working ,speed boost on the white bottles however the jumping effect was not in to add variety, and then if we were able to implement mixing the wines together and drinking them, then we wanted to have a different effect for that which would logically be the combination of the two original effects. We worked on implementing  hopping to the character if they drank red wine, we had some issues with setting an appropriate jump force and had this “working” but was not consistent across different test play troughs.

This rush time before the exhibition has in-bedded a greater importance of planing scheduling for these element early on in the process of a project. Greater iteration and breaking down of the structure of a project. Would mean the lose of aesthetic after functionality wouldn’t happen if the planning of these elements was flipped and realized early. A stronger TDD would have found this early and an art bible would have had this atheistic definite before it implementation. Which i explain here.



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 )

Google+ photo

You are commenting using your Google+ 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