Restaurant games are the subgenre of social simulation game on Roblox that I began with. In various time periods since I created my Roblox account in 2014 and 2022, I dabbled in and out of these types of social games both from a development and playing standpoint. I enjoy the serving, baking, cooking and creative aspects of them and love seeing new innovations in the games to give a fun, yet educational experience to younger players.

We've seen lots of different innovations in these types of restaurant or cafe games over the years, whether it's encompassing hotels, adding security, or even waterslides! My approach to innovating and improving this subgenre is by implementing new mechanics to improve the realism of the game. This includes more interactive elements, improving the serving and cooking processes, trying to bring the experience as close to real life as I can (through food safety etc), and encompassing VR and better mobile/console compatibility.

Machine types

You have a few different things shown here. The first video shows a brief early in-dev version of a type of my machines from 2021. This type of machine I call "recipied", because you follow various recipes to amalgamate into a food, drink or meal at the end, using a large range of different machines. These can include ovens, stoves, friers, microwaves, toasters and way more, and each of these machines, depending on the food and machine type itself, requires the player to interact with it differently. For example in a microwave you might be trying to hold the door shut, for a stove you might be moving the pan about to stop your food falling out the pan, for chopping a carrot you might be having to choose the best time to chop. All of this included hand washing & basic hygiene and is made to be as close to working in a real life kitchen as possible.

The second video you see is a very old in-dev version of the touch-interact machines I built in 2017. This was a major step forward, for the time, in making the machines feel more interactive and engaging for players, allowing them to physically manipulate the machines in a more intuitive way. They featured machines that players would walk up to, similar to legacy touch-interest machines, the player would select what they wanted the machine to do using the UI at the back of the machine (for example, change the cooking time or method), and then load the food in their backpack to prepare it by touching the machine with it and waiting. This was a step up from the very old touch-interest machines and added a new way of enjoying the cafe games.

Whilst I don't have a video of it, there's an abundance of them on YouTube, I also used to develop touch-interest machines. These were extremely simple machines utilised by most cafe games up until 2019, where a player would click on a base (for example, a cup) to collect it, then walk into maybe a tap, frosting, creamer, coffee machine and more. The more advanced versions of these machines allowed you to chain them, for example, collecting a cup, adding coffee then milk would give a latte, or a hot chocolate and coffee would give a mocha latte. Whilst these machines were extremely simple and not very intuitive, they did a good job of getting players through the recipes quickly without much brain power so they could spend their time interacting with other players.

The last video shows a supplying concept for the game in which players would move crates from one place to another to restock items. The idea for this came briefly from a mixture of Mining Inc. and Work at a Pizza Place, where in the former, you'd see automated cranes moving crates of resources about a refinery plant, and you'd have to transport supplies to the restaurant in the latter. By giving players control over this, it introduces a new interesting mechanic not seen much before.

Innovations

1. A bezier curve generator that moves a bag across a smooth line by plotted points - similar mechanics were used for conveyor belts and a drone delivery system
2. A large range of the machines used in the restaurant gameplay
3. A sink for washing dishes and hands
4. Chopping boards for food preparation, the wooden one for lower skilled users, the food specific colourful ones for higher skilled users

There were various other innovations and improvements made to the machines and gameplay systems over time, including the introduction of more complex recipes, better user interfaces, and enhanced feedback mechanisms for players including haptics and audio cues. We encompassed modern innovation with the gameplay experience and advanced mathematics, for example we had pulleys that would move orders about a ceiling track hoist around a cafe, we had a drone delivery system in one instance, and most importantly, NPCs when there were slow periods of customers in the games. The more we innovated, the more machines and interactive appliances appeared that brought a new level of immersion and engagement to the gameplay and the subgenre as a whole.

We introduced cleaning, maintenance, breaking machines, and more to enhance the gameplay experience and provide players with new challenges and interactions. We also brought in learning mechanics that allowed players to improve their skills over time that could be transferred into real life. These included multi-coloured chopping boards after a certain level which are a standard in UK kitchens, where to prevent cross contamination, you only use certain chopping boards for certain foods. We introduced hygiene too, allowing players to clean floors, tables, dishes and their hands to prevent the spread of infection, but more improtantly to gain more experience and points! We also brought in machines that you wouldn't typically see in home kitchens, for example, serving carts, conveyor toasters, blast chillers and more to give players a more unique understanding of the food service industry.

VR compatibility

1. Early machine format for VR users
2. Hands used for VR functionality

There's not much to say about the VR compatibility aspects of the game yet. This has only so far been theorised, it's something I've been working on for a while but struggle for the resources to fully develop. I've had a working copy before where players are able to interact with the kitchen, however I'm not yet 100% skilled enough to enable more creative unexpected play with VR integration. This is still an avenue I'm really interested in exploring and am looking for unique ways to encompass VR compatibility into more games.

