Leona Fable

(AKA Leon Laszlo)

Systems Designer, QA Game Tester, Professional GM

Contacts & Info

• CV
• Mail
• Linked In
• StartPlaying
• Etherdawn_

Bat Out Of Hell is a movement shooter where time is health. The player is constantly forced to move forwards as their time is running out, and for each kill they get, they gain some time back.During this project I worked on perfecting the movement and make it feel as good as possible, creating levels with the movement systems in mind and playtesting and bug testing as well as fine tuning many components of the game.This game was amazing to work on, I felt that the team was really locked in from day one on this project. Although we had plenty of hiccups along the way I'm really proud of this team and what we managed to make in just 9 weeks. This was my final game project at PlaygroundSquad and I can with some confidence say that this game is fun.

Trailer Coming Soon!

The first thing I did for Booh (Bat out of hell) was to create a gym scene. This was something that I realistically should have done on Technomania much earlier.Here we can see the gym scene. At first it was mostly me using it, however the programmers began using it to test their own things as well, giving the scene more use as I moved on to testing in levels later in development.The most important thing for me was to create and later add as many fixed testable variables as possible. Different sizes of objects, angles of ramps, and heights to jump up to and fall from. This scene is what helped me fine tune the movement and test how it worked.

Here we can see part of the movement scripts exposed variables. I worked side by side with a programmer making the movement for this game. They would implement while I would fine tune, provide feedback, and often ask them to change specific things in the code while I continued to test.I believe that this collaboration is why the movement in Booh is so good. The programmer I worked with is super talented, and was really able to bright my vision forwards. While they also helped me understand what their variables did so that I could better fine tune the players movement.We worked for about the first four weeks on this. With polishing the movement for the rest of the project. There was a lot of iterations of the movement system. Typically we would work for half the week, I'd playtest it myself, then I'd get someone else to try it, see their reaction, and then work on that feedback.

I think the biggest thing that ever changed with the movement system was when we changed gravity. This changed almost everything else, but I think the final product was better than before.The image here shows the biggest change we had in my patch notes. I actually really enjoyed making this patch note, and I honestly wish I had done patch notes like this during the whole project for the movement system. I guess takeaway for the next project I work on!When reworking gravity to make the player feel heavier and fall faster it wasn't exactly a change I was happy to make. I knew that this could potentially mess up a lot of levels, and although my levels were rather small and could be remade, our lead level designer had made much larger levels.So how do you change gravity without affecting the gameplay in any of the levels?That became my question to solve. The solution I landed on was reworking the rest of the movement to feel the same or at least similar, while also trying to leave space for future improvements. It took me about two days of just changing numbers and testing, replaying levels and testing how the movement worked outside of just my gym scene.Although I wasn't happy initially with this change, I can't deny that it was worth changing it, and it's a useful lesson I've learned during my time at PlaygroundSquad, to trust others ideas as much as mine, and try my best to see what I can do with my skill of numbers and data to bring their ideas forth.

Towards the end of the project I was balancing the time gain and loss for the player. We wanted the player to always be short on time, but we also didn't want the game to be too punishing. So the solution the programmers gave me was time thresholds.This allowed me to create different levels, between certain amounts of time, or health in this case. This makes it so that when the player has an X amount of time, they lose an X amount of health when they take damage, and gain an X amount of health when they kill an enemy. We wanted to keep them around 15 seconds of health. So that's roughly where I made sure that the player starts losing more than they are gaining.This in a way is also a way to make good players never feel quite comfortable, since good players need to play increasingly good to have a bank of time, creating one difficulty that fits most.

Although we already had started making levels for Booh I wanted to brainstorm some more ideas for future levels, or ways to rework current levels. An easy way to do this was to create blueprints!I didn't use these as hard guidelines for our blockouts but rather as inspiration for what things could be interesting or cool. We were also of course limited by unity in some places, for example overhangs and caves proved quite difficult.Overall if I had another 3 weeks to work on this game, adding in many of these blueprint ideas would have been my next step.

When working on the movement I wanted to test is thoroughly, this meant creating a simple mockup level, that later became the tutorial level for the game.I knew pretty early on we'd use this as a tutorial level, with such short projects you can't afford to scrap too many things.I tried my best to make sure each mechanic was introduced one at a time. It's rather difficult however because of how fast the game plays and starts. The game is built on action and tension, and a tutorial of tension is hard to pull off.

