Game Development

Prototype terrain sample

I am currently developing an underground-submarine openworld multiplayer physics inspired game. As a gamer and enjoyer of large, rich maps and depth to gameplay, I would really like to say thats what I started out trying to create. Instead, the story goes that I had this random idea for terrain manipulation. Games like Minecraft and Terraria use squares and cubes, which just feels boring in my opinion. I thought I could do something much more visceral As a sort of tech-demo/proof of concept I programmed a shape that could be modified by boolean geometry operations, mainly union and subtract with a second polygon. This led to a very interesting, but quickly boring "game" to hop around in. However, since I could drill through and place prettymuch any shape I wanted to, it felt like I could "fly" through the land, much like a submarine "flies" through water.

I implemented some modularly built vehicles with use of graphs theory and object oriented programming, and terrain generation using cellular noise. The reason I used cellular noise is because if you look at the lines between cells, they form a network without dead ends. Then by applying an algorithm using a density function on depth I am able to fine tune the width and density of the caves without impacting their interconnectedness. By using this method chunks can generate completely independent of their neighbor, which is optimal.

"Multiplayer is the hardest part of game dev, maybe release that later" I have been told by a lot of people. However, as a hobby-server configurer and network security nerd, I thought I could take it on. I was right, however as a network security nerd I have more layers of firewalls than I do braincells. Every single time I have an issue with networking, its a firewall. Once I found which ports were blocked, yes multiplayer was easy.

The result? I could fly drilling vehicles through terrain, pop out of the ground or into random caves, mine materials, play hide and seek with friends, and even orbit the planet. One of the things important to me in this game was accurate physics: thrust, torque, gravity, mass, all the fun stuff. While I am a physics minor, I am more importantly a heavy player of physics and rocket science games such as Kerbal Space Program. I was able to glide through AP physics simply because it just part of the games world, it included everything we would learn in the classroom. Realistic physics also added to the depth of gameplay I was looking for.

After some formal computer science education, I discovered new ways to more efficiently implement many of the algorithms I had initially generated and rewrote them ...multiple times. Currently everything runs buttery smooth and framerates are high due to efficient caching of unloaded chunks, multithreaded chunk generation, gpu accelerated compute shaders to modify chunk density, enhanced use of object oriented programing and graph algorithms to build massive modular vehicles, authoritative server networking to disable hackers, and other performance tweaks.

So this sounds amazing, where's the game? Well, a game needs graphics, audio, a sound track. As much as I'd love to release it now, its unplayable for these reasons along with a few minor implementations left such as NPC's and reworking the tech tree.

A grid flying through caves

Testing Input Response

Internal View

Building a UAV

I chose to build a drone from scratch for my AP Physics final project. We were given an open ended assignment to build something cool and I wanted a drone. My choice was much more ambitious than the course required, and took quite a while to complete.

For the drones frame I finally had an excuse to purchase a 3d printer. I modelled the frame and arms modularly to support future upgrades and replacements from damage, reducing the cost of operation. Initially I was using some 3d printed torodial propellers due to their higher efficiency and lower sounds usage. Due to safety concerns of the propellers not withstanding tension at higher RPMs and exploding I switched to some generic acrylic propellers I bought. A challenge in designing the frame was leaving enough room to contain the volume of the wires. I went with the Elegoo Neptune 3 as the printer was open-source and had a much better cost-to-utility than proprietary printers such as the Ender series. I am not sponsored I just really like the printer.

The flight computer was the most difficult part to program. Using an ultrasonic distance sensor, gyroscope, and accelerometer the drone has enough information to probably never crash. The autopilot is implemented on an Arduino UNO using a PID controller for stabolization. The autopilot quality is currently impacted every time the drones mass distribution changes, which can be fixed with a reinforcement machine learning algorithm. For the higher level programming such as flight automation, video transmission and WiFi communications I used a Raspberry Pi Pico. There is also a 2.4GHz line of sight receiver for manual control. A future upgrade may contain a SIM card for near-infinite remote control connection, but drone regulations would make this difficult.

The power system is the most physically challenging portion of the drone. The motors took 14.6 Volts, while the UNO microcontroller took 5 Volts, and the Pico and most sensors run at 3.3 Volts. All of the power to the motors ran through the power distribution board, which I modified to also output the lower voltages and used Bidirectional Logic Level Converters to shift between 3.3 and 5V signals where needed. A potential flaw with having all the power coming from the same source is spikes in energy consumption to the motors may cause the microcomputers to receive too little power, which could be fixed with a capacitor. Luckily, I haven't experienced this yet as the 2C discharge rate on the 2.5Ah capacity battery is more than enough. Having a battery this big does mean it takes up about half the internal electronics volume and is half of the drones mass, but it can also maintain full throttle for half an hour making for long flights.

The motors I used were a bit overkill for a 1.1kg drone, as going past 20% throttle sends it shooting through the sky -- which is not a bad issue to have. Here's the technical numbers behind that: I have propellers with a 6cm radius on motors with a 2450KV rating (2450 rpm per volt) at peaking at 14.6 Volts. From this the tip speed is computed to be ~225m/s under no load at max throttle, quite a lot more than what is safe or necessary to get into the air.

Work Experience

• Cybersecurity Analyst for Equifax

  • Analyzed Security Posture, Business Risk, Compliance
  • Supported Vulnerability Management sourced from Penetration Tests & automated tools
  • Handled issues, exceptions, and deviations
  • Provided Security Advisment Services for infrastructure and code development
  • Used automated scanning tools, GCP, AWS, shell scripts, Linux

• Software Developer for Parkside Pool

  This is a role that didn't exist before me. I was a lifeguard and swim instructor here, and the pool I worked at was being swamped with administrative work. Eventually I took on this work for the money that came with it. For ten hours each week, I would be reading emails, co-ordinating lessons, and sending out schedules. Creating the schedules was a tedious task, with siblings at different levels needing back to back lessons, people not available some days or times, and other various soft and hard requirements.
  
  Soon I found out there is no easy algorithm known for finding solutions to problems with many soft and hard requirements. This is a NP-hard and is described in the Nurse Scheduling Problem. Fortunately there was a cap of 128 students I could fit into classes per week and the final algorithm was around O(n³) for n swimmers, so the runtime wasn't horrible.
  
  Implementing the reception and confirmation of lessons was straightforward enough with a Flask site using Stripe for payments, and Firebase service for sending confirmation emails.