In Roblox social games, such as cafes, army groups, restaurants, salons and more, users have the ability to rank up into higher levels, and then into event hosting or leadership roles. This is the same concept that was used for one of my groups. In social groups, usually this was conducted by P2P interviews or trainings. Whilst trainings are still great for assessing low rank movements, that assess skill, player would have to wait for interviews, possibly at difficult times and be asked a series of open-ended questions that had to be answered immediately in limited amounts of detail.

As a premise, this works great, but it can be made better and more accessible. This is where quiz systems come in, without a need for the P2P interactions, allowing players to be able to write and send applications at any time, and have the option of having them automarked. This was especially good because it reduced pressure, added a new mechanic into the game, and allowed players far more time to formulate answers with more closed questions.

In-game integration

An example quiz page made for a multi-subgroup game

On the right here, you're seeing an old example of a game integrated quiz system. A few laptops were sat at a certain booth in a restaurant and when a player sat at one, they'd have the option to fill out an application under the guise of "getting a job". This application service featured many things including but not limited to:

• Timed quizzes
• Automatic marking
• Manual marking
• Question randomisation
• Question pools
• Multi-page quizzes
• Quiz pausing & resuming
• Autosaving
• Auto-promotion of passed users
• Various roles in one group
• Supported multiple subgroups simultaneously
• Stored passed/failed
• Could immediately advise players where they went wrong
• Large range of types (multiple choice, true/false, short answer, paragraph)
• Featured quiz hints
• Featured quiz bans
• Quiz question media (images, videos, audio)
• Question explanations
• Automatic & manual feedback
• Question difficulty ratings
• Quiz timeouts
• Quizzes only accessible by code or role
• Quizzes controlled by database, modified through game or Discord by group leaders
• ...and much more!

This all reduces the stress on group leaders and event hosts, allowing them to focus on creating engaging experiences for their players without getting bogged down in administrative tasks. In most cases, low rank progression quizzes would auto-mark and auto-rank without anyone elses intervention or review, but it was also capable of being manually reviewed from Discord, an intranet, or in-game for quizzes that required it.

In newer versions, open-ended questions can be auto-marked too. This is done by AI algorithms which share feedback on answers and the score it'd give to assist group leaders in quickly assessing the qualities and weaknesses of a submission. AI/machine learning does not yet autonomously mark quizzes.

Eventlog was by no means an original concept, the original idea for me developing Eventlog was by developing on the concept of Smartlog in Pinewood Builders, created by Irreflexive and maintained by Coasterteam. Eventlog works by allowing group event hosts to log player points in a far easier way, and export them into lists that can be submitted directly into leaderstat entries or into an external database.

Eventlog uses these concepts developed by Smartlog, however integrated many further features into it. My version of this concept allowed you to export the points into already made currencies, not specifically to a single points variable, by using conversion metrics set by the event host. My system had a far more complex take on the backup and restore system too, bringing in a more dynamic restore feature allowing you to pick from either the original or the backup or merge both during a restore. My version also gave more visual queues as to tracking information, highlighting players who had negative points, highlighting players with personal notes, and far more! My version also allowed notes to be submitted with the log, as well as notes for specific individual players which could be used to specify punishments or bonus reasons, very useful for group hosts. This version also allowed hosts, or the people defined as having automatic access, the ability to add other users or roles to log access roles, allowing them to modify logs too. It also introduced a hover system where once enabled, you could add or remove points from users by hovering over their character and clicking them, launching a profile of them showing their current points and notes, changing them there, previous attended events and more. Finally, I also developed a more dynamic import and export feature, allowing already exported logs to be re-exported, and allowing group leaders to accept/deny individual player point levels during the import stage which enforced player point safety, including doing this whilst in-game.

Acticheck, or Activity Check, is a small project I developed to assist smaller games using Adonis-based admin systems to track how long players were playing on specific teams in their games. It utilised datastores to effectively track how long a player was in a group or team by using a dynamic check system that could be changed or modified by the developer, and would present it in an easy to use UI. This was built for the Chronos Science Corporation group, who had various smaller subgroups representing roles within the game. A suggestion arose in the community by one of the leaders of one of these groups, and so I thought, why not turn this into a little pet project.

Whilst Acticheck does not send data outside of Roblox, it's data can be queried using Roblox Open Cloud, given that Acticheck sorts it's data into easy to find and locate scopes, as well as assigning player identifiable information to these records allowing developers quick and easy methods of deleting player data if deletion requests are made. Acticheck allows users to offline search too, searching players who are not in the game, or players who have never been in the game. All of Acticheck is configurable, however given that this project has been specifically made for this group, it's mechanics are tailored to this game, and would require some tinkering to get it working for each game.

