Jan David Cemí Medina de Jesús

Hello world, I'm a video game programmer currently studying video game design at Atlantic University. I specialize in creating the base systems for games. As a hobby I also enjoy creating both 2D and 3D art. I have experience with game engines such as Unreal Engine, Godot and Gamemaker; have worked with with the following programming languages: C++, Lua, Python, PHP, SQL, HTML & CSS and have experience with other software which includes Maya, Blender, Illustrator and Photoshop.

• GitHub
• Email
• Phone

Programming

This is a collection of games, mechanics and small programs I've developed. Most of these are solo projects I developed for fun or for learning purposes.

• Programs

Models

This is a collection of 3D models I've worked on while studying or in my free time.

• Models

Illustrations

This is a collection of 2D drawings both digital and on paper. I don't specialize in art so this serves as an addition to my capabilities.

• Illustrations

• Gamepage

Madware is a game parodying old windows systems and it's adware viruses. Inside the game you have to defend against infinitely appearing windows by closing them. If left to accumulate past the in game systems ram bar you loose. The ads ramp up as the game progresses and as you get more points.

Backstory

When the competition was announced half our class grouped up and started spitballing ideas. We had about a week to work on the game, with a team of 5 people. Our first days were spent learning how to use Godot and how to organize ourselves; our last few days going straight designing the game. Of course, as all game developers do, we over-scoped quite a bit for the first idea, but we riled it in and focused on a smaller concept which won first place.

Application Windows

Windows are sprites which spawn with random texutes. These have two modes of interaction. One is grabbing and moving them around. The other is closing them with the very small red 'x' in the corner.

RAM consumption bar

The RAM consumption bar located at the bottom of your screen functionally acts as a death progress. This bar fills up based on how many windows are on screen, reaching 100% when the critical amount is hit. This helps the player know how close they are to death.

Random Spawning

The windows are randomly selected and spawned into the screen. These have a ramp up based on how high your score is and how much time has passed. At one point spawning so rapidly its impossible to keep up.

• Gamepage

Description here

Backstory

Backstory here

Mechanic i worked on 1

Mechanic description here

Mechanic i worked on 2

Mechanic description here

With our team fully set we now had the knowledge we’d be working on this game further than the previously allotted 3 month window. Development will now extend an extra 6 months, possibly more. This meant we needed to establish a better foundation on which the project will be set; Which required reorganizing ourselves, replacing older systems and fleshing out the game’s story and mechanics, past its skeleton.

Combat System Rework

One of our issues as we went further with our prototype was scalability, and accessibility. We we were finding it more difficult to create mechanics which could interface with our existing systems. A professor gave us a suggestion to look into Unreal’s Gameplay Ability System (thanks Everette). I took some time at the beginning of this development cycle to learn how it works and how to implement it. I used a couple resources to lean which includes the previously linked Gameplay Ability System docs in the Unreal Engine Documentation and video series by Ali Elzoheiry Gameplay Ability System (GAS) Course | UE5.

Gameplay Ability System

The gameplay ability system uses c++ code to implement its base functionalities. This was something I was dreading considering my previous experiences with Unreal’s C++, but surprisingly it was a lot easier with my current experience. GAS outright replaced the previous stats component and the options which fighters get in battle, removing burden away from the combat manager to handle.

The GAS system was first implemented outside of anything related to the game so as to not break anything immediately. This primitive version only includes turns, player attacks and basic stats.

When confirming that it worked the functionality was implemented fully into the base game.

All the skills, attacks and the parry are now abilities within the GAS system.

Damage Formula

The damage formula was put in c++ code. It’s still just health -= damage - defense but this was a slight hassle figuring out how to implement using the GAS system. Originally I had tried using the PreAttributeChange function to add the health that the sheild should've covered (which in hindsight sounds overly complicated). I ended up using the PreGameplayEffectExecute function instead, which allowed me to modify the damage directly.

This was probably my biggest problem with GAS, which ended up being resolved in less than 5 functional lines of code.

Turn Order

The turn order was tweaked slightly now using gameplay tags to determine turn, and turn related actions like skipping, or getting your turn blocked. Apart from that it mostly uses the same logic, basing who goes on which person has the most mana/speed ( these are the same thing ).

Camera Zoom

Slightly less critical the camera was worked on to give zoom in and out capabilities. These make the game feel (at least in my opinion) smoother and allow room for the artist's talent to be seen more up close.

Unrelated to Programming

Folder Structure

The structure of assets for the project (programming and art) was beginning to become a mess which led us to look for a solution. This led to an establishment of a style guide based on others which defines naming conventions and folder structures. I this style guide as a primary reference.

We also took this breather to flesh out the game more. This led to a more developed story and a few more mechanic ideas. This of course lead to updating the Game Design Document.

We now more frequently have meetings outside our obligatory meetings to update on progress and organize who’ll work on what.

To-do's

