Fourth Conversion Phase COMPLETE!

A fine evening to you, readers!

The Fourth Conversion Phase is now complete, and the resulting prototype is more or less done for the time being.

It's a great deal simpler than I originally hoped, in terms of code, visuals, and gameplay, and is a significant downgrade from the previous prototypes made in Unity. This can partly be explained with the fact that I'm still new to the Visual Studio interface, and it took a great deal longer to accomplish certain simple tasks than if I had more experience. Hopefully, this means that future prototypes will be more advanced, and will take less time, allowing me to develop and polish them even further.

In its current state, the prototype plays Rock-Paper-Scissors with the player in a very basic capacity; the player gives their input first, and the "opponent" responds immediately, using a random number generator to decide what its move is. The random numbers are weighted to reduce the occurrence of draws between the player and opponent, encouraging positive or negative outcomes.

In this manner, it's more or less entirely random whether the player wins or loses, and their moves are technically pointless, in terms of which move they make. So long as they make a move, the chances of winning or losing are equal to any other move they could make; for example, a player who chooses their moves with careful deliberation and bluffing would have the same chances of victory as a player who chose Scissors every turn.

With more time, I might design same kind of system to allow the computer to recognise this kind of behaviour, increasing the chances of it countering repeating moves. This would likely work by adding value to an integer variable, and then using that variable in the random number generator when the opponent chooses its move. However, this is a back-end feature which doesn't greatly affect the user's experience at this stage.

A timer, displayed at the top of the game screen, counts how long the player has to make their move; failing to choose a move before the timer completes will grant the enemy a free win, and a subsequent point to their score pool.

On top of this Rock-Paper-Scissors mechanic is a second, also very simple gameplay element; there is a button on the right side of the game window, separated from the Rock-Paper-Scissors game. Clicking this button fills up a bar (which is also constantly depleting at a gradual rate); filling the bar increases the value of the player's wins, granting them an advantage over the opponent by letting them gain the required number of points with fewer wins in the Rock-Paper-Scissors game.

Once the bar is filled and the player's win value increases, it also becomes harder to fill, increasing the required input by 50% with each fill. So, if the first fill takes six clicks, the next should take nine, if the player is clicking at the same rate. Once the player's win value reaches five, it become exceedingly difficult to fill the bar any further, and likely impractical as the game timer progresses, giving the opponent more points. However, by this point, adding more value to the player's wins is largely unnecessary; five points per win is enough to beat the game with two successful moves, while the opponent will always need ten, meaning that the odds are heavily in the player's favour by such a point.

It's up to the player to strike a balance between making moves and improving their win value. Currently, it's largely more practical to focus more time onto increasing their win value, as different moves have little effect on the outcome.



Finally, I'd like to quickly mention some problems I currently have with the prototype, as this is far from the best thing I've made, and hopefully I can put together something better for the next Conversion Phase; as I've mentioned, the way the opponent chooses moves is pretty poor, allowing the player to simply choose any move of their own and still have the same chances for each possible outcome. I would like to have had the time to put together a slightly smarter AI which tried to anticipate the player's moves, and which can be bluffed against.

Also, the game itself, as it stands, is far from entertaining; it's an almost painful clickfest of trying to pick out moves and increase win value for a few seconds, before simply picking any random moves and hoping to win sooner rather than later. The game fundamentally needs some more design work to improve on this issue.

And lastly, the game doesn't even look nice, using basic Webdings symbols, labels, and the simplest of UI elements. Compared to the prototypes made in Unity, or even the Tutorial games from the Fourth Tutorial Phase, this prototype is just ugly, which doesn't really help with the poor gameplay.



That's about it for now, readers. The Fifth Tutorial Phase will begin as of tomorrow, with a YouTube tutorial creating a mixture of XNA and MonoGame framework games, and will conclude on the 1st of March.

Until then, have a fine evening, readers.