I've developed various types of Discord to Roblox verification over the years, whilst I'm aware databases such as those of Bloxlink are open source, I and many other clients don't believe it suits our needs because of its guidelines, terms and dependencies. This is why some opt for their own verification systems that they even integrate into their games.

Some of the types of Discord to Roblox verification I've made in the past are:

• Going to a website where you log in uring your Roblox account using an OAuth2, then do the same with Discord and link them
• Inputting a code into a Roblox UI given by Discord, then verifying the right Discord account appears on the UI
• Legacy methods (putting a code in your player description)

These have been used in many ways including mirroring Roblox to Discord bans, automatically inviting players in the Discord to an appeals server or channel on a punishment, checking Discord users can perform actions based on their Roblox group rank, getting the players stats from their Discord account without having to specify their username and much more! Linking accounts to third party services can offer many interesting features and opportunities for developers and their games, and taking the time to build your own system to do it allows you to have a good understanding of what's possible and how to put systems like this into use properly, tailored for your experiences needs.

I've developed various punishment systems during my run developing on Java, somehow I kinda find it therapeutic as it's a simple task that can make a big difference. I've developed any including, but not limited to automatic, message-based, GUI-based and even web-based ones! For most servers, LiteBans has always been the way to go, because it's remarkably simple, easy to configure and well-set up out of the box, and has a web-based system where you can manage and view the punishments.

• IP/Geographic bans
• Account/Network vans
• Game vans (Bans for specific games on networks etc)
• Mutes
• Kicks
• Warnings
• Notes
• Stacking punishments
• Removal & reapplication of existing punishments

...and more specialised punishments:

• Bot-spam & Group bans (ability to group punish users in a certain area, sending keywords in chat, etc)
• Competitive bans (bans from specifically competitive games)
• Leaderboard bans (bans from showing on leaderboard)
• Report bans (bans from sending reports i.e Reports.io)
• Webstore bans (bans from Tebex/Buycraft ingame using Tebex API)
• Trading bans (bans from trading i.e Escrow)
• Economy bans (bans from receiving and sending money & using player shops i.e Escrow)
• Shadow mutes (mutes players silently, only they and moderators can see their messages i.e Profiling Services)
• ...and many others!

Impact on appeals

An appeal page featuring automatic account identification & loading of active punishments to appeal

When a system is built personalised to a specific server or network, the possibilities become endless. Even with LiteBans, due to how it can store data, through your own mysql database, you can query its data from anywhere. This is the same for all my plugins. In some places where it has been installed, server owners opted to develop, or have me develop, systems to integrate their punishment system directly into the appeal system. In the case you see here, a user is linked to an appeals page in the ban message, and once they've logged in on a XenForo verified account, the system will automatically load the punishment and information directly pertaining to the punishment itself. This can include if the punishment is appealable, how long it is, the type, and if any extra information is needed to process the appeal. Some servers use a combination of automatically grabbing accounts if the logged in XenForo user has their Minecraft account linked, or attaches a small code to the ban reason for players to enter into the appeal system to appeal their punishment. Servers that tend to use the latter are often ones that rely solely on verification by ingame command.

The benefits of having systems in place to autofill this data, is so that people can't send appeals for others without permission, the appeals teams have the punishment in front of them to look at (in some places, if the ban was an automatic anticheat log, it would pull the logs into the appeal for the appeals team), and you can make sure that only appeals right for that area are being submitted, for example by blocking Discord appeals in a Game appeal area. It also is a good way of preventing appeals from punishments that cannot be appealed, preventing empty or troll submissions, or completely banning certain users from appeals.

Warden

This is what the legacy version of the punishment system Warden looked like, created for the Mutinies network. This is the view that an operator would have seen. If a user was a trial moderator, they wouldn't have seen anything above class 3, they wouldn't have seen any of the competitive, webstore, or permanent punishments for example. All of these features were designed and tailored to the needs of the network.

The Mutinies network used rules classified by 'classes' or severities, and a moderator would see a cheater, click class 1 for movement cheats, and then choose from the list of buttons in there. In each class, there was a button for each offence, for example, 'Flight', and the system would automatically work out punishment lengths, and append information about the server and ban tokens needed for appeals. Servers like the Mutinies network had their systems configured so that the more players broke rules in certain categories, the longer their next punishment would be. For example, if a player had a class 1 client punishment, it would normally be 40 days. On second offense, it would become 75 days, then 90, then be permanent. Most of the systems developed like this had stacking punishments to deter repeat offending.

Sentinien

A snippet of an old mockup build of a web-based punishment system on commission as part of a larger intranet called Sentinien