We still have quite a bit of things we're working on for the game. Programming wise here's a short list of what we'll be working on next:- Dynamic in battle camera
- Dialogue System
- Dynamic Enemy Combat AI
- Puzzle Mini games (light puzzle, sound puzzle)
- Inventory usage in combat
- GAS implementation of the weapon system

This is an explanation of the original prototype. Specifically breaking down the parts i worked on.

Combat Manager

Combat Manager The combat manager is a component in the game mode blueprint, it’s used for all the combat logic.

You can attack when it's your turn which runs an animation with an event notify.

When it's not your turn you can parry the enemies attack if timed correctly. The parry also uses an animation montage with an event notify.

The event notify for both have in-built code to send the action to the combat manager.
The combat manager processes the attacks; it opens an attack when prompted which can be interrupted upon starting if a parry window is active or within the open and the close attack calls, else-wise it'll land and do damage to the target when the close attack runs.

The combat manager handles the logic for the current target and it's switching. When an enemy is selected with the targetting feature it realizes and tries to read your attack and parry it.

Upon an enemy colliding with you, the game mode triggers a transition which prepares the combat manager. It'll wait a few seconds to tally up any other fighters that might join (currently a max of 6 due to the arena size, more on that in a bit.When the timer ends, it'll send the combat manager all the enemy classes which joined the combat sent by the overworld enemies.The position and number of enemies are handled when combat begins inside the combat manager. This is done with what is currently a combat arena structure which contains the combat player's location, the enemy's location and max amount (denoted by how many spaces are provided) and the camera to use.

Upon getting defeated you lose a battle and reload the level.

Upon defeating all enemies, you win a battle.
Whenever an enemy is defeated in combat the overworld counterpart is destroyed.Winning or losing is checked whenever an enemy is defeated. First check if dead enemy is player, in which case loss. In the case it isn't the player remove the enemy from the fighters and check if only one fighter is remaining.

Rooms

Rooms are defined by an area box. This sets the rooms bounds and where the fog is constrained to.

Upon switching to a different room, the player's camera switches to the respective camera. This also hides the fog in the new room and re-enables it in the previous room.

AI

The AI for both combat and overworld is programmed using state trees.

Enemy Parry

The combat AI all derives from combatant_enemy which has states for when their turn is up and when they're being targeted. When their turn is up, they do some combination of wait and attack. When they're being targeted on the players' turn, they periodically parry to catch players off guard, as mentioned previously.

Overworld AI uses a navmesh to move around. Currently they can wander around and chase the player, making sure to always stay within their starting room.

Stats

Stats include the usual Health, Defense, Attack and Mana. Some of the intricacies include:Health being capped to a max health which is pretty standard.The Damage formula is a flat selfAttack - targetDefense = damageDealt.

Mana does differ from other games in the sense it servers as a turn order, exhaustion mechanic and action cost. The exhaustion mechanic is used for the animation speed of the parry.

UI

Worked on the code for the Main Menu & Pause Menu, combat UI, win/loose screen and to be continued screen. This includes implementing the assets and programming logic. As a personal preference all the buttons only activate on release over the buttons; which means you can cancel a button press by releasing outside the button.

Additionally the stats UI in previous videos at the top was made by me as a debug functionality for viewing combat while the actual UI is being implemented.

Asset Implemention

Implemented animations the animators designed into combat using a combination of Animation Blueprints and Animation Montages for the brute the solider and the player. The parries, attacks, damage reactions, parried reactions and death montages all are called whenever their respective action happens in code.

Organization and Manegement

To organize the group I set up and have been using a combination of Trello, Github and Whatsapp.Trello to keep everyone in the know of what they have done and have to do. As a part of this the trello is managed at least once a week to keep it updated and have people on track.Github to share the changes across ourselves to make like easier. This lets us not have to all work together in the same room in the same computer or have to import mechanics from other projects.Whatsapp to keep in touch. Any pertinent info gets shared here such as committed changes, asking for feedback or general scheduling.

For those interested

This is 3 minutes of uncut fighting.

The main grabbing mechanic works on physics objects which implement a grabbing interface.

It checks if there's an available object when grab is pressed. If this object has the intended interface it'll be added to the player's physics component.

The Throw has a charge up time which you can release whenever before the max charge time. Upon reaching max charge time it'll release anyway.

To charge up it updates the charge meter over a period of seconds with the formula timeElapsed / timeMax = percent. When released it sets the objects speed based on the percentage of the charge meter.

The hit mechanic stops once an object is hit once as to not damage other objects, this is shown by the change in colour of the block.

If the object hits something it checks if its not currently grabbed and if it hasn't already hit something. If both are true it applies the damage.

This is a glorified calculator

Model

Reference Image

- Image by Ivan Vasilchuk.

Model

Reference Image

- Image by Ruslana Gus.

Scene

Wireframes

All Props

Boat Model

Moodboard & references

Digital Illustrations

Vector Illustrations

Physical Illustrations

Black and white