I was brought onto the Dappervolk development team as a front-end programmer, primarily working to translate designer mockups into functioning HTML/CSS as well as connecting the pages to the back-end code. Post-alpha testing, I took on more back-end coding responsibilities, maintaining the existing features and adding new ones. The development team underwent some changes and I helped with settling in our new members, working together to see the site through its beta testing phase. Currently, we are working towards improving current functionality and adding more fun features for release.

Working with a more experienced developer to produce the release version of the site, I built the features related primarily to social interaction and converted old Ruby front-end files to PHP.

While the initial number of participants in the competition was fairly small, I anticipated that the site would eventually need to host a large volume of images and opted to use Amazon S3 to host images. As there is no objective way to score art, I joined the game designers in brainstorming a scoring system that seemed fair, and built tools for them to tweak the scoring values based on player feedback. At launch, the site hosted about 7000 participants, growing by about 10 times in the next 4 years.

As a frequent user of the site during its alpha phase before I joined, I had a number of ideas that I implemented when I joined the development of the site for its beta phase. This included restructuring the HTML elements so that writing custom CSS for users would be easier, rewriting the overall layout to be responsive, and compiling the CSS from SASS files for better project organisation and facilitating the creation of site colour themes.

A common complaint was that creating new pages was confusing due to the overwhelming amount of information on one page; I broke up the forms so that sections of the UI were grouped together and easy to focus on. At the same time, as frequent users of other sites that regularly underwent disorienting layout changes and were slowed down by unnecessary fluff on the frontend, we wanted to keep the look of the site as similar to the old layout as possible. The site is now fully usable on the mobile layout and preserves the old, simple look of the site that users enjoyed, while being practical and highly customisable.

This requires an explanation of ARPG culture, which I'll try to keep brief:

• ARPG stands for Art RPG, which is a format of game that is hosted on an art gallery website (specifically, deviantART).
• Players own characters - most of the value of a character is based on its visual design (as it is an art community, after all), which cannot be changed easily, and most if not all ARPG groups need a masterlist to keep track of the designs that exist.
• While the specific gameplay/reward structure of the game can vary wildly between groups, the core mechanic is that players can submit drawings of their characters in order to earn rewards, which can be used to earn upgrades to their characters, or create more characters to play the game with.
• Typically, all of this is handled manually by the players, game administrator and a team of moderators using spreadsheets, which takes a lot of time and energy and introduces error.
• In addition, characters are often designed by the players themselves according to guidelines written up by the game admin. These guidelines can be scattered and/or inconsistent due to manual management across multiple different content hosts.

As I participated in the community as a player, I saw many game features common to a large number of ARPGs that could be automated, some of which I implemented in a custom website I helped to create for one such game. If everyone could easily set up a basic website to hold a list of characters and information, it would make it radically easier for people to create/manage games, and for users to access the information they need.

I wrote a design document that listed all the features I wanted to include in the release build and worked in a structured manner, posting regular updates about my work every week to Patreon and seeking feedback from future users. I also included my plans for the following week in the interest of being transparent and accountable.

Features include:

• User management
• Using deviantART's API to verify the identity of a user
• Editing and searching of basic data and uploaded characters
• Automated reward distribution
• Built-in tool to manage raffles, a common method for distributing prizes
• Extensive logging of users' game activity for verification purposes
• Well-documented code and detailed instructions for setup

I used the Kohana framework and Bootstrap 3 to build an image uploader that contained all the features I enjoyed, and added on some more that I wanted:

• Drag-and-drop mass uploading of images with editing of file names/file descriptions
• Folders for sorting images
• Viewing images sorted by folder, or by upload date
• Integration with ShareX to upload screenshots instantly
• A palette generator using Imagick that would generate a 5-colour palette based on the colours in an image
• Image tagging
• Text hosting that has a few display options, including but not limited to: line numbering, plain text mode, HTML mode
• Mobile-friendly, responsive layout
• Additionally, I set up the LAMP stack on an unmanaged Ubuntu server to host the site

I am still using this site on a daily basis!

Has the following features:

• The engine takes in data in JSON form and randomly selects a next room based on a number of possible connections. The next room can also be made deterministic.
• Commands can be aliased (for shortening common commands, e.g. directions, checking inventory).
• Rooms can have random or fixed contents.
• The player can pick up items and check their inventory.
• Limited backtracking is possible, to a certain number of steps.
• Every playthrough would be different, with limited ability to head in certain directions.

While the concept is often used for procedurally generating English text that sort of makes sense, I hadn't seen it used on Japanese text before, so I wrote scripts to digest the source texts (corpus) and produce the data for my tweets. The bot itself is a simple PHP script that generates a string of text based on this data and posts it to Twitter every 15 minutes. The verdict: it also sort of makes sense in Japanese, but due to the way I had to break up the grammar for flexibility, it occasionally posts half-formed grammatical structures.

I handled the game code, meticulously timing the visual and audio effects to the brilliant text written by my teammates for maximum comedic effect, and created the puzzles in one of the routes. In terms of technical difficulty it's possibly the easiest game I've ever made, but quite possibly the most entertaining.

Aside from realising one of my small dreams of releasing a game on April Fool's Day, it gave me the opportunity to learn to use a popular game engine (that I also helped to translate into English officially!) within a short timeframe of a month. Characters were designed by my teammates, and I produced weekly builds of the game to share and seek suggestions/feedback. The graphics were a combination of edits of free tilesets from the now-defunct First Seed Material and my own handmade sprites.

Created for a game project module in school, this game was my first foray into using the Unity game engine.