Here is a brief example of the capabilities of these web based systems. This is a mockup of an addition to an already made panel called Sentinien owned by a network I contracted for. This is image is the prototype before it was remodelled. The punishment system inside Sentinien was linked to the one in-game. You could perform Discord, XenForo & Teamspeak punishments from it, you could add, review, remove and modify punishments, and you could view large sets of data about players like their previous names, capes, and skins which you could look at from every angle by dragging them around in the cell.

Not only could you see player information, you could also see statistics about how many people were being banned in set periods, who the most active banning staff were, and punishment reasons & types were all brought together to show staff what the most common punishment reasons were which were used to help deviate players away from committing the offense.

On the few occasions I've had requests for permission plugins, it has always taken me aback a little bit. I became profient in Java in mid-2021, and with the release of LuckPerms, becoming commonplace in mid-2020, it was strange that servers weren't utilising this option instead. But I digress.

When I make my permissions plugins, I try to model them in a similar way to LuckPerms, a plug-and-play plugin that you can dump on almost any Minecraft server jar, including Spigot, Paper and even Bungee, and have it work out of the box. It uses a web editor that allows you to make the tedious task of writing permission nodes faster, with an autocomplete system that reads the plugins in your server so you don't have to always look for permission nodes in plugin documentation. You can also set world or server specific ranks and permissions, where a prefix might display one thing on a Survival server, but show something else on the Hub. You can set permission groups and individual permissions with expiries. You can create promotion tracks to promote users in a department (i.e moderation or development) without having to remember the next rank. My permission plugins do all of this too, and slightly more.

I don't work to make my plugins better than the alternative, but what are the key differences between one of my systems and LuckPerms?

• My systems still use a web-editor, but also have options to view information in an easy to use GUI

  This is beneficial to those who want to view information without editing anything, LuckPerms uses a text-based viewer for this whilst I use a slightly nicer interface to do it.

• The editor for LuckPerms is external and single-user

  When you load the LuckPerms editor, you are sent to an external website and only 1 person is intended to edit it per editor session. In mine, multiple users can edit in the same session, and if somebody pushes a change whilst someone else is editing in a different session, they'll be prompted to merge individual changes similar to Git. You also have the ability to live edit things which LuckPerms does not allow!

• Contexts are a lot more suggestive than in LuckPerms

  LuckPerms uses contexts to configure where permissions should be active (i.e server, world), but it's not always clear to new users how to use them. My plugins give auto-suggestions, world & server name autocorrections, and you can query contexts in real time.

• Installations of my versions cache information for failure

  If LuckPerms were to fail to connect to a database (i.e mysql, mssql, postgresql), it will stop the plugin loading. In the background when my plugins have changes pushed to them, they will automatically download a very optimised copy of the information into a sqlite on each installation in the background for if the database suddenly fails.

• Node migrator is more effective

  If users are coming from a legacy permission plugin (i.e GroupManager, PermissionsEX, bPermissions), migrating permissions into LuckPerms can sometimes be an arduous task due to inconsistent note transfers, and sometimes you spend more time cleaning non-obvious inconsistencies up than if you'd have manually copied each node. My migrator is more effective and can figure out various types of config for each plugin more effectively.

• The web-editor is internal rather than external

  LuckPerms offer you a way of downloading their web software onto your server to self-host the editor which is great, but because mine is built to be internal, you can customise it in any way you'd like!

• Uses a server settable locale

  Whilst this was possible through the use of contexts, you could set server specific locales in the config of individual servers. By default, all created permission groups, permissions and all data related to permission groups and players was located on the 'origin' locale. If you were to change the locale to something like 'dev', then you could create an entirely new permission setup on other servers, maybe for testing or QA, then if you wanted to merge it into origin, you could!

These differences are not me putting LuckPerms down, they are relatively minor improvements for specific servers who prefer their own solutions which would be impossible for a solution like LuckPerms.

In-game GUI

An example of the in-game GUI that would show permission groups

This is a brief example of what one of the ingame UIs would look like outside of the web-editor. Each permission group could be associated an icon, you could enlist what groups a permission group was a part of (i.e donor or staff), add weights, prefixes and so much more! The system also supported subranks in an easy to understand way allowing you to bring in a moderator, but allow them to keep the permissions from their donor rank for example!

