Kuroko Engine was the basis of Project Atlas, the engine we used to develop the game. This first version was developed by me and Rodrigo de Pedro Lombao. The main reason why we decided to pick it among other options was the scripting subsystem that was developed

The aim from the beggining was to make a "Unity Like" scripting system, where each file is an Asset and scripts can be added to Game Objects as components. The language choosen to implement scripting was Wren, a scripting language developed by Bob Nystrom. The reason why:

- It was similar to C, which all the team is familiarized with
- Fast compilation and runtime
- Light weighted implementation compared to "Mono", used for implementing C# which was our other option

Before the project started, the scripting system already featured some characteristics that would really help us when developing the game:

- Hot reloading

- Variable modification

But that wasn't enough. Therefore, I focused on improving the system adding more features:

- Development of the API: I made possible that every other existing subsystem (Audio, Animation, Particles, Collisions, Physics, Input, Time and Pathfinding) was used from the scripting. Every component was a class, that could be gotten from a Game Object using "getComponent()". Then, functions to controll the behaviour of the component could be called in that class. Also, I included support for controller input in the engine.

- Tag System: This is what allowed us to have communication between Game Objects. In the editor, objects can be assigned tags, and the function FindGameObjectByTag(tag) would return a list of GO.

- Communication between scripts: This was a crucial aspect of the scripting system. Being able to access any Script in any Game Object, made for a flexible scripting system that allowed us to develop the game in a confortable manner.

- UI and Animation scripting callback: In order not to populate scripts with too much code, some systems were developed which would call certain functions when a UI event happended or in certain animation frames (for example, in the final frame of the enemy attack, we call the function that instanciates the attack collider)

Collaboration with: Marc Torres and Carles Margelí

Conclusion: I'm really proud of how the scripting subsystem came out. Partially every member of the team has used at least one time, and they have been able to learn it really fast and with few issues. Using Wren was a bold move, since no one knew about it, but it was a good decision.

During the rest of the project, I kept adding small functions to the API, but not more systems.

From the beggining I was really focused on developing the scripting system. My idea was just doing and improving the system, and let other people use it.

After we failed Vertical Slice 2, I realized that the system was solid enough, and the reason of our failure was a lack of people working on gameplay programming. Because of this, I decided to switch from Engine coding to Gameplay coding, specifically combat and the player.

I picked up the work of Pol Ferrando and Lorién Portella which had already set up a base for it, but it wasn't functional. With my knowledge about how the rest of the engine worked, how the scripting worked, constant communication with other teamates and previous experience developing and designing combat gameplay (Dungeon Brawler) I helped to fix the issues that made it work poorly and from there onwards I dedicated exclusively to make the game FUN.

Features for VS3:

- Variable tweeks: Fastened combat by increasing the speed of the animations and the combos

- Smooth movement


- Pushhit and Pushforward


Conclusion of VS3: The combat was functional, but it had some bugs still, didn't feel good and we only had 4 attacks (2 kicks and 2 punchs).

Features for Alpha 1:

- Movement depends on camera: This allowed designers to iterate with a variety of camera angles, and made the controlls allways make sense regardless of the world coordinates

- Controller Vibration
- Differentiated attack properties
- Kick and Punch third hit


- Projectile Special


- Combat camera


- Pitfalls


Conclusion of Alpha 1: The combat still didn't feel good. Player didn't feel in control of what was happening and hitting enemies didn't give enough feedback. Besides there weren't many special moves avalibale, only the projectile.

Features for Alpha 2:

- Combat Auto Aim: This fixed the issue related to player not feeling in control of combat


- Camera shake and Slow Motion: Slowmo is achieved by briefly reducing the dt. This too elements, along with sound and particles Lorién Portella and Josep Pi, fixed the lack of feedback on attacks


- Dash limitation system: Unlimited dash was too strong, and made it so the player could dodge enemies forever. Out of feedback given in one of our playtests, we developed a system that allowed player to wait for charges of the dash to replenish and then use multiple ones at once, way more FUN than a simple cooldown.

- All specials implemented:

Projectile


Haerza Haegon


Axe kick


Plasma Dash


Conclusion of Alpha 2: The gameplay felt good, but it was too easy, as the player could perform infinite combos on enemies.

Features for Alpha 3:

- Enemy separation: In order to prevent infinite combos, I implemented enemy separation, which made it so enemies attack from differten positions when in groups.


- Enemy charge: The previous feature still didn't stop the player from performing infinite combos on single enemies. Therefore, I implemented a new attack aside from the basic punch, which was the "charge". Enemies could be configured so each time they attacked they decided weather to attack with a normal punch or an invencible charge that the player needed to dodge. This chance increases when the player hits the enemy, and decreases when the enemy charges


- Dash and special cancelling: Players were punished really often when they fought too enemies because of separation, so we gave the option to cancel the recovery of the punches and kicks into dashes, as well as special moves.



- Save and load of player stats: Between scenes, the player needed to keep his stats (life, unlocked abilities, plasma, scrap...) so I developed a system to store variables locally in the engine and applied it to the gameplay



Conclusion of Alpha 3: Gameplay was too hard

Features for Gold:

- Implemented "time between attacks": Enemies will wait a random amount of time before attacking, mantaining a combat stance
- Charge aiming threshold: Made it so the amount of time that the enemy aims towards the player while charging is adjustable
- Graphic feedback on End Level Trigger: Made end level trigger so it has a red circle when there are enemies around, therefore can't pass to next level. When there are no enemies within a certain radius, the circle becomes green and the player can pass to the next level
- Implemented god mode