My name is Al Ridley and I'm a freelance game developer with a focus on working with small teams and individuals to assist in the process of bringing game design documents to life. With over 20 years of general programming experience, I bring plenty of knowledge and passion to any project I work on. Whether your goal is to test out a game idea via the construction of a prototype, or you're looking to add another team member to meet deadlines, I am available to work with you remotely to get your project ready for release.
Looking to hire a game developer? |
|||||||||||||||||||
Email: info@eatsleepindie.com | |||||||||||||||||||
Discord: eatsleepindie |
I have over two decades' worth of experience as a freelance programmer and almost 10 years experience with Unity and game development. I began my freelance career programming data-driven web applications using Coldfusion & PHP, and following over a decade of success, I decided to cash in all my chips and begin a life-long dream of developing video games for a living.
Work over the last several years has ranged from having a small part in games - setting up Steam SDK, building multiplayer frameworks, etc. - to Lead Developer for Creative Storm Entertainment's sequel Age of Gladiators II. The development team was small and so my responsibilities were numerous, ranging from rigging character models to programming AI for the arena.
|
|
Looking to hire a game developer? |
|||||||||||||||||||
Email: info@eatsleepindie.com | |||||||||||||||||||
Discord: eatsleepindie |
I have over two decades' worth of experience as a freelance programmer and almost 10 years experience with Unity and game development. I began my freelance career programming data-driven web applications using Coldfusion & PHP, and following over a decade of success, I decided to cash in all my chips and begin a life-long dream of developing video games for a living.
Work over the last several years has ranged from having a small part in games - setting up Steam SDK, building multiplayer frameworks, etc. - to Lead Developer for Creative Storm Entertainment's sequel Age of Gladiators II. The development team was small and so my responsibilities were numerous, ranging from rigging character models to programming AI for the arena.
|
|
I've been spending time adding to my EVE-inspired MMO recently and have finally converted the C# code that controls the local player's ship in Unity to similar methods that run in the Java extension. What this means is that I am now able to add any number of enemy ships, provide them with a target, and they will fly through space just like the player's ship does but without the need for a single Unity client to be connected; it's entirely server-controlled. If the player's ship gets within the aggro range of the enemy, they'll immediately be targeted and the enemy will move into attack position. This enemy ship will also alert any nearby enemy ships so they all attack the same target simultaneously.
I've been spending some of my off-time continuing work on my Titanfall-inspired prototype and just finished up the test course for some new mechanics. I've added three new features: wall-running, sliding, and double-jumps. Results are featured in the video below, which has a small teaser at the end which hints at where I plan to go next.
I decided to dedicate my weekend to starting a new demo project with the intention of adding it to my portfolio and Itch.io profile. This will be another ongoing side project that will hopefully serve me well in finding freelance work, same as Runiq Online has already done in the past. This time around I've opted to create a game inspired by EVE, the space-themed MMO that has been around for as long as I can remember. EVE seems like the best choice given that the client is basically just for visuals and for sending input requests to the server and I am fairly confident that I can go so far as to have all of the ship's transform updates calculated via the server extension, which would ensure that the client really is a dummy. This is something I've never done in the past but for now I'm going to get the code for movement of the space ships done in Unity to save time and in the future will move all of this to Java for full server control.
I was playing through the Titanfall 2 campaign recently as I've done countless times before and during the level in which the player travels through time I got inspired to create the mechanic in Unity. My goal here was to whip up what worked as quickly as possible for the sake of having some fun in the Unity editor and the methods used here are nothing I would have gone with for a game I was intending to release. That being said, let's breakdown how this thing works.
First up is the save/load system, which is about 95% complete at the moment. I've gone through and ensured that absolutely everything is being included in the save file data and that quarantine zones that have been spawned already are recreated exactly the way they were at the time the game was saved. I also have the type, position, and other important data stored for each and every zombie, the only current exception being corpses - for the alpha release I will likely leave that as is since it is not anything that needs to be in place for the first round of public testing.
The codebase for RIZN has grown so large in size that compilation times are really starting to affect my progression. It takes so long each time anything is changed in a script for the project to recover from updating everything that I am spending a fair chunk of my time just waiting and watching. I'll keep pushing through, but recently decided to take a short break and work on a new, simple project for the sole purpose of being able to progress quickly and efficiently.
I've just finished the remaining work for 1-handed melee weapons, which were functional but still needed to be tied into actual gameplay. They now work with weapon racks to allow players to easily swap them out when needed, and I have also found a way to make the severed arms of zombies work as weapons as well. My hesitation with this was due to the how often the player would be able to grab a severed limb and start killing rizn with it, but I think I've found a way to make them work without making things too easy.
This devlog is long so I've split into two sections: the first covering what's new and the second is meant to give everyone an idea of what to expect in the coming months.
After roughly 2 months of ill health, I'm very happy to finally be back in my office and working on RIZN. I spent all of last week working on Runiq Online, finishing up the new features that I had started last year as a way of ensuring that I was well enough to get back to work. Now that I seem to be in the clear to work full-time again, I'm ready to dive back into freelance work next week as well.
My online presence has been non-existent these last few months due to the majority of my 2023 having been spent incredibly ill. Since the start of the year, I have been admitted to the hospital twice and came terrifyingly close to death at one point. It's been a long road back, but I am finally feeling back to normal, and this week has seen my first days spent in my home office in quite some time. I've never been big on sharing details of my personal life online, so I'll leave it at that and get right to the work.
I've spent these last few days finishing up what I had started working on for Runiq Online before this all happened. At the time I was unaware of the health issues that would plague me for 9+ weeks and I was feeling that I needed to take a bit of a break from my zombie shooter project before the final push to get the Alpha release out. Had I known what was to come I likely would not have worked on Runiq at all but given that things were close to being finished when I fell ill, I figured it would be best to get it wrapped up and published before diving back into RIZN - something I am incredibly anxious to do.
Even though progress on RIZN has been a bit slow as of late, I do have some updates and new features ready to share. Work has been incredibly busy (more on that later) but I put time into this project when I can, being careful to take breaks when needed to avoid burnout.
Freelance work has been very steady recently which hasn't left me with too much time to share progress on RIZN. I've been spending the majority of my free dev time fixing bugs and implementing small adjustments to make sure that gameplay is as smooth and performant as possible. As far as what's new, the three major recent additions include an incredibly large propane tank, a missing persons board, and (finally) the first melee weapon.
Well, it's been about two and a half years now since I built the first prototype that would ultimately evolve into RIZN, and I've finally reached the exciting point in the development process where the bulk of the main mechanics and systems are in place and I'm free to polish things up and toy around with new ideas. With zombie attacks and the pooling system finished up last month, I've spent the last few weeks fixing a lot of annoying bugs and playing around with concepts that have existed on my Trello board for as long as I can remember. This devlog covers a few of the new features added since my last post.
As promised, this devlog will cover the second half of work completed for RIZN the last several months. I've still got a few small items to wrap up before all of this can be considered completed, but I figured I'd share since the bulk of the work is done and I don't expect any problems going forward. With these items knocked off my to-do list, nearly all major systems for this project are done and working, the only exception being the mechanics for using research stations to work towards a cure for R1Z-N.
It's been nearly three months since my last post here because I decided it would be a good idea to take an extended break from all things social media related before the final push towards the alpha release of RIZN. I'm happy to be back and sharing progress now and, although I've been silent since March, I was still hard at work and have a lot of updates to share with everyone. I'll be splitting this work between two articles to save everyone from a single, novel-length post, so expect another post to follow this one within the next few days.
I've been continuing to make progress on my MMO demo and have settled on a placeholder title: Runiq Online. On top of adding several new features including spells, a lantern, and a complete UI overhaul, I've also released a Windows download for those who would prefer it over WebGL, available here and on itch.io.
I just finished up moving my MMO Demo project to a SmartFox Overcast server (with some generous help from the SmartFox team), and I'm happy to announce that the WebGL demo is available to play for free directly in your browser again.
Freelance work has been keeping me pretty busy these last two weeks, but I've got some free time this weekend to wrap up the few things remaining in order for me to record a 20+ minute gameplay clip. With the culling system now complete and fully tested, I've spent a lot of time playing through two quarantine zones and putting props, crates, etc. in place to ensure that as much of what's done can be shown as possible. I'm circumventing random generation for this clip in favor of loading predetermined zones and structure layouts to make sure that everything plays out according to plan, especially considering that I've still got a ton of work left to do insofar as balance.
My custom real-time zombie culling system is finally complete. In the end, I saw even more of a performance boost than I had originally anticipated. I was immediately able to spawn 1,000 zombies in a quarantine zone, upping the previous max count from ~600 in scenes that contained a lot of world geometry.
Work on my zombie occlusion culling system is finally complete. The following video might be easier to see on YouTube so I've provided a link below for convenience. Zombies on the left side of the screen (frustrum culling only) will be sent for rendering anytime they are within the view frustum, which includes zombies that are occluded (hidden) by world geometry. On the right, the system I've been working on in my spare time now culls any zombies that are occluded, skipping the rendering process for any that cannot be seen; in practice, this will often amount to several hundred zombies that no longer need to be rendered every frame.