Believe it or not, the reason I got into programming in Java & on Minecraft was to work on anticheats. As an avid player of the late Mineplex network since early 2015, watching the network become further and further plagued with cheaters became quite disheartening. That only got worse after I became a moderator in 2018, and again in 2020 where the depth of the issue was made obvious. Mineplex, in 2016, had one of the top anticheats built for it ever seen... GWEN! However shortly after its phase 2 release, it saw extremely sparse updates from developers not affiliated with the original project who made spotty changes at best. In 2020 when I became a Java moderator for the network, I started learning Java with the hope of one day being able to make an anticheat myself, and possibly work on GWEN. The cheat clients grew in popularity massively, cheating became an epidemic, and whether it was blatantly obvious, or in secret, it seemed that everyone had some sort of link to a cheater. It was difficult to find games without them. GWEN was very good at figuring out who was using combat cheats, such as Reach, Killaura and using an autoclicker, but it was programmed to use a banwave feature that was rarely executed which caused most cheaters to fly under the radar. GWEN was also totally unable to stop movement cheaters, allowing bunny hop players, people with flight and so much more to run rampant. Once the leadership team figured out that GWEN wasn't working as well as it once did, the QA moderation team was given the resources to see the advanced information that would allow them to ban players for less-obvious cheats - but guess what, not one of them ever did, and god forbid you pinged one to ask for a review.

Now obviously as of writing this, 5 years on, we know that GWEN never really saw a proper update before Mineplex was on its downward spiral. A year before the closure of the Mineple network, the single developer still working on the network pushed many updates to the anticheat, removing the banwave feature, lowering the thresholds, and most importantly, allowing GWEN to monitor movement cheats. GWEN was top of the range again, but the cheaters had become so dominant in the community, that Mineplex couldn't survive blocking the freedom of their now mostly-cheating community.

This is what caused me to abandon anticheat development on Minecraft. I developed MAC for the Mutinies network privately, but development on it stopped once the codebase was redone. Here's some of the very early development of MAC!

Extremely early development of MAC (Mutinies Anti-Cheat) - Est. 2020

MAC was originally able to detect most combat cheats and some movement cheats with no issue, using various checks for each, these included:

• Killaura
• Reach
• Autoclicking
• Timer
• Flight
• TP-Flight (a certain NCP bypass that would allow a brief burst of flight after a player teleport)
• Bunny Hop
• High Jump
• ...and a few others!

If resources were retained to continue the development of MAC, it could have been quite a strong anticheat for its time. MAC allowed you to view anticheat information in extreme amounts of detail, ranging from the exact parameters of violations (reach range, click speed, head snap distance), how many there were, leniency by ping, and having a system that would calculate possible cheaters without them making any violations. This was usually through new accounts, MAC extreme prejudice which detected alternative accounts with violations or anticheat bans on the same IP (inspired by GWEN Extrepe Prejudice or GEP), and packet watching.

One of the biggest challenges we had during the creation of MAC was false positives. If you were punished automatically by MAC, either by banwave or by instant ban, you'd be given a code in the ban reason that could be used to track violations that lead up to the punishment which was extremely effective in appeals. The big aim we had was to find the balance between accuracy and playability. MAC had a tuning system that allowed staff to adjust thresholds for checks there and then, as well as regionally set thresholds depending on server type, playerbase, game, and even geographical region. For example one of our glide checks would falsely alert sometimes if players had over a certain amount of ping, a similar issue happened with reach violations simply down to latency. MAC was able to account for these by dynamically scaling violation thresholds based on player connection quality, which greatly reduced the false positives without making the system too lenient.

MAC wasn't just about detection, it was about giving the staffers using it the right tools. This paired with the Profiler also mentioned on this portfolio, suspicious players could be flagged before even getting into a game, with their data stored for review. Moderators could view timelines of violations, graphs of reach or click patterns, and note information tied to player accounts. This meant bans could be both fast, and more accurate, and allowed for bans based on clear evidence rather than vague suspicion.

In the later versions of MAC, low severity violations would raise silent alerts, allowing moderators to observe without tipping off potential cheaters. Consistent or extreme violations would push a case into an 'auto-ban' queue, while specifically marked servers could opt for instant bans to maintain competitive integrity. This approach was used as we wanted to avoid cheat developers being able to guess our thresholds by slowly increasing cheat settings until they get a ban. With the banwave, they always came randomly unless a player was deliberately setting off every check.

Despite the effectiveness of the anticheat, MAC faced many of the same limitations that every anticheat does: the constant arms race between developers and cheat developers. Every update required new changes, new thresholds, and every bypass needed a more creative solution. Still, for the time it was active, MAC provided a reliable backbone for fending off cheaters, which gave moderation staff a good alternative to the pre-existing solutions of finding something on SpigotMC that wasn't built for Mutinies.

The profiler flagging a user with 2 banned accounts for either cheating or 'Compromised Account'

The profiler (or sometimes referred to as the 'Accounter') was a system that would investigate new players, given they meet certain criteria (new player, low level, no rank etc), and did a background IP check on them as they joined. The check would iterate through all of the accounts that came up and count ones that had recently been banned for cheating or had compromised account bans. Once a player was found to have accounts related to them with these bans, the profiler would send an alert to online moderators and tell them a potentially suspicious user has logged in and where.

