The Choice Engine is a tabletop role-playing game rule set of my own devising based on my experiences in the hobby and my knowledge of the current market.
The modularity I am referring to is partly that I am designing it with multiple settings in mind, but I also want it to be very extendable and easily modified.
In some cases this means designing sub-systems multiple times with various levels of complexity such that players can choose for themselves the balance between simulationist rules and narrative driven gameplay that they think most fun.
Letting players choose which combination of rules also means that I don't have decide on a single correct way that the game should be played.
To this end I aim to present the simplest set of rules as the "basic rules" and include alternatives as "alternate" and "advanced rules".
In addition to satisfying my own desires in the hobby, this project allows me to tackle what is a surprisingly challenging task from a writing perspective.
Rulebooks, much like textbooks, serve multiple roles as both documents used for learning as well as for quick reference in times of uncertainty.
A well made rulebook, again like a textbook, should also be engaging to read instead of painful.
For me, this presents a fun challenge.
This is a collaborative effort with user gitdatgitdat/, using his knowledge of exercise science and personal training to develop an application to help his clients be more aware of their personal condition.
This project initially prototyped in python 3, and has since evolved into using the Godot engine to target multiple platforms simultaneously.
Artificial Intelligence
Robot Navigation Group Project
March 2018 - April 2018
The goal of this project was to take a pre-constructed robot and program it, using python, to audibly count a certain number of tiles of alternating colours then turn and push a bottle from a specified location.
Once the robot had started a run, we were not allowed to interfere with it.
The first part of our approach was to familiarise ourselves with the sensors on the robot.
From memory: the robot had a basic colour sensor looking directly down, a touch sensor facing forward on the front, and a ultra-sonic (high-frequency, high-precision variation on SONAR) sensor facing forward on top.
This is in addition to the motors that could report their approximate revolutions from a given reference point.
The touch sensor was well-behaved while the the ultrasonic and colour sensors were less so.
The challenge with the colour-sensor was that its readings depended heavily on the lighting of the surface it was looking at yet it did not have a light of its own.
The colour sensor's behaviour thus depended heavily on ambient light.
To combat this, we used the colour sensor to take multiple readings of various features in the environment as frequently as we could without hindering other stages of development.
This allowed us to get an idea of the range in which each feature could vary within and even then it was necessary to include a calibration phase.
The challenge with the ultrasonic sensor was that, while it could measure distance within 30 cm or so reasonably well, it could not tell where objects were in its detection cone.
This was a challenge because we had initially wanted to use the ultrasonic sensor to check that the robot was going in the correct direction and to charge when it saw the target bottle.
Only the target bottle was tall enough to be visible to the sensor so we thought this safe.
The problem was that the robot would sometimes, essentially, pick up the bottle in its peripheral vision and charge right past it.
I believe our solution involved finding the object at the edge of the cone to get an idea of the bottle's relative location.
A challenge we didn't expect was that the two motors would sometimes turn at slightly different rates when travelling at low speeds.
The main area that this presented priblems with was the stage where it had to count a number of tiels before turning.
The tiles to count were visually distinct so it wasn't difficult to keep it on track.
What was difficult was keeping it on track in such a way that we could guarantee the tiles had not been miscounted.
Overall this was an interesting project and taught us about thoroughnes in testing solutions and how the real word often brings complications.
Computer Aided Design and 3D printing
Modular Glasses
February 2021 - October 2021
Summary
Designed modular glasses
Games
Alchemaster
January 2019 - February 2019
Summary
Worked with 2 other students to create a short tower defence game.
Implemented Dijkstra/Flow maps for efficient path-finding
Designed and revised the project's User Interface
This was a project I worked on with two others over the course of 5 weeks.
I have preserved the initial form of it here but you should also be able to view it on the course website here.
Because the other two members of the group were proficient in different kinds of art I was one of the main programmers for the project.
In particular I took responsibility for the behaviour of the enemies in the game with the pathfinding being easily one of the most interesting aspects.
I also took partial responsibility for the User Interface design as I was the member of the group most experienced with the genre of game we were creating - tower defence - which also meant that I naturally was given partial responsibility for checking the balance of the game.
The path-finding was interesting because the technique we had learned for path-finding was among the best for a low number of actors, especially when destinations needed to be recalculated frequently.
This method, the A* method, has each actor probe possible moves, preferring the shortest path towards the target that it has thus far explored.
I knew that we would have many many actors on the screen at once, meaning that any way to reduce their need to think would be greatly valuable.
Further, our game had player-created mazes being constructed while enemies were moving towards a static goal location.
The long mazes meant that there was a long path to calculate.
The solution I arrived at, after discussing the project with a friend with greater experience in the field, was to use flow maps.
In this case the map itself calculates the distance a given tile is from the goal.
The downside is that the entirety of the map must be explored to determine its distance from the goal, but the upside is that this only needs to happen once per update.
For enemies this is much faster since they simply need to look at the tiles adjacent to them and move towards the one with the lowest distance to the goal.
An additional advantage to this technique is that it enabled us to tell if there were areas of the map that were blocked off thus impossible to navigate from.
This allowed us to prevent actions that would cause this situation.
Software
Software Engineering Class Project(s)
February 2018 - November 2018
Summary
Collaborated with a total of 3 other students to create 2 mobile applications designed with disability support in mind
Performed User Interface testing for the second application
Woodworking
My woodworking projects can be seen below in their own sections that may be expanded.
This is done, for now, to ensure that the text associated with the projects stay with the projects themselves.
I do have experience with more rough and ready woodworking, though, in more recent times in the form of helping my father with home-renovations.
The renovations were for replacing rotted wood in our shed and otherwise reinforcing it.
One example where we needed to think a bit was that one of the beams we cut rot out of was not cut square due to difficulty of access so we then had to estimate the angle it was off by so that we could wedge the fresh piece in.
I made this guitar stand in year 12 as my woodworking project.
I started by researching what current trends were in guitar stand design, followed by taking measurements of my own guitar.
With this I could sketch out potential designs.
Once I was satisfied with the sketches I created a mock-up from wire to test my measurements, especially important given all the curves.
With the mock-up adjusted as desired I traced it to make patterns for bending guides.
Once the guides were cut out I needed to co-ordinate with my teacher more than I had before in order to figure out the best way to bend wood into the desired shape.
His suggestion was to use the lamination method; whereby several thin pieces of wood are bent, after being softened via boiling, at the same time then glued in shape and trimmed.
This is the technique ultimately used, but it did necessitate him making something that we could boil several pieces of wood nearing 2 meters in length at the same time.
His solution was a long vertical steel tube capped at one end and heated via camp stove.
The bending and lamination process was repeated for each of the four pieces, each with their own guide and many clamps.
With the main pieces constructed all that remained was the receiver for the guitar neck, the pads to protect the body of the guitar, and to connect it all together.
The neck and back support were connected by drilling and chiselling slots and teeth.
The others, including the pads, were connected via dowels made from a different wood for contrast.
I made the pads using small thing blocks of wood, a section of suede fabric, and polyfill by placing the polyfill on the block and wrapping it with the suede before using a staple gun to affix the suede to the bottom of the block.
The neck receiver, like the dowels, was made from a hard wood for contrast and durability.
Finally, once everything was assembled and sanded smooth, I coated all of the wooden pieces with a couple layers of lacquer via spray-gun, sanding with high grit sand-paper between coats to remove burrs.
