Iker Giménez Bilbao

Star Stable Online

2023-08-01T00:00:00+00:00

Summary</h2>

Brought on to get a hand-over for a project from a senior team member and provide support while she was on new baby leave

Senior member of the team was in the process of developing and releasing a large update rehauling how the player inventory system works behind the scenes</li>
Took ownership of the project and made technical decisions as well as steering the rollout of the changes</li> </ul> </li>
Continued working on new projects after the initial project was done</li>
Provided feedback and guidance on improving processes and workflows at the company</li>
Mentored junior members so they became more effective and confident contributors to the project</li>
Authored internal presentations on changes I made or topics I encountered</li> </ul>
Personal Highlights</h3>

First professional project targeting mobile devices

Android</li>
iOS</li> </ul> </li>
Working with a custom engine was very refreshing after working with Unreal</li>
Impressed my coworkers and department leads with my quick integration into the team and grasping of a complex release flow</li>
Faced complex challenges in unknown environments and technologies with confidence and effectiveness

First project with a large usage of SQL</li>
Using Docker images for services the team had ownership of</li> </ul> </li> </ul>
Video</h2> </iframe>
Project Description</h2>
Star Stable Online is my first job as a freelancer. I was brought onto the team to stand-in for a senior gameplay programmer going on leave, and finish off the project she was working on. It was intimidating to have that kind of responsibility on me, but Yvonne</a> did a wonderful job documenting the project and answering questions for the month she was still working before going on leave. The focus of the project was to refactor how the inventory system worked on the C++ side, and to change how it got stored in the SQL database the game servers use to store player state. Essentially, each inventory space had historically been stored in a two dimensional array, using an ID to identify “bags”, and another for each slot in each bag. Multiple bag IDs mapped to the same inventory space. To make it easier to add more inventory slots and more inventory spaces, this was changed to use a single ID per space, simplifying a lot of the server and client code when working with inventories. I had to adapt quickly to the custom tech stack at Star Stable Enterainment, being brought in on August 2023 and delivering it on February of 2024. This meant migrating the old SQL tables to the new flat array structure, changing player registration so their initial items get placed correctly in the new table, updating internal tools to correctly account for mixed scenarios where one database had migrated and another had not, and other related services which the gameplay team doesn’t have ownership over, talking to the relevant teams and making sure they got to review my changes and provide feedback.</p>
Afterwards, my work on that refactor was used as the basis for expanding player storage. Player storage had been limited by a UI layout that required a lot of manual placement of UI elements, part of it caused by how the bag ID system made it difficult to modify the number of slots in an inventory space. Now that expanding the number of slots is easy on the code side, I worked on trying to make it easier on the UI data side. I specialized some UI classes to handle paged inventory systems, so each page can have a set number of slots to display, and each paged inventory space has a number of pages. The slot UI elements no longer have to be placed individually, and only one pages’ worth of slots actually exist, as they are reused between pages to improve performance and memory consumption. This nearly doubled the amount of player and horse equipment our players can store, and increased their pet storage more than ten fold. The content team and the company was very happy with this, as players were having trouble engaging with new content because it would mean they’d have no place to store their new items. Now, adding more space has become trivial, and a similar approach based on what I built was used to expand the storage space given to players for their hairstyle and makeup items.</p>
There have been a lot of challenges while working on this, mostly related to mobile platforms that I had no experience with before this job. The internal tools and processes to get a development build onto a device hadn’t really been fleshed out when I had arrived, and I pushed to try to define that and make sure everyone on the gameplay team can deploy and test onto at least one mobile platform. This is especially necessary for UI work, as mobile has very different requirements from a standard PC keyboard and mouse setup. Planning has also been a big challenge while at Star Stable, as the company is trying to figure out a way to keep their weekly release schedule going, and to improve internal tools to actually make meaningful weekly releases possible. I’ve tried to teach what I’ve learned about that and offer criticisms and feedback when appropriate so the team and the company continue to improve. That the company renewed my contract way beyond the originally planned timeline during which Yvonne was on leave I think speaks to the fact that they were very happy to have me on board and providing my programming knowledge and skills to the company.</p>