When the moderator hovered over the name of the suspicious player, it would list the accounts in connection to them in order of last joined, where gray names were normal accounts, and red ones were ones with an active cheating or compromised account ban. If the account had a very large amount of associated accounts banned, I think it was over 50, the profiler would automatically compromised account ban them.

This is based off a Mineplex feature that did something similar.

Shadow mutes & MAC Extreme Prejudice

A profiler muted player trying to speak, observed by a moderator

The profiler didn't just mark and alert potentially suspicious players, it also took proactive steps to circumvent people disrupting the community. If players had a large number of associated accounts, were low level, with low play time, or had an associated account with an active mute, they would receive a 'Shadow Mute'.

A shadow mute was a silent mute where a player would talk normally, but be totally unaware that their messages weren't actually being sent to other players. This was here to prevent bot spam and the troll messages left by Sigma Jello. This was also very effective at preventing toxicity from players on alts of muted main accounts. Once the mute on the associated account had ended, or the player reached a certain level or play time, or bought a rank, the shadow mute would automatically expire. Moderators and the player would be the only ones able to see the message, for the player, it would send totally normally, for the moderator, they'd see a 'SHADOW' prefix, as well as 2 buttons to undo the mute, and the other to automatically ban the user for having a compromised account.

As mentioned in the Anticheat Services, MAC the anticheat made to work for the Mutinies network, used the profiler as one of its methods of designating who to apply 'extreme prejudice', which was a silent status a player would be given to make MAC less lenient against them. If the player had compromised account or cheating bans associated with them, the logic was that theres a possibility that the person is the same cheater, and MAC extreme prejudice was there to try and catch it. This would automatically lift when the associated account bans expired, were removed, or the player hit a certain level or bought a rank.

Player Trading

On multiplayer servers, trading items and cash between eachother is a main mechanic for the game. Whilst on vanilla servers, wandering up to your friend and unloading half your inventory on them is the best way, for competitive combat servers, this isn't always the best option. You have anyone wandering around who can jump in and steal an item as its dropped, you have no idea what a custom item may be until you've picked it up and possibly been scammed, and most importantly, it allows you to trade everything at once including cash and items, so players can't teleport away half way through.

My take on player trading relied on players in close proximity to /trade with eachother. All trades would be logged so you could track where items were going, and you could set caps on what could and couldn't be traded, for example, large amounts of cash or special custom items. The system required both players to accept a deal, if a player tried to change the deal last second, the other players accept button would either reset or begin a grace period so the player didn't accidentally accept the scam trade.

Escrow & Market

Escrow is another plugin I created that was originally designed as a standalone replacement for AuctionHouse, a plugin where players can place items for auction and have it sold to the highest bidder, as well as an instant buy and sell mechanic for players that wanted it sold ASAP. Servers could modify the settings, UI layout, tax and more of the auction system, as well as create featured lists and record the stats of players buying/selling on there, giving a fun, competitive mechanic to servers, especially ones that used custom items of rarity.

Escrow then had a plyer shop built into it, which was a static administrator arranged shop where players could buy and sell items to, primarily to make money in a faster way for items you wouldn't typically see on an auction house (like ores). The player shop system was built to be similar to the one featured in Hypixel Skyblock and replicate some of its features, like buy/sell orders allowing players to flip and make more money by spending more time and effort watching the markets for when best to sell. Prices could either be static or be set to change within margins based on demand, and it gave players on servers an extra way of gaining resources when the aim isn't to go mining.

Imagine yourself, fighting someone you'd been fighting for ages and losing to. Losing gear, resources and your dignity. You've landed a good hit and you've turned the tides and are about to get your last stab to get your resources back, when all of a sudden, the player disappears into thin air and disconnects.

Combat loggers are a massive pain in the backside to competitive players in games, it creates unfair escape methods for players, and if servers choose to outlaw it, it takes moderators constantly online to circumvent it. This is where plugins like CombatLog and CombatLogX, plugins that kill and temporarily ban players doing it, come in with a strict defense against combat logging.

Whilst I dislike people who log out to escape fights or run away with gear, I'm also against the premise of outright banning for it, because this can affect their standing in the community and if they want to rise the ranks later on, which is why I invented SkeletalLog.

Skeletal Log

1. The usual display of skeletal log
2. Skeletal log version designed for ObstructMC/Tribes based on Mineplex Clans
3. What the player sees upon rejoining after the skeleton is killed

Skeletal Log is a type of combat log defense plugin that instead of banning or instantly killing a player, it will spawn a skeleton where they stood with all of their gear for players to kill. This skeleton entity is a fake player and is designed to execute exactly the same events and stat changes as you would get if you actually killed the real player. Upon killing the skeleton, they drop all of the equipment that the other player had on them. It does not perform any bans or inventory wipes unless the skeleton is killed.