Here is the final version of the tutorial level, and once again amazing work by the artists. The way they made my tutorial messages look interesting and nice is truly amazing. The level introduces the player to all the gameplay mechanics in about 30 seconds. That's a lot of information. Luckily it worked out fine. It forces the player to learn the base minimum, and as they continue through the game they continue to learn. Failing isn't a bad thing, but rather a stepping stone to learning.From the numerous playtests I held I saw players of all skill levels, and I'm quite proud when I say that in the final version I haven't seen anyone fail the first 10-30 seconds of the game. This of course was after multiple redesigns. For example getting people to understand the ground pound is still something difficult even in the final version. However with the resources and time we had I think the tutorial and rest of the level play just fine, and introduce the player to most of the gameplay components quickly.If I went back to redo this tutorial I would spread things out more, introduce killing enemies for time earlier, while giving the player natural stops in the level to read tutorial prompts from a distance while running towards their next goal or obstacle.

Level 3 was the second level I was set out to work on. Once the movement was to a degree reaching it's final levels we wanted a level that showcased some of the momentum gaining mechanics.Originally this was going to be a very open level, with a large expanse the player had to race through quickly to get to more enemies. However this got cut due to time restrictions. I fought pretty hard to keep this in the game, but I also understand why it got cut.The level has two "identities", something I try my best to include for all my levels. An "identity" is something that defines the level, something that people can refence in conversation. "The level with X." This one has two massive walls that the player can wallrun in-between, as well as an infinity loop that makes the player go under where they were previously.

The final version of the level has this hellish almost burning feeling to it. Once again the artists outdid themselves.The loop that connects upon itself was quite tricky to get to work. However eventually we landed on some sort of destroyed road/building combination. I had to fix this section at least a dozen times because of all the little holes or small issues that allowed the player to get lost/skip a large section of the level. Now skips are cool, but skips that the average first time player stumble into and then get confused about aren't. So finding the right balance there was tricky.The wallrun section also had a lot more added to it. Obstacles in the way, certain sections of the wall that the player couldn't run on, enemy placements so they don't run out of time, and multiple paths, allowing players of all skill levels to enjoy the wall running section.

This project was the first where I felt like we had a lot of time to debug and test and polish everything.During the final weeks of the project I went through my two levels and started looking for any collision that might be out of place. I found quite a few spots where there were left over invisible objects with collision. I think the funniest thing I found while testing level one was an enemy that instead of getting deleted had it's model deleted, creating an invisible enemy that would just keep damaging you throughout the whole level.Something that I also didn't talk much about here is the nav mesh. It's not really something terribly interesting. However the final weeks of the project I sat a lot the nav mesh for the AI. Placing exclusion zones to reduce it's size, as well as making sure the AI doesn't try walking somewhere where it shouldn't.This part of the project was a return to form for me from all my QA work, but it's always beneficial to keep practicing and improving.

The Grand Forest of Mefor took me about 10 hours to make. It is where the Road Wardens campaign is set, inspired by the Roadwarden video game.This forest lies between the cities of Mefield and Arespolus, the two grand cities of Repoluv. As such the road connecting the cities is not only important to keep save, but dangerous. From monsters to bandits to magical events from the forest, Mefor holds many mysteries and dangers.When making this map I wanted to give the forest biomes, still connected to the forest and road theme, but with interesting locations to explore, where those locations have thier own rules, and ecosystems, such as the pale forest (the white trees) and the grand planes (the fields to the south east).

The Road To Illegend map was the first map I made using Dungeon Drafts hexgrid system. I think it came out looking quite well for a first map.This map offers some locations for the party to go towards with the main goal being the grand city if Illegend, a city built ontop of a dungeon that seems to come back no matter how many times people clear it out.The bridge serves as a natural half way point, in this regional map, the cave in the middle of the map housing a fire troll, that serves as an optional boss.Each village here has a trouble. The logging camp for example has a warewolf problem, which can be quite dangerous to a party if they aren't ready, especially considering non silvered weapons aren't as effective.Illegend serves as the main questing location for this regional map, with multiple quests within the heart of the city, and the dungeon within. From political plots, to a potion maker trying to start up her shop again.

More to be added!