Stellar Entertainment Untitled IP

2022-04-01T00:00:00+00:00

Summary</h2>

Contributed my game development experience to build up an infrastrucutre base to make a new game IP</li>
Participated in team decision making about designing our best practices and how to help developers stick to them

Asset checking tool to enforce naming conventions and performance-sensitive metrics</li>
Perforce branching strategy</li>
Unreal Engine version upgrades</li>
Build machine specs</li> </ul> </li> </ul>
Personal Highlights</h3>

First professional experience with Unreal Engine 5</li>
Led the setup of a good CI/CD system integrated with source control to empower the development team based on my previous experiences</li>
Built a build system using Unreal Engine’s BuildGraph tools despite them being sparsely documented at the time</li> </ul>
Video</h2>
Due to NDAs, there is no publicly available footage of the project.</p>
Project Description</h2>
Stellar Entertainment Software hired me due to my experience and expertise regarding general games programming. It’s a very young company, with several co-development and remaster projects under its belt, but it had struggled in the past to get attempts at getting an internally produced game and IP up and running. The technical director at the time, Andreas Neukoetter</a>, had been positively impressed by how well I did on their programming test, and I was working alongside him to direct the project’s technical decisions in the right direction. I wanted to get a fast and reliable CI/CD system with automated testing up and running, as well as get the team used to good practices for version control and asset labeling. I proposed for the team to make a tool for artists and designers to determine naming conventions in the Unreal editor, and for it to block Perforce submit if it was meant as a production-ready asset but didn’t meet the naming convention rules. I learned about Unreal’s BuildGraph, which was mostly undocumented at that point, and set up our build system to use it with the intent of eventually also using it to run automated test sessions. We discussed ways to prevent pitfalls I had experienced previously from slowing the team down, such as hard code review vote requirements, assigned people to be on dedicated code support roles to avoid support requests going unanswered or falling on the same people all the time, discussed Perforce branching strategies, started to automate parts of merging in the latest versions of the Unreal Engine source code from Epic Games, and many other things that we wanted to have figured out before the project fully started.</p>
Unfortunately, my concerns about us not having basic infrastructure figured out started to encounter a lot of friction with where the project was at that point; there was a push for us to have content to show almost constantly, which made it very hard for us to reach a point of stability with the content and less time was being spent on actually having things like crash/bug reporting figured out, or a larger amount of fast build machines to be able to churn out builds quickly but not slopily. I firmly believe that it’s important to quickly iterate on what you are working on, and to make changes easy to do, but you have to have ways of having confidence as a team that the changes won’t introduce unforseen problems. Game teams often have trouble iterating on ideas because builds take a very long time to get made. The assets we work with and the nature of the problems we solve makes it difficult to keep iteration times low. In addition to that, games have been slow to adopt automated testing, in part because unit testing is time consuming and can be difficult to get right in a language like C++ that doesn’t have proper native testing support like other more modern languages, and in part because more sophisticated integration testing needs to figure out problems like faking player input (either through replays or some other means) which is another time sink, along with learning curves for both. That said, these aren’t unresolved problems. I’ve taken great inspiration from the work Rare did on Sea of Thieves</a> to get their team to be more proactive in guaranteeing stability and predictability in game projects. Cutting down on unecessary things, like code and data branches in a heavy centralized version control system like Perforce, and replacing them with less heavy alternatives, like feature flags, empowers teams. Investing in those things early on sets the project on the path to success, as it allows the team to pivot and reconsider choices mid-production. Errors and performance concerns get caught earlier, preventing broken code from blocking the team and making it easier to meet more ambitious performance goals.</p>
At that time, I was frustrated with feeling like I wasn’t being listened to and my expertise wasn’t really valued. Once Andreas left the team, I felt like I had lost what I felt was my main advocate on the technical side for early investment in things that would save the team a lot of grief and extra work in the future. I decided it would be better for me to leave and find a different opportunity. Looking back, I would handle things differently, and I would have advocated to find a way to keep demo development separate from full production development. This would allow the team to be as messy as it needs to be for the sake of demo development, and only move things across when the team had resources to clean up or improve or properly implement what is being brought across. Recognizing and learning from the mistakes I have made during my career has been as much a part of it as celebrating my successes, and I think my most recent work shows that.</p>

