Hey! I am Antonio, a game design student from Chile, currently operating from Sweden.
Through my interest in Systems and technical knowledge, I strive to create a game that excites through genuine emotion and interaction.
Nothing excites me more than the possibility of a new experience.
Education Projects
M0THER
Lead, Systems & Technical Designer
Puzzle game about guiding cute creatures through a deadly lab
TECHNOMANIA
Systems & Technical Design
Frantic looter shooter with procedurally generated weapons
Black Gold
Lead, Systems & Narrative Design
Atmospheric management game about operating a deep sea rig,
with an eldritch twist
Jams & Other Projects
Materia
Cozy space simulation
Master Of Mana
Domino fueled card game
Shotgun Argot
Eerie arcade shooter
M0THER is a dark but charming puzzle game about a supercomputer guiding packs of stupid creatures through a deadly testing facility
WARNING: Images down below contain some stylized images of blood and gore
Genre: Puzzle
Platform: PC
Engine: Godot
Duration: 9 Weeks
Team: 10 people
Role: Lead/Technical, Systems and Level Design
Summary
M0THER is a chamber-based puzzle game, where the player must guide cute little creatures through a lab filled with scary traps. They must open and close doors to guide the silly critters, give the creatures modifications to allow them to bypass danger, and try to predict the tricky layouts of the dangerous levels.The one line pitch is: What if GLaDOS was playing Lemmings?
My Work in M0THER
With M0THER being my original idea, and being the lead, I was in charge of most of the gameplay design for the game. This meant finding what exact actions the player would have access to, and how they would interact with each other.For me, the three pillars of the gameplay were:
The Creatures: Cute, lovable, but very stupid. The goal is to get them out of the facility. Their idiocy needs to be as charming as it is annoying.
Traps & modifications: The interactions between the different abilities that the player can give the creatures, and the level hazards is the driving force of the puzzles and levels.
The Cameras: Since the player is a supercomputer without a physical body, they can only see the level from the fixed point of the security cameras. This adds to the challenge, but also immerses the player in the game's fantasy.
Below are breakdowns on how each of these were approached
The Creatures
The creature behaviour was one of the hardest parts of the game to nail down.My initial directive was:
The creatures walk in a direction until they collide
When they collide, they turn right, unless there is an obstacle in that direction
They do not avoid any traps or danger. They just walk into it.
This, while very simple on paper, turned out to be quite a challenge when taking into account that the levels had a variety of sizes and shapesThe way we achieved it was:
Tweaking and refining the numbers: There are a huge variety of different variables that affect the creatures' behaviour,and it took a lot of testing and iteration to get the right combination of numbers for most situations.
Behaviour modifiers: We came up with a trigger zone that changed some of the numbers for behaviour of creatures that entered it, so the behaviour could be adjusted by the level designer for areas with special layouts
TESTING: I ran a huge amount of testing on the creatures, both for the elements above, but also to hunt for bugs and edge cases that popped up.
In engine depiction of the creature and raycasts
Interactions & Modifications
I designed and mapped out the interactions between level features, traps and modifications, pushing for this new focus of the gameplay, and created a variety of both traps and modifications focusing primarily on:
Variety: No modification should be just an answer to a single trap, and viceversa
Surprise Factor: The player should not always know exactly where and how a gameplay interaction works from a single glance. There should be some space for the unexpected
Fantasy: The traps and modifications should be fun to look at, and must delight the player whenever activated
I also did direct implementation work on traps in conjunction with the programmers, such as:
Creating some of the activation and deactivation animations for the crusher and shredder
Implementing the base functionality for some traps, such as the shredder and the drainhole. The rest were the work of our great programmer, Love.
Tuning the sizes of deathboxes and hitboxes to iron out inconsistencies
Two of the fan favourite modifications:
Balloonify allows the creature to fly whimisically
Blockerify allows the creature to act like a wall
Camera Controller
In M0THER, the player can only see from the fixed POV of security cameras. They also cannot move, and must instead jump from camera to camera.A lot of thought and iteration was put into the controller, making sure it was intuitive to the player, and tutorializing the areas where it wasn't to the best of our ability.Some of my contributions to the controller were:
I iterated on the keybinds for the core actions, taking in feedback from repeated playtests to improve the flow. This repeated iteration led to the locked mouse camera movement, and the modification wheel
Worked with Linus, the camera programmer, to tweak the transition shader and speed, to improve player orientation
Helped with the implementation of the modification wheel, and debugged issues related to modification selection and application
HUD
During the second half of the project, I did a large amount of work on the HUD, going through an iterative process both in terms of aesthetics and functionality with the aim of making it aesthetically pleasing, evocative, responsive, and highly readable.Some of my additions to the HUD were:
Creating and implementing the various indicators, such as creature count, amount required to complete the level, and the creature death messages
Creating the startup animation, and implementing it across the various different UI elements that make up the HUD. This meant having both a long, full fledged version the first time the player opens the level, and a shorter one for when they replay it.
Creating animations, and implementing both visual and audio feedback when the UI elements were updated
Level Designs
With the team having only two designers, I also had to take on level design duties. My aim was to create levels that would motivate the player to explore the various options and interactions available to them through the modifications, while keeping a certain comical level of surprise by trying to catch them off-guard with some unexpected interactions.
Ideation
Coming up with a strong fantasy or idea for the levels was vital to my specific process. For this, I looked at some of my main references throughout the project, mainly Portal and Lemmings, to find interesting ways of presenting ideas, and cool scenarios to put in front of the player.With many of my concepts, I was looking for the comedic and playful aspect of the game, by thinking of beats that could surprise the player in a funny way, or put them in a fantastical situation, where the charm of the creatures and the systems could shine.
Blockouts
After nailing an idea, and very often having drawn a paper mockup of it, I made a blockout using Godot's Gridmap feature, which allows for extremely fast and flexible building of the shapes of the level.During this process, it was vital to also test out the different camera perspectives and tweak the level accordingly, so as to have the level not feel cramped or for the scale feel out of place.
Testing and iteration
After the inital blockout was done, I tried and tested everything myself first, to see that the level worked, then tried out the various interactions that were key to the level and tweaked anything that didn't fit or work.After this, I showed it to my co-designer, Philip, who usually gave some feedback that I implemented before showing the rest of the team, who would have more feedback to improve it.Once it was determined the level worked on a base level, the environment artists began work on it while external playtests generally allowed me to sand down the smaller imperfections.
Levels Produced
Doors Level
Gauntlet Level
Race Level
End Level
Learnings
M0THER started out a little rough, as it took us the first couple of weeks to find what the game was and how exactly it should play, but as we iterated and found our footing, it really became somewhat of a charmed development. From this, I learned many new things, as with our momentum, we got to do many things that I hadn't been able to in previous projects.
The game is not only made of big, impactful, flashy features and moments. Small sounds, interactions, HUD feedback, and the overall "juice" of the game, is where things often come together for real
This is kind of obvious in retrospect, but having an entire team, not just designers or a select group of people share the vision, and be able to feed the game concept with their own ideas changes the process entirely.
The game not being where you want it to be is not a death sentence, but a problem to solve, and this is not a bad thing, as long as you keep your cool. No game is instantly perfect, and dealing with this is just a part of the development process.
Genre: Looter Shooter
Platform: PlayStation 5 & PC
Engine: Unreal Engine 5
Duration: 9 Weeks
Team: 18 people
Role: Systems/Technical Designer
TECHNOMANIA is a chaotic First Person Looter Shooter, where you play as a killer robot that’s gone rogue inside of a huge weapons R&D facility.
My work in Technomania
I was in charge of the weapons for Technomania both in the design and implementation side. This meant creating a modular weapon system where the guns would be created from combinations of modules which created meaningfully different gameplay experiences from weapon to weapon.This involved working hand in hand with both artists and programmers to ensure that the weapons were functional, but also provided the players with strong visual and auditory feedback to create a memorable sensory experience.This process involved extensive testing and tweaking, to ensure that all weapon combinations work, but also provide the feeling we were looking for, where the player is constantly going from weapon to weapon, and each new pickup comes with excitement of not knowing what will happen when you press the trigger.
The Weapon System
Modular weapons were part of the core of Technomania, as the unpredictability and variance are the fuel to the game's manic looting and shooting cycle. Because of this and the technical complexity of such a system, its design and the implementation of the weapons took most of my time during the 9 weeks of the project.At its' core, the system is based on the idea of separating the operation of the weapons from the type of shot that they fire. With 9 different modes of fire and 5 different types of shot, this creates a huge amount of possible combinations, which when taking the many different variants of each of them, makes for an almost infinite amount of different weapons.
Weapon Generation
Weapons are created from up to 4 main component types, which define different aspects of how the weapon works, both in function and aesthetics. These components are:
Weapon Body: Defines the mode of fire, recoil, hand positions and operation VFX (charge effects, bullet casings, etc.)
Barrel: Defines the shot type, weapon crosshair, and shooting related VFX, sound and animations.
Magazine: Defines the amount of bullets the weapons spawns with
Stock: Initially defined the weapons' handling stat. After moving this to the body, the stock became a purely aesthetic component, due to time and technical constraints.
This also allowed us to create different weapon shapes by having a very short barrel and no stock to create a pistol, or having a particularly large and heavy barrel to make it more of a shotgun. Additionally, these weapons can spawn with special attachments such as scopes, who although initially had functionality that was cut due to time constraints, help the weapons have more variety in feel and look.
Modes of Fire
There are 9 modes of fire in the game, which resulted from the combination of two different elements, the "charger", which is how the player loads the weapon, and the firing class, which is how it delivers the shot when operated.
The charger types are:
Normal: The weapon is activated when the player presses the Fire button
Threshold Charger: The player must hold the Fire button to add charge to the weapon, and when charge reaches the maximum value, the weapon is activated (an example would be a minigun, which needs to wind up before shooting)
Charge-Up: The player can hold the Fire button to add charge to the weapon, up to a maximum. When released, the weapon is activated, and the shot is boosted depending on the charge amount
The Firing classes are:
Semi-Auto: When activated, the weapon fires a single shot
Burst: When activated, the weapon fires a volley of shots a single time
Automatic: While activated, the weapon shoots repeatedly every short interval
Constant: While activated, the weapon shoots a constant stream (mostly used for laser weapons)
These elements are not all compatible with each other for example a threshold, or "minigun style" weapon, cannot be semi-auto or burst, as it requires something to be shooting constantly while held, but after ruling out some, I reached 9 combinationsApart from the functional combinations, each weapon has a variety of stats that can change the feel and function of the weapon, such as
While the stats are not always used depending on the weapon, they allow for a very large variety of interactions between bodies and barrels, making combinations that can be both hugely powerful and extremely weak.
Shot Types
The second main element of the weapon generation, shot types refer to what the weapon shoots when activated. A core part of the vision of the system was to reflect the experimental nature of the weapons to an almost comical degree to create flashy and exciting weapons.The main challenge in designing this part was the tension between wanting a lot of variety and space for more "out-there" concepts for weapons and the production reality of us only being able to achieve a limited amount of things in the short amount of time we had. This was much more noticeable when making the shot types, as they are more VFX intensive, and often require different models between them.The game has 6 shot types total, chosen to create interesting and novel combinations with the modes of fire. These are:
Bullet: The traditional bullet based weapon
Shotgun: Shoots many pellets scattered in a cone
Grenade: Launches a small explosive projectile that detonates on impact
Scatter Grenade: Shoots many grenades in a horizontal cone
Laser: Shoots a concentrated beam that deals damage constantly to targets. Can only be used with constant modes of fire.
Pulse: Shoots a powerful pulse of energy that also has a small blast area on impact
As with the modes of fire, each of these have a set of stats that can be changed to create a large set of variations.
The explosive modifier in particular creates a really different gameplay experience with relatively small effort, creating some of the game's most exciting moments.
Here are some examples of weapons that share either shot types or modes of fire, but provide significantly different gameplay experiences to the player thanks to the differences in stats and combinations
Implementation
Apart from designing the systems for weapon generation, I was in charge of the implementation of the components' functionality. I worked with Unreal Blueprints to create all functionality related to the weapon operation, including making them work with the AI, adding all visual and audio feedback for the shooting, and having the weapons' work with the stats pulled from data tables.
The base systems were built in C++ by programmers, creating a weapon base component class that acted as root of the weapon. This base object pulls data from data tables to generate the components and give them the stats. These component classes are created in Blueprints by me and contain the functionality needed for the modules to create a unique operating weapon.The body and barrel blueprint components have custom functions for damage calculations, recoil numbers, and all the visual and audio feedback. All of the stats and assets such as sounds, VFX and gun part meshes used can be easily changed and tweaked in the data tables themselves without need for further implementation.
Blueprint Samples
As the functionality required for the components was quite large, especially in the shot types, which were larger due to needing more calculations, checking the objects hit, as well as more visual and auditory feedback, I made a lot of use of the Blueprints node collapses to keep everything visually tidy and de-cluttered, making very large blueprints into a collection of much more manageable nested compartments.I chose collapses instead of making separate functions due to a lot of the shooting function using a many local variables through it's entire length, which I found a bit cumbersome to send back and forth between functions, and due to most of the logic not being repeated elsewhere in the class, thus not justifying the use of a macro either.
Learnings
Over the course of the project, I feel like I really came into myself both in terms of systems design and technical expertise. This project really pushed me to expand my limits, and ask for feedback to improve my craft in a whole new way.
I also got a lot more hands-on practice with coordinating with working on a feature team setting, and having to communicate with people of different disciplines on a more technical, hands-on level.
Lastly, I learned a lot of valuable things about working under a tight schedule and dealing with pressure. The game's scope was tight, and I worked really hard, but I strove to work efficiently and not burn myself out. I really felt my success on that point when, after finishing the game, I felt more motivated to make games than before, even making a prototype over the holidays.
Genre: Survival Citybuilder
Platform: PlayStation 5
Engine: In-house Engine
Duration: 6 Weeks
Team: 12 people
Role: Lead/ Systems & Narrative Design
Due to having been made in a proprietary in-house engine, with a focus on PlayStation 5, the game is not available to share at the moment
Black Gold is an atmospheric worker management game about building and operating an offshore rig. As you grow your facility and manage your workers' tasks, optimising processes and growing your operations, strange happenings begin to occur, and you will begin to learn about the dangers of the depths.
My work in Black Gold
A core part of my role in Black Gold was being the owner of the idea, and team lead. Having initially pitched the game, I had a strong vision for a city builder/resource management game with a high intense pace and a heavy, dark industrial vibe with eldritch horror undertones. I was heavily inspired by Frostpunk, but wanted to create a more stressful, intense experience from the pacing of the game, inspired from RTS gameplay, where APM and efficiency are key.During the development, I did a lot of the broad system designs, laying out how the buildings & events would work, which resources the player could work with, how to get them, and did some support work and a lot of testing on the numbers and tweaking side. Additionally, I wrote and balanced a majority of the events in the game, as well as doing the narrative design for the overarching narrative, and created UI mockups for artists and programmers to work off.
Teamwork & Engine
This project was my first large group project, and I had the privilege to work with an extremely positive, nice, and talented group, but as my first time leading such a team, I did a lot of communication work, and learned a lot as we went along about communicating efficiently, having team discussions stay focused on the goal, and be clear about our objectives & opinions.Additionally, this was my first time working on the school's proprietary engine, and working with the PlayStation 5. This also came with a lot of new constraints to adapt to, as the engine is much less opinionated and has significantly less features than the ones I had been using before.This led us to lean much more on each other, especially on programmers, as many of the common features, such as UI or data management tools were not part of the engine by default and had to be made, but this also allowed us to make things custom made to the exact way we needed them to be when communication was effective and we worked as a team.
Gameplay & Systems
I started from the initial concept for a strongly atmospheric game, inspired by images of towering, rusty oil rigs in the middle of a stormy ocean, a heavy industrial monolith isolated and enshrouded by the fog, at the mercy of the elements.This led to the idea of making something in the lines of Frostpunk, combining the management and growth aspects with the desperate fight against the elements, but with mysterious eldritch horrors of the depths as the threat.From that core gameplay concept which I pitched, I worked with the team to create a consistent vision of the gameplay that creates a stressful, oppressive feeling. To do this, we strove to create a fast-paced rhythm, where operation and timings were an important factor to success, keeping players busy at all times.
Defining the buildings: I did real world oil rig research, but also looking into different resources that could plausibly fit within the fantasy of the game, and what kinds of buildings might produce them, creating the economy of the game.This also meant working with artists and programmers to get visual concepts, and build the architecture of the systems.
Designing the event system: I worked to create a framework for random narrative events with gameplay choices and consequences, how they deliver narrative, but also a progression system, where during the course of the game the stakes and drama of the events would scale. This also included a set of main narrative events, which would tell an overarching story for the game, including the climax, which would be the ending of the game
Controller & movement: Another of the distinctive features of the game was our focus on targeting console. This required us to make a variety of adaptations from the standard uses, such as having to make a character marker that the player must move around the map for selection and building. I tested and tried out many different layouts, and worked and in hand to make the navigation on the hex map work smoothly and consistently.
Narrative & Events
Another strong part of the vision for the game was a strong narrative element that would force the player into hard but interesting decision making scenarios, both from the narrative and management aspects. This required a lot of writing and editing, working hard to ensure a correct tone and difficulty.Curating the narrative theme and atmosphere of the game was hard, having to constantly proofread, edit, and even cut events. In the end, over 60 events were written and created for the game. Some features designed for these events are:
A weather system, where different conditions would have different chances for an event to occur, tying the visual mood of the game to the gameplay
A danger system, which makes the events become harder and more dramatic as the game progresses
Narrative lines, where events could add new events to the pool of events, so that they may show up in the future, creating narrative progression, and also a new way to reward/punish the player's decisions. This system was used to create the overarching narrative, as there was a core line of events that upon completion would spawn the next chapter of the story, leading to the ending,
Learnings
Black Gold was an incredibly challenging experience for me, as my first time leading a game team, or even working in one. I learned a lot of valuable lessons about design, iteration, production and working with other disciplines, especially artists, as I was very unacquainted with the technical aspects of that area. Many of the things we as a team worked on could not make it into the product due to scope, and this is a lesson I keep very much in mind.I also got the privilege of working with a super nice group of people, and learned a lot from them about feedback, clarity and communication. In a project where I could not necessarily implement or prototype myself, not knowing the engine or the programming language, communicating effectively was vital to get the game across the line, and to make sure the design was clear and properly executed.
Master of Mana is a tabletop inspired strategy game, where you have to wield mana through powerful rune dominos to defeat your opponent in an epic duel. Beat everyone who stands in your path and become the ultimate wizard!The game was made in a month by a team of two for the BOSS RUSH JAM 2024.
Genre: Strategy/Card Game
Engine: Godot
Duration: 4 Weeks
Team: 2 People
Role: Designer/2D Artist
The theme for the jam, apart from the starting premise of making a Boss Rush game, was "Exchange". We initially went through an ideation process, coming to the domino and card concept as we thought it would make for a good combination of interesting for us, feasible, and unique in comparison to other games in the jam.
During the development, I:
Designed and tested all the cards
Designed the enemy bosses, and created the narrative around them
Designed and implemented the narrative segments and the UI
Created the art for all the cards, the table, and the three bosses
Learnings
I learned a lot of technical and project management best practices from my teammate, who was more experienced in matters of development
This being a sort of unique game, I really felt that we should have put some more focus on the tutorial, as many people struggled to get how to play, and have tried to do so going forward
This was the first time I worked with someone else on a videogame, and I feel that this was the point where I really fell in love with development. I am still very proud of this game, and think we worked super well on it.
Shotgun Argot
Genre: Arcade Shooter
Engine: Godot
Duration: 1 Week
Team: Just me
Gameplay Video
Shotgun Argot was a solo jam project made for the Acerola Jam 0.
It's an atmospheric arcade game where the player has to rotate shotguns that shoot automatically around them to defeat enemies.I made everything from scratch, including art, sound and code, over the course of a week.
During Development, I:
Designed and implemented movement, combat, enemies, animations, and progression
Created the art and animations, as well as editing sound effects & music
Even reached the stretch goal of having an endless mode in the game!
Learnings
This project really tested my technical skills, and I came out the other side much more confident, but also with a lot more knowledge of coding and technical research
I also got to hone some of my art skills, and general sense of aesthetics, to create a moody, tuned experience
Looking back, I feel that I managed to accomplish a lot with this game, especially considering the extremely short time frame.
Antonio Giaretti Escobar
Game Designer
Materia is a galaxy sandbox prototype I made as my first Personal Project in PlaygroundSquad. It's a mini galaxy editor with a zen atmosphere, where the player can create their small corner of the universe
Genre: Sandbox Simulation
Engine: Unreal Engine 5
Duration: 5 Weeks
Team: Just Me
The Development
My goal with Materia was to create a fully player-led interactive experience. This was in equal part a design challenge and a technical one for me, and I pushed myself to create a satisfactory sensorial experience for the player, while broadening my technical knowledge of Unreal Blueprints.
Through research and testing, I designed and implemented a set of features that the player could use to create their galaxy. This includes editing their orbits, speeds, colors, and their shapes.
In parallel, I also ran through various iterations of UI, compartmentalizing it as the feature set grew to make sure each sub menu was easily readable.
I also created a camera system that allows the player to alternate between free floating camera movement, and locking onto planets for better inspections and a more striking, cinematic view of the galaxy.
Lastly, I implemented sounds and music, focusing on creating mood and tone, and trying to give more weight to the UI interaction.
Designing this game was a pretty novel challenge, as I had never worked on an experience with no inherent goal before. Making sure that the game was interesting enough and satisfying enough to at least motivate the player to mess around with it for a little while took a good couple of rounds of playtesting by fellow classmates, and a lot of the features and direction of the game was influenced by these sessions.These changes included somewhat major features, such as being able to change the color and shapes of the planets, as well as the whole name system, where planets are named, and the player can change these names at will.
The experiential component of the game was also very important to get right for me. Creating a cozy and relaxing experience, but retaining the grand scope and gravitas of the idea of creating a galaxy took a couple of tries, and searching for the right music and sounds to get the feel right involved a lot of testing, swapping songs and sounds around, testing again, and so on.
In the end, with the help of a tremendous sound pack, I managed to get a vibe that I was really satisfied with, and that set the mood for the player to have a really meditative experience with the game.
Learnings
This project really allowed me to broaden my skillset, as I hadn't really worked in a full UI based game this directly before, and I got a lot of valuable experience getting UI to be readable and satisfactory to interact with
I also had to learn a lot of the particularities of Unreal Engine, as I had to solve a variety of build issues, such as the component of the planet not rendering on build, or the system I was using for splines not showing either. This forced me to do some quick but thorough research, and retool many important features in the days coming up to the project end
As mentioned above, I also got many insights into searching for the "juice" and the player satisfaction in the games' interactions.
Antonio Giaretti Escobar
Game Designer
About Me
Hello! I am Antonio, a game designer from Chile, currently in a land far far away. I have dedicated my last 10 years or so to learning and working in different creative fields, having studied Film & Television at Universidad de Chile, and most recently coming over to Sweden to study Game Design at PlaygroundSquad in 2024.
This is not me
This is Manchas, my dog, who I miss dearly
This is me doing some hardcore gaming
I started out in games as a bedroom solo dev, making small games for the love of it, and participating in game jams. From this I still carry the passion for learning all aspects of development, and iterating quickly.My favorite game is Magic: The Gathering, where I love creating my own brews from cards that inspire me. Some of my other favorites include: Journey (my favorite videogame), Darkest Dungeon, the GameBoy Fire Emblem games, and Super Smash Bros, although if you ask me tomorrow this list might be different.
I love working on games where systems, mechanics, and aesthetics come together to create a small, contained universe of possibilities for the player, and gives them the chance to play around in this framework. I look forward to the delight of players doing something I didn't know was possible in a game I made, or seeing a combination of options that I had never thought of before to overcome a challenge.