The first project that we had to make for Studio1 was a brief titled “Status effects = victory!” The designers of the cohort had to design a game that utilised any three status effects and win the game using them.

The keywords myself and my partner Josh used where increased reputation, score-multiplier, and bouncy. The result was a game that used only two of these words within its design.

How you play

Slot charmer is an arcade style game, with the twist that the machine may or may not like you.

 

You cough up some cash, pick up the balls, and hope you get three of a kind. If you go too much into debt, you lose, and you’re kicked out of the establishment. If the machine doesn’t like you, there’s a chance it’ll randomise the symbols while in play. If it likes you, it can give you a combo with two of a kind instead of three and it can double the payout.

What went right with the game

User Interaction

Players picked up the interactions of the game right away. Although the game is limited to a single mouse click, every player was able to start the game, then click and drag the balls to the top to start play.

Game Flow

In following from ease of interaction, the game transitioned quiet well from each play state. After dropping each ball into the game, the player is able to press start when they all fall down and play again. This makes the gameplay fairly snappy, and allows the players to achieve their minute to minute goals far easier.

Documentation

The level of documentation created for this small project meant that we had clear goals of what we wanted from the game and what the game was. Although the Technical Design Document was my first attempt and probably lacking in something, I felt it detailed the functions of the game that would be required quite well. The only thing I felt was lacking from the TDD was a UML diagram for the class structures.

What went wrong

Time

One usually thinks of time management in regards to game projects and assessments, but in this case it was a rather silly thing. We thought we had three weeks to work on the project when we had two. A silly mistake I hope not to make again.

Scope

Leading from the previous point, our game was way too large for the time we were allotted. In our original design, we had a system for dialogue for the machine, giving it a personality and personal touch to the experience. The game interaction and gameloop were uneffected by this, but would have been great for the overall aesthetic, and gives better context for the fondness meter.

Use of ‘status effects’ words

As indicated in the intro, we only ended up using two of our keywords, due to the development cut short. “Reputation gain” was used for our fondness meter. Fondness wasn’t used as a status effect however, but as a game state. The machine is always either fond or not fond of you. The bouncy status effect is actually in the project source code. The code is there to activate the balls bounciness for a set time, I just never got to implementing it. This leaves only a single ‘status effect’ in the game, and that seems to be a bit of a failure in terms of the design brief.

In the future, we can consider using the full extent of the design brief to fully realise capabilities within games.

Unity Versions

A problem I thought I learnt years ago during final project, but apparently need to hammer it in a bit more, is making sure that everyone on the project is using the same version software. Having the entirety of your prefabs break due to the project version being made in Unity 5.4 beta is time consuming and irritating.

Frequent Documentation Updating

As this is the first time I’ve been exposed to doing Technical Design Documents, I know I’ve still got a learning curve to go in regards to that. In relation to this project however, updating the TDD after the project has started should be a habit I need to get into. As mentioned previously, the technical implementation went well for the most part, but started to become a bit jumbled as the end of the project started drawing near. The primary thing I’m thinking about is how different systems interacted with the fondness variable, and how they execute based on that. As the GameManager had control of the key variables, other scripts where simply checking the gamemanager fondness directly, then executing based on that. While that functions, it does mean that code related to fondness based behaviours are all over the place, and can be tedious find relevant code.

This could probably be fixed with documentation updating. If when a system is changed from what the original plan was (which will always happen), then going back to update the document does two things: Makes a reference point for how the system changed over time and allows people joining the project after the fact to implement the same functionality.

Don’t implement things last minute before playtesting

Just don’t. Everything will horribly crash and burn.

 

Conclusion

While I believe we had a solid design concept and implementation plan, the fact we just didn’t do enough in the allotted time is where most of the shortfalls within the game occur. Now that I’ve started the second project for studio (noting the end date of the project), I intend to make to keep track of project development.

You can download Slot Charmer from Josh’s itch.io here