Horizon: Zero Dawn Remastered

2022-01-01T00:00:00+00:00

Summary</h2>

Very briefly worked on this when I started at Stellar Entertainment Software</li>
Worked to help automate the process of transforming data files from the sequel to be compatible with the codebase used for the remaster

Mostly based off of Python scripting</li> </ul> </li> </ul>
Personal Highlights</h3>

Great to learn a new engine and asset pipeline</li>
Got to work with lots of amazing developers</li> </ul>
Video</h2> </iframe>
Project Description</h2>
I started working at Stellar Entertainment in January of 2022. Stellar was working with Nixxes on the Horizon Zero Dawn remaster at that point, along with Weaseltron and Nequinox. Initially, it was very overwhelming, similar to my experience at Ubisoft. Joining a new team with a complex development process is always challenging. Fortunately, the tools built for the game and my coworkers helped smooth the process, and by the end of my collaboration on the project, I felt very confident about the work I was doing and what the objective was. The project took advantage of the fact the sequel to Zero Dawn remade a lot of the same areas with a higher quality for the PS5. The challenge with reusing those assets was that the asset and graphics pipeline for the code bases is very different, so we had to find ways to make the assets compatible. This meant parsing asset specification files for both versions, and coding transformations for the data so that when artists moved them across projects, most of the work was done and they only needed to tweak details specific to the remaster. Some of this involved working with Python scripting which I had only very briefly touched in other contexts. Despite not having that much practical knowledge in the language, I was able to contribute to the team significantly. It was a very fun challenge, and I was very happy with the solution I came up with.</p>

Conan Exiles

2019-10-01T00:00:00+00:00

Summary</h2>

Supported a live game with bug fixes, exploit investigations, and performance improvements</li>
Extended an existing data tracking solution to support the design team with better data on player trends</li> </ul>
Personal Highlights</h3>

First professional experience with Unreal Engine 4</li>
First professional experience with a live game</li>
Learned a lot about pitfalls game development teams often fall into</li> </ul>
Video</h2> </iframe>
Project Description</h2>
My time at Funcom is a difficult point in my career. I left a team I was very fond of at Ubisoft Barcelona, and moving to Oslo, Norway was a very big change. Relocating to a country that you don’t speak the language of and that is very different culturally to what you grew up with is a challenge. On top of it all, the SARS-COV-2 pandemic started while I was just getting my feet under me at Funcom and in Oslo, and I had a medical emergency at the start of 2020 that was very scary to face in a foreign country. I did like the experience of living in a country where it snows often and services and people are used to it, along with a place with big parks and easily walkable spaces.</p>
While at Funcom, my main contribution to Conan Exiles is related to taking an existing data tracking system and extending it so that the gameplay and design teams are able to selectively track things player trends to figure out playtime funnels, popular item sets, and similar things to better direct the team’s decisions. The existing system was only used to gather more information about crashes that were particularly difficult to debug, which was a lot less data than what eventually got sent by the system I expanded. This meant coordianting with the gameplay team so that they knew how to add code to collect the data, and with tools to be able to make sure the infrastructure in place was able to process all the data coming in.</p>
Beyond that, I learned a lot about the difficulties of supporting a live game. While with Assassin’s Creed III I had to be careful about changes to not break existing content, this was a lot more complex with Conan Exiles, because changes did not have as much QA time to go through before they went live. Disruptions to the build system were also much more important to address quickly, and builds were a lot harder to make in order to test changes. Supporting a live online game with modding support also has a lot of challenges associated with it, because people need access to a lot of project internals that increases the attack surface area. Decisions made several years before I came on meant that some exploits were very challenging to fix, as they would need extensive code changes to completely address, but the time was not available to do all those changes, in addition to high risk of breaking existing content. Overall, I learned a lot about what patterns to avoid and what to flag as problems early on in development to be able to address them before they become so engrained in teams that they can’t be undone, and the project quality suffers for it. It made me more curious about how other games have tried to address these challenges. It has helped me to grow my skills beyond just programming, improving my communication, leadership, planning, and other equally important skills.</p>

