TECHNICAL DESIGN
At Isart, we work most of the time in a team without programmers. Game designers are responsible for coding the games we submit. Everyone is more or less at ease with this task. In my case, it's an area in which I enjoy learning and which has often led me to handle a large part of the coding in our projects.
I've mostly practiced visual scripting, whether on Unity or with Unreal Blueprint. I've done game logic as well as tools, or taken charge of version control in certain projects. When it comes to line coding, I'm less experienced: I can read and understand code in most cases, but I'm not yet very efficient on my own, in C# for example.
However, I do have an appetite for programming and would like to continue developing this aspect by learning more in the future.
IN MY PROJECTS
Sentinel by Breaking Walls
This text is extracted from the project page. To see everything about the project, click here.
Among the design team, we designed the game together and then split up into two for programming, one for LD and one for UX. I was in the programming duo and my main task was to make all the game's enemies and the code surrounding them. I'll mainly be talking about that in this section. The project began with a first prototype that I made between design meetings to evaluate the idea of explosion chains with a brick-breaking feel:
We were fairly confident that the concept had potential and would fit in well with short production runs. But the main perceived problem was a performance risk linked to the number of enemies and the fact that the game is in 3D, and therefore uses skeletal meshes which are likely to be very costly. To gauge the seriousness of this problem, I carried out research throughout the early stages of the project.
After looking at various solutions, we decided to implement vertex animations for the enemies, turning them all into much less expensive static meshes that are animated through their material with vertex displacement textures. To find this solution, I consulted UE5's Matrix Awakens demo, which uses this method, and I started from a utility proposed by kromond on Github, which I slightly improved to make it fit our needs.
This first direction was the most convincing compared to other plugins such as MassEntity, and proved to be sufficient, when combined with other enemy optimizations such as having them spawn in a pool and using squad logic to manage them.
The squad logic was handy for optimizing calculation - the squad calculates for all the enemies in it, rather than each enemy doing so independently - and also helped us with gameplay. In fact, we wanted the jackpot enemies to hide behind the others, so we needed the opponents to maintain a squad formation when they moved. For this, I did some research on the RTS side, notably with this article:
Group Pathfinding & Movement in RTS Style Games by Dru Erridge.
As for the rest, a good part of the work was simply programming the game's dozen or so enemies, which turned out to take less time than expected thanks to good code recycling. All the enemies inherit a basic enemy with the essential code on which I add or override special behaviors as needed. Here's a video of the project in mid-production, highlighting some of the enemies:
Virtual Breach
This text is extracted from the project page. To see everything about the project, click here.
I made the whole game on my own, except for a few assets such as the background and sounds. Everything else is programmed by me in Unity, using Visual Scripting and position lists to draw the shapes with a vector effect, which are then visualized using LineRenderers. The whole game is just lists of positions that move with the LineRenderer updating and Raycast detections, meaning there are no sprites or meshes, except for the player. It was unusual to design, but very instructive in terms of modular code that can be reused as best as possible.
Sand Rush
This text is extracted from the project page. To see everything about the project, click here.