Goblins aren't typically seen as the most threatening, but put about 15 of them and a hobgoblin captain in a well defended position that's hard to ambush, and you have a difficult encounter on hand. This map is called the goblin campsite, a temporary camp that the goblins chose thanks to the natural shelter and advantage position that the cliffside here has. Archers can look over the cliffside during the day while during the night the cliff prevents fast attacks from the south. Goblins resting bellow have cover from the wind.We can see that the goblins have been stealing here. The cart tracks give a hint to the party and a way for them to find the encampment.Even just adding one cliff can create interesting combat, where to attack from becomes a huge question, and the decision has large consequences.

This map I have named forest blueberries, it's not that special, but that's the point!This is one of those maps I throw on whenever the party runs into a random encounter in the forest, and I need a map for it. It offers some high and low ground spots. Trees and rocks that create lines of sight that can be used during combat.

A cursed tree sits in the middle of a dark part of the forest. Heavy canopies cover the skies. A dead tree looms over the surroundings. A rusted sword, covered in dried up blood is stuck within the dead tree.This map was made specifically for a random encounter that I really liked, originally it was just a sword stuck to a tree, but I decided to make this map, spice up the sword, and make the tree it's stuck in cursed! If you draw the sword, the tree and the sword both come alive, and start trying to kill the party. The sword is chained to the tree, so although it is very fast and unable to take damage, running away is still very much so possible, if the party isn't ready to fight just yet.

More to added!

DnD already has a Cockatrice, so why did I decide to make another one? The regular one is small and I felt that didn't live up to what I know of them. Cockatrices are in folklore a type of dragon. I felt this was lost when they were translated to fifth edition, I wanted a monster that felt like a lesser dragon, so I changed the bite petrification into a type of breath weapon that petrifies instead, giving is a strong attack and weakness in one. If you cover your ears you make checks against the screetch at advantage. It also comes with a lot of interesting problem solving, since talking is the main way of communicating between players during DnD and if your character is covering their ears, how can they communicate with the rest of the party? Overall I'm really happy with this design, and I feel like it lives up to being a lesser dragon.

More to be added!

Nautlius is an under water submarine horror exploration game. I worked mostly on systems but I also designed one level for the game.I worked on a lot of things during this project, due to the small team and large concept I had to split my attention on multiple things, which forced me to get better at being flexible and work where I was needed.This game went through a lot of itterations, from having plans to be multiplayer, to plans to make it in VR; The games systems were changed a lot during development, what I'll showcase here is a mixture of all those systems, some finished and many others never implemented due to time restrictions.

I designed all the submarine systems in Nautilus, this mega flowchart shows every connection, of how each system interacts with itself and references to other systems.This is the final version of the systems, since they were changed later on to fit a singleplayer
experience better.I made this flowchart to help both myself and other designers understand my design philosophy behind the systems as well as making it easier for the programmers to understand what systems needed to interact with each other and the hierarchy of logic.

Here we can see a more in depth one system at a time logic tree. I designed the system so that each hazard in the game only affected one or two systems. This means that the player isn't overwhelmed with things to do if they run into a hazard.Lets take for example cold; Cold slows the submarine down, but doubles all damage done by crashing. This forces the player to be more careful, and navigate slowly.Electricity turns off all electrical systems and damages the fuze box if the system is online until it breaks, the player can hence make a choice, stop driving and turn off all their lights and useful tools, like sonar and external lights, or drive through with those systems damaging the fuze box, potentially breaking it and losing their electrical systems for a longer time.Each system is designed in a similar way, with a choice. The player as such is forced to make these choices constantly, with each hazard being designed around an emotion.

Hull damage is fear.
Heat is panic.
Cold is dread.
Fog is unease.These emotions sometimes overlap; Hazards can also be avoided, building tension. All to create a horror exploration feeling for the player.

I wrote most of the scannable texts for Nautilus and together with a programmer implemented them into the game. These are all built up with the idea of hinting towards the larger lore that another talented designer made. Together we created a whole world deep in the waters.The player interacts with these by scanning (pressing F) on certain interactable objects. Then a text to speech robot reads them out to the player. Some of these are also used to enforce the horror theme of Nautilus.My favourite line has to be: "Scanners unable to reach cavern end, opening too small for Nautilus. Captain... message deleted by Torsion Systems... Overridden... Godspeed Captain.We can see the implementation to the left here, with a bit of debug lines from when I was testing this.