Assassin's Creed III: Remastered

2017-08-01T00:00:00+00:00

Summary</h2>

Tasked with porting the game over to then-current-generation consoles

PS4</li>
Xbox One</li>
PS4 Pro</li>
Xbox One X</li> </ul> </li>
Tasked with improving PC version, including support for modern Windows</li> </ul>
Personal Highlights</h3>

Built a small proof of concept tool for the art team to track references to assets in the engine

Tool was spun out by tech art to be an internally-accessible web database of all assets in the game and for the art team to track their work</li> </ul> </li>
First professional experience with Xbox and PlayStation</li>
Implemented HDR rendering for PS4 Pro and Xbox Series X</li>
Supported Design, Gameplay, Art, and Engine teams with debugging and tools support

Made presentations for the team to learn about C++ debugging and internal Ubisoft tool usage</li> </ul> </li>
Collaborated with international teams in the Philippines, China, Canada, and Singapore</li>
Learned to balance code maintainability improvements, visual improvements, optimizations, bug fixes, and asset pipeline improvements with maintaining a legacy codebase</li>
Upgraded audio SDK for compatibility with modern consoles</li>
Integrated modern crash report tools to keep track of bugs and prioritize work</li> </ul>
Video</h2> </iframe>
Project Description</h2>
Assassin’s Creed III: Remastered was my first project in the games industry. I was accepted to Ubisoft Barcelona through their Graduate Program as a gameplay programmer, and made the switch to the engine programming team about a month in. It was daunting for my first job to be in a AAA company, but it showed me how valuable and practical the skills I obtained while studying at DigiPen really are. I was able to grasp working with Perforce, with console SDKs, bug reporting tools, crash dumps, debugging, asset pipelines, rendering pipelines, and many other systems quickly. Assassin’s Creed III originally released in 2012, and a lot of the systems were showing their age and their limitations. The project taught me a lot about working within an existing code base, where the project aims to not change fundamental gameplay behavior, while also recognizing what can be cut out or reduced to improve quality of life. Overall, the main highlight of this project for me is that the team felt tight and cohesive and there was a high sense of team spirit. We trusted each other to make the best decisions for the project and for the team, even when what was available to us was not ideal and we had to make compromises for the sake of the release date or to keep the scope realistic.</p>
A particular challenge we faced that I was in charge of solving is the HDR rendering. Owen Angell</a>, one of the senior rendering engineers on the project, supported me through the process and referred me to some blog</a> posts</a> from Jasmin Patry</a>, about the HDR implementation on Infamous: Second Son. HDR is a tricky subject, in part because HDR is an overloaded term that means multiple different things. The first time I heard of HDR in a game development context was in Half Life 2: Lost Coast. Lost Coast is cut content from Half Life 2 that Valve released in part to showcase some of the graphics work they were doing at that time. The level showcases scenes in which the main character goes into and out of dark tunnels, and the game simulates human eyesight by having adjustment periods as the character moves in and out of these locations. To achieve this, the lighting pipeline was changed to be HDR, high dynamic range, rather than the lighting pipeline game engines mostly used at the time, which kept the lighting value calculations within an SDR, standard dynamic range, set of values. Basically, games usually used 8 bit integer values to store the result of lighting calculations, which limits the set of colors that a scene can contain. It also makes it difficult to have particular lighting sources “overpower” others. In real life, light sources have a specific brightness to them, usually measured in candelas or lumens, and the human eye is capable of letting in more or less of that ligth by expanding or shrinking the pupil. This is what allows humans to see in the dark, given enough time to adjust to lower light settings, and what causes sudden changes of lighting like going into a tunnel and back out, to be uncomfortable and need an adaptation period. If the lighting calculations are stored with a different data type, such as a 16 bit or 32 bit integer, or even a 16 or 32 bit floating point data storage, the range of values that the intensity of a light source can be is suddenly much wider. Besides mimicking human eyesight, this also allows lights to be much more dynamic. More commonly, HDR is used these days to refer to screens that can display a larger gamut of colors than SDR screens. What this changes is the format of the buffer the game is rendering to, so now it is able to write out its values to a buffer that can contain a wider set of numbers, and therefore also show images with a wider contrast natively, rather than forcing them to have to be mapped into sRGB or some other standard dynamic range gamut. I’m simplifying some of this for the sake of brevity.</p>
For Assassin’s Creed III Remastered, we wanted to support HDR televisions and monitors for the PlayStation 4 Pro and Xbox One X. The problem was that the Assassin’s Creed games with HDR rendering also changed the way their UI is rendered, which made it so that we couldn’t just piecemeal merge in the feature into Assassin’s Creed III nor copy the solution over somehow. Assassin’s Creed III’s UI is blended on top of the 3D scene, so that blending needed to happen with the correct values in order for the UI to look correct, and we didn’t want the UI colors to be affected by the HDR mapping to avoid visual issues. The solution we came up with was to calculate the blended value, and then transform that by the inverse of the HDR mapping look-up-table (LUT) so that when the HDR LUT got applied to the final draw, it would undo and mostly preserve the calculated blended colors of the UI. This worked well and wasn’t too heavy on performance, even at higher resolutions, and the final game shipped with HDR screen support on Xbox One X and PlayStation 4 Pro.</p>

