Hi, Im Ayden Greenan. I was born in 2008 and really like programming. I love coding backend systems and witness them take everything that's thrown at them, forming a beautiful web of processes that work together like a well oiled machine. I'm not one one for front end development, but I can manage.
I know my fair share of languages. The more you know, the easier newer ones are to learn; I dont have a difficult time picking up new languages. The ones I know most intimately are listed below in order:
Feel free to reach out to me on any of the below, almost always down for a chat :)
Some projects that aren't featured here are on my github. I have a lot of repos on there from my more inexperienced days if you're curious.
Cellvolution is a small project I made over the course of 3 days, although, 2 of those were mostly polish. In this simulation, you start with one cell in the center of the canvas. This cell will then procreate, making a copy of themself. The cells have many different stats which mutate over time. The starting stats can be editted and viewed on the sidebar. You can hover over different cell species to see their mutated stats, how much area they cover (via highlighting), and even their species name! I'm really proud with how this came out and it makes for a great interactive screensaver - messing with stats and letting it progress over the day seeing what comes of it. The most notable thing about this project might be the rendering method I used. The canvas is at a very low resolution then scaled up, with each cell being one square. Then I alter the image data using javascript (via looping over it, filling in cell pixels when needed). This method lets me render very intricate scenes much faster than I otherwise would be (using canvas 2d).
https://cellvolution.glitch.meAfter I finished making Cellvolution, I started to idly keep it on throughout the day, and it caught some eyes. Typically, if they were seated near me, we'd end up watching it together observing the behavior (how stats and shapes develop, different "periods", etc.) Then, I started sharing it with friends enjoying more indepth conversation about it. This prompted me to make a "live" version where the simulation runs on the server and streamed to the clients. Since it was already made in JavaScript the porting process was not too difficult but it presented a new problem: performance. Aside from splitting up the code while maintaing all functionality optimizing was probably the most arduous process. The bottleneck was iterating over each cell rather than their actual functionality. I needed a fast way to randomly iterate over each cell in the simulation. Over the following day I tried different approaches, the most notable of which included linked lists and 1d arrays. The linked list implementation consisted of putting all the cells in a linked list and randomly swapping positions as I iterate over them. I decided to have the linked list be on directional (only having listElement.next). Surprisingly, compared to my 2d array, this was magnitudes slower. My other approach, with a 1d array, required me to calculate the position of the cell based off it's index which seems like it could be faster, but in reality, it ended up being marginally slower than my inital approach: Caching all possible positions in the simulation, then shuffling them and iterating over those. This leads me to believe that JavaScript simply does not lend itself well to this sort of random iteration, and, unfortunately, glitch.com only lets you host nodejs projects. One workaround I considered was using glitch to tunnel the data and have the actual simulation run on one of my servers, still, JavaScript would be the bottleneck and I did not feel like recoding everything again for a small side project.
Streaming the data turned out to be relatively trivial because my encoder/decoder (that I made a while ago) is already extremely efficent because I set each byte individually as needed. Packet size appears to hover around 50kb each. At 80 fps that's 4MB per second or 14.4GB per hour... thankfully glitch doesnt limit network traffic (sorry guys!). If I were to improve this I'd likely just communicate the changes between frames and send updates to the clients, but for now, it's a non-issue. In the frame packets, I include all the species data first (so the player can track species and their stats still), then I send each cell of the simulation, each species having a "renderId" which is mapped to their actual id, which is then mapped to the species which include their color. The client receives the data, interprets it, then sets each pixel of an image data and renders it to canvas. There's no render loop on the client, it only renders when a frame is received. This can lead to some slight latency when highlighting a species when tracking it, but it tends to be unnoticeable and lets me keep the client light weight.
An additional feature I added are logs! They let me keep track of notable events like old species going extinct, dominat species, and species who might be battling eachother. This stemmed from conversation when people saw my original version -- it helps the average person who might be less knowledgeable about the simulation interpret it.
https://cellvolution-live.glitch.meThis project was very fun to make and I'll probably keep it on unused screens for time to come. I like to show this one off because it's one of the more "eye catching" ones; The average person will find it neat. I think this served more to demonstrate my skills more than to expand on them.
This game has a rocky history. Ownership has been transfered many times and the development team has shifted overtime. Originally, arras.io was made (which is based off diep.io), Woomy was forked from an early version of arras and was developed independantly over the years. These 3 games are a top down 2D shooter, arras.io has more classes than diep.io, as woomy has more classes than arras.io. I was one of the last owners/developers of the game. I decided to end active development due to issues with the codebase -- after years of uncoordinated additions from a handful of people it becomes infeasible to refactor large parts or even recode it in general. I managed the community, servers, API, networking, etc. -- the full stack and deployment. Since active development is over I decided to port the game to a single player offline version. This required me to refactor the entire game and to run the server in the browser -- which hasn't been done up untill this point. Due to javascript almost the same in Node and the Browser this was easier than expected:
https://woomy-site.glitch.meHowever, later down the line, I expanded on this code in a seperate project. I wanted a lightweight way to allow for multiplayer. I decided to stick away from Peer to Peer because I didn't want to have to manage a mesh of connections, desync, nat types, all the pain that comes with p2p. I eventually ended up with a 2 server system. One server hosts the website where the client downloads any files. The other server is a "room manager". Clients can now host the game server on their device and open a "room" in the manager which is joinable by anyone on the website. All traffic is tunneled through the room manager as to not deal with the p2p pains and to hide ips. The hardest part about this was figuring out a fast way to route traffic through the room manager. 40 players with a lot of entities on their screens generates A LOT of traffic that the one server has to deal with. I decided to prepend packets with an identifier that tells the room manager what to do with it, tunneled traffic doesnt get decoded allowing me to keep memory low and minimize cpu usage. This system ended up working extremely well and, without issue, handles the load of 30+ players just fine. Since entity data is downloaded from the server each time you play, that allows players to modify their copies of their servers, allowing them to change and add things to their desire, which was embraced by many members of the community and fostered a healthier space for the game.
https://woomy-online.glitch.meDespite how messy this project might have been, it was an invaluable resource and really kickstarted my programming journey. In the end, I'm very proud of what came of it and the experience I gained. It takes a tremendous amount of effort to port an entire game's server into the browser, then frankenstein it into a unique networking system, forcing me to write high performance JS and network protocols.