I made some simple UI for Nautilus, focusing on function over form. I typically don't code much but whenever needed I try my best to fill the shoes of what needs to be done.This UI allowed us to play the game through the main menu, and later changed to a finalized version. It also allowed us to select which level we wanted to start playing in, which would allow people to test later levels in the game without needing to go through the whole game from the start which lowers the time to test.

I also made one level which I named the "Giants Pass" during development. This is the fourth and final level in the game and as such I designed it to be complex, challenging and trying to inspire a sense of awe.Multiple pillars need to be navigated around and with the cold debuff one crash could spell your doom. You then pass under the giant into a tunnel that twists and turns with heat in it forcing the submarine to accelerate, making the player have to maneuver quickly.It then splits into two pathways, each with a unique hazard, smoke on one side, electricity on the other, with the player having to choose what challenge they want to overcome. The tunnel then reconverges and narrows in before opening up for a grant reveal.

The final version of the level has a lot less pillars to give the player a better view of the giant holding up the cave, although I wish we had added more pillars for a larger challenge.I love the new pose the giant has. The lava replacing heat zones also adds so much to the caves below, and the grand reveal with all the statues really makes this level look amazing.I'm really happy to have designed this and what the artists turned it into.

Technomania is a first person rapid looter shooter. This was my second game project at PlaygroundSquad and I feel like I have so much to talk about.You play as a war robot that has broken free and is now on a rampaging killing spree through the same facility that made it.This game uses procedurally generated weapons, that heal the player when they are picked up, you can't reload, meaning you are constantly swapping weapons.
Below you can read more about the decisions I made, and what I contributed to this project.

The first level I made was the Tutorial Level. This level explains the first mechanics available to the player. Such as how to walk around, shoot and loot.I designed this level with a theme in mind. Trying to set the mood and the story of something that has gone wrong. Through visual story telling and the artists that later dressed the scene I feel like we really accomplished this.The vents in the scene force the player to crouch, and the half closed door force the player to jump. This makes the player learn without us forcing them to see which buttons to press unless they get stuck.The level is made in such a way to prevent the player from being passive when it comes to combat, they are forced out of a choke point, and need to take the fight to the enemies, which enforces an aggressive playstyle which through playtests we noticed made the players enjoy themselves more with the game.

The second level I made was the crane level, in the images you can see the before and after from when the artists did the dressup for the level.This level was designed with multiple waves of enemies in mind, an arena for the player to play around in for a couple rounds before moving to the next zone. As such I put in a bunch of pathways, both up and down in an attempt to make the player explore their movement options.After the artists dressed the level a lot of these pathways disappeared and I highly disagreed with this decision on their part. The level was designed vertically and a lot of that verticality and “playground” feeling went away after the changes.

Originally meant to be an extension of the tutorial level, the "Science" level later became its own project.This level was designed with the player's dash in mind, as such you can see many large empty gaps in the level here, that force the player to jump, double jump, or jump and dash across.There is also a bonus area with 2 weapon crates at the end of a very long tunnel that makes the player have to combine all of their movement to reach, performing a slide, jump, dash, double jump into wall jump allows the player to reach this bonus area, rewarding their skill.This level was never dressed and as such isn't in the final version of the game which is a shame since this level teaches new players more about how the movement in Technomania complements its gunplay.

I helped with a lot of the movement for Technomania, most of this was testing, commenting and trying things out in a default scene such as the one in the image here.The movement for Technomania is easy to use yet the deeper you go the more you can master it.You of course have your regular WASD movement, a crouch that if you are moving fast enough becomes a slide. A sprint which makes you go slightly faster. A jump and an air double jump. You can also wall jump for another extra movement option.We were also testing wallrunning at one point in the game's development but later removed it since it proved to be too strong of a movement option for the player, allowing them to skip large sections of levels and enemies. Many of our levels at that point were not designed in a way that made the wallrun feel good to use.

Here we can see the navmesh that the humanoid enemies use in Technomnia. I was the one assigned to edit this navmesh and make it function.Although Unreal Engine 5 has a solid auto generation tool for the nav mesh there are also plenty of spots we don't want enemies wandering to, as well as wanting to force them in certain directions, as such I was editing a lot of this manually and double checking where enemies walked to ensure enemies wouldn't go "hide" in corners.

We originally only had humanoid enemies which use the same procedural guns as the player, with plans of making a complex bossfight towards the end of the game. This proved to be too expensive for the team time wise.So we came up with a clever solution on how to add more enemies without adding a lot more development time. Turrets and Drones!These proved cheaper to design, test, model and program while also adding a lot more variety to the game.