Sabotage: Give me my Pet Back!

2016-01-01T00:00:00+00:00

Summary</h2>

Improved a sophomore-year project with other DigiPen Europe-Bilbao students for our Senior Year project</li>
Reworked how probability rolls worked to improve the play experience</li>
Built a way to script cutscenes using Json files to add story exposition to the game</li> </ul>
Personal Highlights</h3>

First project I worked on as a student when I actually felt like I was using all of the knowledge I had gained during my studies to fix problems in the game and expand on the existing content</li> </ul>
Video</h2>

The video is rather loud! Be careful with the volume!</p> </blockquote> </video> </p>
Project Description</h2>
In my sophomore year of university, my graduating class was split into two teams. I worked on Dandelion, while the other students worked on this game, Sabotage. For our senior project class, some of us chose to group up again and improve on a previous project. We chose Sabotage, as it was the most stable and the most easy to expand upon that our cohort had developed. There were a lot of concepts left on the table in the original game, such as remixed bosses and a storyline. We used our improved skills and knowledge to try to bring those things to life in a second iteration of the game.</p>
One of the things that had bothered me about the original is that the health and mana pickups dropped by enemies were very inconsistent. This was down to some messy code trying to use randomness to decide whether to drop a pickup when an enemy is defeated or not. I had been taking probability and statistics math courses recently, and I had more practical experience using random number generators in C++ because of it. I changed the code to better stick to the intended case where the drops became more plentiful if the player was running low on either mana or health. While it did drive down some of the difficulty, the game is much better for it, as it now feels possible to finish the game, and not get stuck very early on due to minor mistakes.</p>
The other major thing I added is the ability to script scenes using Json files. The scenes aren’t complicated, and are sequentially exectued actions and text boxes written directly into the Json file. These days, if I were to do something similar, I would make the editor integrate into the engine and allow previewing and tweaking more on-the-fly, to reduce iteration time. Given more time, we might have experimented with giving the player chocies to make that branched the narrative. But the results speak for themselves, as our combined efforts resulted in an experience that plays better and has more personality.</p>

