I am the Elder God

The first consideration was what resources I would need to deploy a web game, which was the most restricting consideration. I chose the Quicksilver engine because it supports automatic translation from Rust to Javascript and HTML. This choice had several important limitations.

• Simplicity - Quicksilver does not have a high level actor system

• Resources - There were few examples of the engine being used for games of this scope

• Documentation - There were only a few pieces of engine documentation

To address this I set three initial rules about how project development would progress

• +1 Simplicity - To balance realism with aspirations I would only go 'one level of complexity' beyond existing games

• 10 minute assets - Art is an important part of any game, to keep the UI usable and to be confluent with the previous goal, I used slightly modified stock assets that were still an improvement on existing example games.

• Established codebase - To jump-start the project into something tangible as fast as possible I adapted an existing open source game framework as the base for this game.

The next, and biggest, undertaking was laying the groundwork and codebase that would allow me to deliver API that would enable gameplay with shields, freezing, movement, etc. This is where a bulk of project time was spent; implementing the world primitives, state machines to control gameplay, and the other services.

• Game State Controller - The state machine built for Mehen's Portable Casino was adapted for scene control

• Turn Controller - A state machine that would automatically transition turn states under certain conditions (like being out of moves, or actions) was carefully designed to make gameplay less hands-on.

• Environment - To maximize efficiency, the environment was implemented with an on-demand system for tiles and effects.

• Animations and Music - Quicksilver had no built in services to offer animations or looping music so I built controllers to implement both based on time from the current frames per second.

This was the most enjoyable part of the project. After implementing the API I needed for gameplay I needed to create a sensible way to put it all together with a week of development time left. After testing my proof of concept API and understanding what gameplay possibilities that enabled I set and met my MVP.

• Lettered tile terrain - For labeling different kinds of terrain use 'W' for wall, 'C' for city, 'F' for forest, 'R' for road, 'A' for a mountain, and 'O' for a pit.

• Controller accessibility - The controller should as simple as possible for the game; arrow keys and the enter button.

• Environment interactivity - Standing on a red burning tile will hurt you, destructible blue shield tiles that protect you and prevent movement between them and unshielded areas, and purple frozen tiles that hold entities in place, will melt on their own or in response to you attacking them. Your abilities may create these effects as well!

• Abilities - Text definitions, visual cues, and animated targeting UI to make abilities easy and fun to use.

• Consistency - Players should always have a route to the endgame using available pieces.

• Dynamic UI - The UI should never leave you without a hint or direction about how to progress in the game or without a description of its state.