I was tasked with finding a solution to having multiple levels in Technomania. I wanted a way to make it feel seemless since this is a high action game and being taken out of the action for too long might hurt the players experience.So I designed, and implemented these airlocks into the game with the help of a programmer. When the player steps into them, they lock behind the player, then load the next level ahead of them. The player can still move around while in the airlock and once the new level is loaded, it unloads the old one and opens the airlock!This made me have to put in all the levels into one master level and place them next to one another, with airlocks connecting them all, although this took some time (mainly due to my poor computers GPU) I feel like the final product was more than worth it.

Although this is the last in order of this page, making the asset list was actually the first thing I did before I started designing levels. This was so that the artists wouldn't need to make 1000 different assets, textures and models for each different wall.So I created a simple list of all the assets we needed in the game and placed their models in one scene for the artists to later texture or redo in their own style.This I believe saved us a lot of hours of work and allowed us to have multiple highly detailed levels in a project that was less than 3 months long.

Black Gold was my first project at PlaygroundSquad.We used a scrappy in-house engine to work on the game,and if we hadn't I don't think I would have found my love for systems design.Black Gold is a strategy city builder, with inspirations from games like Frostpunk and Surviving Mars.I worked on Systems Design for this project, creating the balancing around the core gameplay loop, as well as reworking many parts of the core loop. I also rebalanced many of the events in the game, and even made some of them myself.

Since we were making a strategy game the first thing I got started on was making a flowchart graph of how the player would go about gaining resources.This flowchart showcases what buildings the player starts with, what resources they gain from those buildings, and how those resources lead into new buildings that then lead into new or more resources.The flowchart helped other designers as well as programmers to understand how the internal logic of the game worked, as well as helped me draft ideas of how the progression should work in the game, and when the player got access to new buildings and resources.

During development I helped work on the research tree which we can see the final version in the image here.This graph used to only have 3 tech tree's but I later reworked it to have 4 on account of the boats becoming a more complex part of the game. With the "Arch" being one of the ways to finish and win the game if the player built it.This simple technology tree was surprisingly complex to make, figuring out how to make it easy for the player to understand without making the game feel boring or too easy was a delicate balancing act.

Ah my beautiful insanity, here we can see some spreadsheets and data tables that I created during the development progress of Black Gold. We were using an in house engine which meant even getting simple code or textures into the game took a while. As such I found myself recreating the game in google sheets since it was a strategy game.I could create all the costs, resources, and how much the player would have each minute in a rough estimate. I remember myself "playing" the game in this cursed yet amazing simulation.This is where I ran by most of the balancing of the game and how I designed Black Gold to fit the game philosophy we had of creating a real time strategy game that would be played between 20-40 minutes.Overall Black Gold was an amazing introduction to PSQ and this game will always hold a special place for me since I found Systems Design through Black Gold.

This project was a one month process of ad-hoc bug testing and running test scenarios throughought the whole game. Working together with a team of three other interns and the developers to fix and improve the Nightmare update for the game.I helped out by playing through the whole game, sending in bug reports and feedback to the devs and then retesting those same things once they had been changed.

I did this project while working for Northify, a QA company based in Boden. I learned a lot of useful skills while working for them for 6 months, and working for Budget Cuts was my largest contribution during this time.I remember being to proud and excited when I saw my name in the credits after they released the nightmare update.

We used Jira during this project, and although I can't show any screenshots since we were under NDA while working for Budget Cuts and I no longer work for Northify I feel that it's relevant for me to talk a bit about what I learned.We used a typical Scrum board, with tasks aligned into different priorities. This helped us know what issues, levels and parts of the game were the most important to test.Overall I like this workflow, it's easy to understand and efficient, and speeds up communication between everyone working in the team without needing more than daily standup for meetings. Which was especially useful due to our limited 4 week time on the project.

This was my third and final game project at Futuregames. I worked as head of QA focusing on quality of level design and audio as well as player movement. I worked closely to fine tune how enemies interact with the map and how the player moves around it. Researching thoroughly on grappling mechanics in other games to make sure it felt just as good in Ecoside.

Soil mates was my second game project at Futuregames. Here I helped test the game as well as discuss many of the core design decicions with the other designers.
I held a game test where I asked players questions and watched how they experienced the game on their own. Only giving them help when absolutely stuck.

• Return