Skeletal Log went through various iterations of what entity should be used, how it should be displayed, and even a version where the entity would attack people around it, mimicking the player that left. In the end, a vegetative skeleton was chosen as this was the least intensive on servers. Servers that do actually used custom versions of SkeletalLog were able to mask the skeletons as fake player entities to make it more realistic.

In the second photo, you can see a different type of skeletal log. This is a version that was designed around a factions/clans type raiding system present in ObstructMC & Tribes during their development. When 2 factions, or clans, started fighting, they'd gain warpoints for killing eachother. During a clan war, if a clan member was killed by another clan, they'd lose a warpoint, if they killed a member of that clan, they'd gain a warpoint. If a clan lost -25 or under warpoints, the enemy would be able to use cannons on their base and break/raid their chests. Making sure Skeletal Log worked with that system was important, so in the model you see, if a clan at war killed an enemy skeletal log entity, they'd gain a warpoint and the other clan would lose one. The skeletal log entity also would not expire until the war ended.

PVP Protection

In some versions of Skeletal Log (ObstructMC & Tribes versions for example), there was also a PVP timer system. This was a system that prevented new players from being attacked or killed by people on the server, but also stopped them from being able to pick up non-environmental items, participate in world events, or enter clan territories. This system was put in place because the gamemode was quite difficult to learn and get a hang of, so their leadership wanted a way to protect new players so they could explore before jumping into competitive play.

If a player had an active PVP timer, a combat log entity would never spawn, players could not attack them, and they could not be harmed by traps or cannons. The PVP timer that was custom built into certain copies of Skeletal Log featured a system where the player could disable their own PVP timer and join the fight early, but moderators could also remove them from players, set custom ones, and toggle if the player could toggle it or not. This was quite helpful for events and such.

1. A staff member being forced to enable 2FA on login
2. Automatic session re-entry if still in parameters of old authentication

2FA solutions were used on some servers who wanted extra protection for their moderator accounts, especially on offline/cracked servers, or servers with a history of staff account breaches. My 2FA plugins were very simple systems where if a player were to join and was in a demographic where they'd need 2FA (has a certain permission etc), they wouldn't be able to do anything until they'd created an Authy code account and validated a code successfully. This meant that to log into the network using one of these accounts, you had to have the moderators phone, which would make it very difficult for someone compromising the account to actually log in to abuse it. As well as being given a type-in code for Authy or Google Authenticator, in most installations, the players were given a map in their hands with a QR code to automatically add the 2FA account to their authenticator.

Most of the servers implemented sessions for their moderators so once they joined shortly after validating previously, they wouldn't need to validate another 2FA code again for a little while and would be allowed in automatically. Things that would invalidate a session and require a new 2FA code could have been 24-hours between the last successful code, a sudden IP change from the last login, changing to a server using a different authorisation server or having a session manually invalidated by an admin.

Management

This is an example of a small admin panel made for a couple of installations of this system. It worked with a version with an authorisation server mode. This meant that you could set certain servers to expect codes from different accounts depending on which server was asking. In the example you see here, the player was a Developer and so had to validate as a 'staff' member in normal servers. They also had servers in 'dev' and 'support', which meant that if the person entered the development or support server respectively, they'd be promoted to sign-up or find a code for a different account.

In all honesty, I never expected to make this website. I had a server which originally had a small portfolio on it which went over things like the languages and libraries I'd used, as well as a small introduction. It was very small, not very good, and after I changed my server host, I never put the old website back up and instead put up a maintainence page.

One day, I was bored and decided to undertake a website as my pet project. I'd never really used HTML5 and CSS properly before and didn't really know what I was doing, but I ended up creating this website. The layout and functionality hasn't really changed since it's early stages, and I make semi-regular changes to the portfolio buttons on the website as well as adding images to the slideshow as time goes on. I'm proud of what I was able to accomplish in a paradigm I had no idea how to use.

I decided to undertake this project because I wanted to join onto development teams or undertake contract based development projects, but needed a method to show them to potential employers in a way under my control, totally by my design. This website has stood as a great way of doing that, allowing me to modify the website in any way needed to be able to show off individual projects, experience and my talents.

I've made many Discord bots in the past, for moderation, levelling, game management, community management and more. Each one uses a similar framework centered around the newest Discord features such as embeds, interactions, slash commands and more. The bots I make for clients are fully customised to their clients needs and are made in a model that aims to be 100% configurable without developer intervention which has been a target for me over all of my projects.

