Arena Project

Inspiration

The project was inspired by strategy roleplaying games (sRPG) such as Final Fantasy Tactics, Fire Emblem, XCOM, Disgaea and other notable franchises that have built unique experiences centered on tactics-heavy, turn-based combat that allows players to take full advantage of 3D environments' cover and scalability. While many of these offer tightly knit, well balanced experiences for their player-versus-enemy (PVE) campaigns, there is a notable vacuum of player-versus-player (PVP) equivalents in the industry. My goal is to leverage the power of the Internet Computer and the Motoko programming language to build an on-chain sRPG that allows players to import self-customized NFT characters into their game session. Because the IC offers extremely low costs for data storage and on-demand processing, I've been inspired to make it my platform for game design, seeking to prove what's possible with well designed smart canister code.

What it does

The current build initializes a Session, the primary data type of the Arena Project ecosystem. When the smart contract allocates memory for two players to play the game, it generates a Session to manage all gameplay between the two players. Within the Session is a Zone class object that in turn fields two (customizable) teams of 3 character (Mobs), allowing them to move and attack on command. While the prototype lacks a front end, most of the key data types exist in some form and deliver debug information when the project is initialized in a local environment. In lieu of full-fledged NFTs, the game takes a collection of 'Champions' (NFT precursors) and bundles them into an immutable array fed into the Session class. The Session convers the Champion data into derivative Mobs and eventually placed within simulated 3d space (an array indexing (X, Y, Z) coordinates). While the game is only a fraction of the eventual goal, there are several useful tools and methods on display that I've begun to develop while working with the Motoko programming language. At runtime in a local environment, the game places the user in control of the Thief Mob on teamA. The Thief showcases basic functionality and is able to move and attack, as showcased in the project's video demo link.

How we built it

The current prototype was effectively built in three stages that were heavily influenced by my Dfinity grant schedule. The first two weeks were used to build several orthogonal modules that tested several early features in isolation. Although it was useful for working on functions and object classes in an isolated workspace, it taught the important lesson that unless data is being passed between canisters, it's preferable to keep data at least partly compiled; this may, notably, change in an upcoming build due to the stack being completed up to the Session level*. In the second two weeks and up until the first grant milestone's deadline (June 2nd), development started on actual game functionality. Mob movement was introduced alongside rudimentary movement. The first showcase video allowed mobs to be freely selected, moved, and allowed them to attack with modulated damage. Since then, development has started focus on completing itself to the Session-level of the stack (which, at the time of submission, has been completed). Project design has been completed within VS Code using PowerShell to launch the program in the local environment, a method that was showcased during the Motoko bootcamp and one I've grown to endorse. *The Session level allows for external modules imported to main.mo to be handled from within the Session object without exposing certain implementations. This will be reflected in code as additional pattern matching implementation that streamlines initialization and allows for more easily traced data flow.

Challenges we ran into

As stated above, early orthogonality ended up being as much a setback as it was a boon. While it didn't hamper functionality or object coding directly, it did require more direct integration of several classes into a single file rather than letting them occupy their own separate modules. While orthogonality isn't wholly present now, future builds will continue to reimplement this separation. Developing with Motoko canisters in mind was, generally, a new experience that required me to adapt new techniques when assembling the project prototype into a more functional product. The only other large issue that springs to mind were the List object class behaving oddly (with buffers eventually providing superior functionality) and over/underflow errors with no line number appearing during project launch in the local environment - though this was more a warning call to add additional debug messaging to track where errors had occurred during the Session's initialization.

Accomplishments that we're proud of

Above all else, I'm proud to have met me goal of completing the program up to the session level and now having a better idea of the project's trajectory. With sessions implemented, greater orthogonality can be implemented which simultaneously allows more class-specific development and refinement in isolated modules. Tangential to Session's completion also comes the introduction of the Champion data type which can easily be substituted with other data types or sources such as external NFTs, allowing development to begin on a separate ledger canister that can have its data read by the game session canister. Ultimately, the baseline prototype provides a collection of tools that are necessary for the next stage of the development process to begin.

What we learned

The hackathon provided indispensable experience with the Motoko programming language and has provided me the opportunity to develop methodologies for programming with smart canisters in mind. I had the opportunity to implement pattern matching techniques with variant types and found alternatives to array manipulation using the Buffer type among other tools. This also gave me the opportunity to practice managing my own project as I talked to a select number of VCs about what I was building and learned about what it takes to begin a startup. The project not only let me further develop my programming skills but my business abilities as well.

What's next for Arena Project

As stated above, the Arena Project is currently a part of the Dfinity grant program and its next milestone will be due at the start of next month. In the coming two weeks, I will be squashing bugs and refining already implemented mechanics in time for the showcase. With most parts of the core game framework completed, I'll be transitioning towards ensuring the already implemented parts of the project are fully functional. With the upcoming dispersal of grant funds, the associated team artist will begin work on showcase assets in Blender to eventually be used as part of a frontend/game renderer in Unity that will be bundled with the game when actually deployed to the IC. The project's road ahead is not a short one, but I'm excited for all the challenges that come with it regardless of the hackathon's outcome; the Arena Project is something I'm incredibly passionate about.

Built With

• candid
• internet-computer
• javascript
• motoko
• visual-studio-code