0xC054 N05TR4

2014-01-01T00:00:00+00:00

Summary</h2>

First attempt at a 3D game</li>
Inspired by XCOM: Enemy Unknown (2012)</li>
Main programmer in charge of graphics</li>
Also in charge of game design</li> </ul>
Personal Highlights</h3>

Started to develop ways of managing engine assets and creating pipelines</li>
Learned how integrating assets into an engine looks like from an artist perspective and how it connects to graphics programming</li>
Built debug tools to improve development of other tools like a terrain editor</li> </ul>
Video</h2> </video>
Project Description</h2>
For my junior year at DigiPen Europe-Bilbao, I pitched making a squad tactics game imitating Firaxis’ XCOM: Enemy Unknown. The game really absorbed my attention when I first picked it up and my team members also really liked it when they tried it out. It felt like a reasonable challenge to try to copy it and change the aesthetics of it for a student game. The art team proposed to make it Italian Mafia themed with robots living in flying cities instead of humans. The main hero unit is a “godfather” that the other units have to protect, a rifleman unit, an explosives expert, and a tank that can turn itself into cover. At first, the project started out strong and we got to a place that made us feel pretty confident about finishing something reasonably fun by the end. Our ambitions were too high for an eight month project, and although we got extremely far, we weren’t able to dedicate enough time to it for polish and stability improvements. The end result was a game that worked but that is difficult to follow. The gameplay needs better feedback through animations and camera work, and the environment needs better reactivity. The fog of war system also never worked like we wanted it to. That said, we succeeded in including things like animated 3D meshes (all through affine hierarchical animations, no skinning), terrain analysis and editing, importing meshes and textures easily, and a robust UI system.</p>
I took up the role of graphics programmer for the project. We had taken a 3D rendering class during the summer, which made us a lot more confident about what we were doing in 3D. This project was the point in which I started to really understand how to make game assets be data driven rather than hardcoding values and behaviors everywhere. The engine we built is capable of loading scenes described in json files, which were parsed at runtime and helped us have better iteration times. It also has an archetypes system (also known as prefabs or blueprints) to be able to quickly reuse definitions of individual units or specific objects. The files can also specify which material they use, which defines the shader, texture, and other visual properties of a game object. Lighting uses simple Blinn-Phong shading, and deferred rendering for more flexibility. The rendering side was also able to draw debug line segments, which was extremely useful when building the map editor. It allowed the programmer in charge of it to check that the terrain generator code split up the maps into tiles correctly, and tweak parameters of the terrain generator to fix any issues before importing the data into the terrain editor and cleaning up the map. The project was a great introduction to how much pipelines make a difference when building a 3D game.</p>
Overall, I think the project would have been better if we focused on satisfying the grading rubric requirements first, and then try to add all the bells and whistles and polish we wanted. The scope was too large for an 8 month project that we worked on while also juggling the rest of our degree. We lost time, but we also didn’t account for the mental and physical load of having to deliver things for our other classes. Many things had to be done the “hard way” and would be a lot easier to tackle with modern tools. Back then, graphics debugging tools like RenderDoc</a> didn’t exist, and what was available was very unstable or wasn’t useful to debug why things weren’t rendering as expected. A library like Dear ImGui</a> would have made our lives a lot easier by lowering the barriers to create editor UIs to make scene files and tweak shaders in real time. I carry the experience of building this game with me to this day, and I try to think of ways to improve the pipelines and dev experience of the teams I work with when I can. A team is only as effective as the tools they have access to. They can go very far with ad-hoc and improvised solutions, but even the projects that have extremely strong starts will fail to have a strong finish and to carry that momentum if developers have to go through convoluted processes to make tiny adjustments to the game, or if they are unable to examine the effects of what they change.</p>

Dandelion

2013-01-01T00:00:00+00:00