My bots are able to echo things from games, listen to internal webhooks, listen and respond to Redis messages and even modify Roblox game settings from outside of the game, such as being able to send broadcasts into the game, scheduling events, shutting down games, changing the Avatar Editor clothing availability, adding experience boosts and lots more. They also encompass a console system on the host server, so owners or administrators of the server can easily go into the bot, debug it and launch administrative commands from inside the console itself.

I've developed comprehensive game management systems and intranets for games and online services, including Minecraft and Roblox. These platforms provide tools for tracking trades, monitoring player activity, and enforcing moderation, all within a secure, centralised interface. Access levels are carefully structured to maintain security while giving administrators and moderators the power to efficiently manage their communities, streamline operations, and respond to issues in real time. These intranets are also capable of helping QA and development teams too, in showing service logs, allowing seamless management of API keys, managing active servers and all errors and warnings being flagged in one central place. These intranets also allow the reporitng of players, receiving of player feedback, surveys and bug reports, as well as organising in-game events and crowdfunds.

Adelade Impero

Shown from a test account only able to access 'Service Status' and the administrator menus

Impero is a good example of one of these systems. Impero was an intranet designed for the Adelade network whilst it was still in development. This system was capable of:

• Showing the status of itself, the public & private API, the Discord bot and website
• Showing metrics such as players moderated, hardware, joins, average playtime in one place
• Allowing remote management of servers including shutdowns, announcements and event management
• A large range of moderation tools including player punishments, anticheat warnings, item & collection management, player reports & appeal tracking
• Displaying history of items, chats, leaderboards and transactions as well as player feedback, surveys and bug reports
• A fully customisable role system that was used to let, not only game administrators in, but contractors and representatives of affiliations with limited access to only what they needed access to
• ...and much, much more!

In Roblox, due to the, as of now, unfortunately poor Open Cloud Group API, groups have to make use of Roblox accounts created for the primary function of being controlled by scripts to make automatic group shouts, change the ranks of users, exile and many more things that should really be available through Open Cloud. There have been many repositories helping to do this such as Noblox.js and bloxy, however during the creation of another service at the time, I found that neither of these popular libraries seemed in-depth, up-to-date, or secure enough for me to use them for my work.

Thus I created my own library for Roblox bots which makes use of the bot accounts Roblox security token and X-CSRF-Token to log in and make changes on the website whilst posing as the user. Due to the methods of control used, my library is able to bypass Roblox bot checks and effectively disguise itself as a regular user whilst still yielding results. My library is faster, far better developed from the start, and uses the most up to date libraries and paradigms with current Roblox infrastructure, and is built around timeouts and error handling which is a common issue with it's popular counterparts.

In the future, I may release this as it's own Node.js repository, however due to my current resources, this is not yet planned.

I'm well-versed in creating responsive, fast and secure webservers using Typescript through Express. These are primarily put to use on Roblox when external databases, Redis instances or Discord bots are used in conjunction with a game or service. I've designed the infrastructure for many of these webservers and create fast and easy debugging and hosting methods including a console system, API token-based access system with levelled access and logs, all which can be used to assist developers on the projects.

All of my webservers make use of sensible rate limits, as well as API request protection systems. These include an API blacklist, a public and private key system where access to specific API endpoints can be locked to specific users, a body-based validation system that uses HMAC tokens to validate the integrity of post data, and logging of every HTTP request the webserver receives. These are all incredible, state of the art features that ensure that data on the webserver is safe, and that malicious users cannot weaponise the functionality of the service.

These webservers have been used for many things, including other systems mentioned on this portfolio, including Eventlog, Acticheck, Punish, Avatar Editor, the Quiz Centers, Discord Verification and more!

Xenforo is an enigma, it's a very popular Minecraft premium website software, but isn't the nicest in terms of it's API sometimes.

My experience using XenForo is minimal, and was my first and only time using PHP in a project. I used XenForo and it's API to create a Minecraft and Discord based account linking system for a client. This worked by creating linking sessions on a database, then sending the user to the session token on the website, and linking whatever account they were logged in as to the Minecraft account that was in the session. This worked similarly to the one used for Discord, where the user would be taken to a link page with a created session, this time without a pre-registered Discord account within the session, the user would click a button to authorise an application on their Discord account, then Discord would link back to the original link page with the token needed to fully link the account.

These were impressive systems used to reward players for linking the account, allowing them to post on the forum, it would echo bans to Discord and the website where Discord access would be removed and the website would prompt the user to appeal, allowing them to select the punishment they're appealing without them having to input a punishment code or staff having to go looking for it. It was a fun to make system and I enjoyed how effective it was once it was published. It was also used to verify ownership of accounts through Tebex, where the logged in user would have their IP checked alongside IP's they'd previously logged in as, so users couldn't buy something in the shop as another user, then charge it back leading to the user being falsely banned from the network. Unfortunately I do not have an image of this one in action.