Summary</h2>

2D side-scrolling puzzle game</li>
Main mechanics rotate around a character with a dandelion on its head</li>
The more seeds the dandelion loses, the older the character becomes</li>
Different abilities at different ages</li>
Combine abilities to solve environmental puzzles</li> </ul>
Personal Highlights</h3>

Very difficult project</li>
Learned the hard way about how difficul it can be to work with graphics programming when there’s no debug tools available</li>
Learned about the pitfalls of uninitialized memory values</li>
Learned to animate objects on screen using sprite sheets</li> </ul>
Video</h2>
No video available for this project; files have been lost</p>
Project Description</h2>
Dandelion was a very hard project for me. Looking back on it, I understand why my team and I were so overwhelmed and why we should have approached things differently. We were overly optimistic about our abilities and the time it takes to develop things. DigiPen is also a very demanding university, with a very wide set of topics covered in very little time. Deciding to develop an ambitious game as a third serious game project, with a wholly custom engine, having never worked with modern OpenGL (or any kind of graphics API for that matter), having barely touched on Visual Studio, and not really grasping what building a C++ code project entails, it was bound to be extremely challenging.</p>
The premise of the game is about a small mouse-like woodland creature that is attempting some kind of pilgrimage. The creature has a dandelion flower on its head, and when seeds get blown off, it ages. The creature has three age states: child, adult, and elder. As a child, it can crawl into smaller spaces, and it can move quickly. As an adult, it’s able to jump higher and push and pull boxes. As an elder, it is able to spawn plants from fertile soil that can act as platforms and ladders. The player has to get past the obstacles in a level taking into account the different states’ abilities and what they can do to either make the creature younger or older. The woodland environemnt lent itself to highly detailed environments with very nice hand drawn art. Unfortunately, it also caused some of the problems we ran into.</p>
Because we wanted more naturalistic environments, we tried to make levels by having artists paint the levels and us overlay the collision data on top with an editor. To be able to have slopes and uneven surfaces, we implemented oriented binding boxes, but didn’t quite nail down the collision restitution. The editor was also unstable, because we didn’t understand how to sync separate C# and C++ threads at the time. The mistake which caused us the most hardship, though, was uninitialized memory. There were a series of graphical bugs and weird behavior that didn’t seem to have a pattern. When I looked back some time after, I realized a lot of it was down to variables not being initialized correctly, so the values that they received were random when running outside of the debug environment. These days, I always opt for initializing to 0 or whatever other default value that makes sense. Learning from mistakes isn’t always the prettiest or the most fun of experiences, but it is the kind of mistake I am glad I made as a student and no longer make as a veteran programmer.</p>

Iker Giménez Bilbao

Star Stable Online

Video</h2> </iframe>

Stellar Entertainment Untitled IP

Summary</h2> Contributed my game development experience to build up an infrastrucutre base to make a new game IP</li>

Video</h2> Due to NDAs, there is no publicly available footage of the project.</p>

Horizon: Zero Dawn Remastered

Video</h2> </iframe>

Conan Exiles

Video</h2> </iframe>

Assassin's Creed III: Remastered

Summary</h2> Tasked with porting the game over to then-current-generation consoles PS4</li> Xbox One</li> PS4 Pro</li> Xbox One X</li> </ul> </li>

Video</h2> </iframe>

Sabotage: Give me my Pet Back!

0xC054 N05TR4

Summary</h2> First attempt at a 3D game</li> Inspired by XCOM: Enemy Unknown (2012)</li> Main programmer in charge of graphics</li>

Personal Highlights</h3> Started to develop ways of managing engine assets and creating pipelines</li> Learned how integrating assets into an engine looks like from an artist perspective and how it connects to graphics programming</li>

Video</h2> </video>

Dandelion

Video</h2> No video available for this project; files have been lost</p>

Video</h2>
Due to NDAs, there is no publicly available footage of the project.</p>

Video</h2>
No video available for this project; files have been lost</p>