DualtroN Post Mortem

DualtroN is finished. After these 15 weeks of work, we finally have the final product. Having a final product does not mean the game is complete, because many of our plans got lost along the way. That was probably the hardest part of the process of creating a game, discarding features that you already built in your head, but there is no time to implement. DualtroN did not get too far from the initial goal, but we reduced the amount of content notably by removing the third level.

While making a game there are decisions to make and luckily I would say we took most of them correctly. The initial plan was tight in time and we were able to foresee where the situation was heading and we were capable of assuming it and fix it the best we could. Removing a level meant removing many of the ideas we already had for DualtroN, like having vertical parts on a level or a boss that could un-fusion you, but I think the decision also brought more time to make the experience we already had better. We have the opportunity to improve the visuals of the game and especially to give feedback to the player about what was happening at every point.

Since our team is composed by 4 programmers, the absence of artists was a fact we had to substitute by investing some of our time in making the game visually better. The problem was not just to make the game appealing, we needed to transmit some necessary information through effects, that are harder to design when you do not have someone who understands how to transmit those. Luckily we had Eneko in the team, who is always willing to make this kind of feedback effects that make the gave more enjoyable.


DualtroN has only 2 levels, but with the stats gathering system Tejedor implemented, this 2 levels have a bigger replayability. The timing of the levels gives a time attack mode that makes the game interesting to play again.


This was the first time that the four of us were working together and with DualtroN we have proven to ourselves that we can do it. The aspect I most value in our team is the balance and the different roles we took naturally. During meetings, there is also a division between the optimistic and the pessimistic sides of the team, basically Eneko and Tejedor against Falven and me. This opens debates about what should be the scope of the project that results in a pretty accurate and realistic plan, which in any other way is hard to achieve.

When working the difference of personalities also shows up, when we see Eneko working in visuals (probably too soon sometimes), Tejedor creating systems and the more pragmatic approach Falven and me have to create (make it work first, we will take care of other stuff later). The good part of this is that we naturally use these differences constructively and it normally goes in a good direction because everyone pulls to his working style.


GAM450 class has been a great experience for many reasons. Mainly because I understood what it means to work with a built-in engine like Unity3D and what it means to create a game in 15 weeks. I already did that first year, but the scope of those games was not comparable to DualtroN. It also taught me how important planning and team organization is. The truth is that we probably lacked some of team organization at some points, but without it we were able to keep working due to the team dynamics that I explained in the previous paragraph. I am really proud of what DualtroN is because I saw many people wanting to play it after we showed it to everyone. This is one of the main goals of the game, having an addictive cooperative game and that goal seems to be reached listening to people’s reaction. As my final DigiPen project, I am proud of it and how my team worked to do it.


Alpha Milestone Report

DualtroN already got to its alpha milestone. This last month has been hard for the whole team. We all realized that DualtroN is in its last phases of the development and that we needed to add those details that need to be there to consider the game finished. That also meant that the team had to make decisions about what was the real scope of the DualtroN. We had many plans that we had to discard or convert them into smaller features.

One of those decisions was to remove the third level completely. We had to choose between making the two levels we had the best they could or having three levels that would most probably be less polished than they should. We thought the first option would make DualtroN a better overall experience.

Since the now the second level was going to be our last one, the fusion had to have a bigger presence on this level. So more than half of the phase plus the boss was going to be played in fusion state. A fusion state that had almost no testing and the team did not know if that was going to work design-wise. We invested quite a lot of time on polishing that experience of playing with the fusion since it is a completely different control scheme. I think that time was properly invested because we finally got something that is actually fun and nice to play. Especially when we realized that it really adds to the need of cooperation we wanted the gave to transmit.

My Work

During this milestone, my work has been very diverse. I have programmed some gameplay like the second boss and some changes in the fusion and I have also worked with game flow related issues. In that sense, I created a main menu, a pause menu and a level transition for the game.

Main Menu

Focusing on game flow was one of the tasks we wanted for alpha and I was the one in the team who took care of this area. Main menu was the first aspect I created because it was the most essential parts. I have a simple goal for this menu, since we are tight in time, I wanted to create a menu that was final and would not change once finished. I am not someone who normally takes care of making the things I do look beautiful, but in this case, I did an extra effort to make it final even visually. I made it simple but with enough dynamism for it to be not static.

The main menu needed to have some minimum screens apart from the menu itself which in order to maintain it simple, I just embedded in the same scene with different camera orientation. This way by just moving the camera we could have a nice transition and keep it simple.

Pause Menu

With the pause menu, the goal was exactly the same as with the main menu. I did an even simpler approach to this menu with a really basic layout and a very simple scrolling background. Apart from implementing the menu I also programmed the pause state of the game.

Transition Menu

The transition menu is just a level ending menu where the statistics gathered throughout the level are shown. The statistic shown is still WIP, but I wanted to create the menu so that Aitor Tejedor could simply add them on top of it.

Boss 2

After the experience with the first boss, we decided for me to be the one building the second boss too. In this case the boss was in fusion state so the gameplay was going to vary. Falven designed the second boss as a constantly scrolling enemy where the moments of vulnerability would have also an obstacle avoiding part. Due to the way the fusion is controlled, avoiding obstacles and shooting is a big challenge and cooperation is necessary. During the rest of the attacks, we want the players to focus more on just avoiding.

Since while this boss was being implemented the fusion was being tweaked and playtested, the final version has not been tested. This enemy will still need probably a couple of iterations to decide and balance when to do each of the attacks and decide the resistance of it.


First Playable Milestone Report

We just reached the prototype of DualtroN. During this milestone, we stopped creating mechanic testing sections and we built real content for the final game. Full level one is built now with a final boss at the end of it (more about the boss later). Since the content we are creating is tending towards being final, we also made some visual revision. We know we still have a huge margin to improvement on this aspect, but do not worry, we would tackle that in coming milestones.

We worked with the mechanics we already had mainly, but this milestone was also when we added to new features that we think will add a lot to the game.


This game is a completely different gameplay element compare to the DualtroN with two players. When the Fusion happens, there will only be a single character on screen, a character that is controlled by both players. In this mode, we want synchronicity and cooperation to be unavoidable. The actions of that character will happen if and only if both players do the same action at the same time. Coordination will be primordial to control this powerful entity.


The link was created first just to avoid both players to get far from each other, which is a needed feature to keep both inside the camera space. After implementing it, we realized that the effect we were working on could have ways to exploit it as a gameplay element if we gave the players the ability to create the link at any time. We did some test and we discovered that it may give an extra dimension to what our level design can have. Actually this feature will have a huge importance in the forthcoming second level we are building and it creates really spectacular gameplay moments with came out pretty naturally.

My Work

I have work in many different aspects of the game during this milestone, I improved visuals, worked on the logic for the fusion, created the link and the boss for the first level:


My main task was focused on adding feedback to the gun switching, a key feature of our game that needs to be clear. I made a really simple effect, that consists on a halo that moves from a player to the other, that we think works well. Being able to see something going from a player to the other removes part of the confusion that the game previously had.

Since I was improving players feedback, I also decided to make visual improvements on the player, because I wanted them to look like atoms. I used Unity3D trail renderers moving around a sphere and that created a really cool trail when moving that was not intended, but we all agreed that was good looking.


Gun Swapping and Player Visuals


As I explained before the fusion is controlled by both players doing the same action at the same time. This makes it hard to control, but it is a really powerful entity that has a jetpack and a much more powerful gun. Implementing it was straight forward and after I did the logic, Eneko took the responsibility of making it better and mainly more visually appealing.


I also mentioned this feature earlier, but we did have many problems while working with it. Our player is controlled modifying its velocities and we do not rely on Unity3D physics, but we wanted to use its spring to create that connection between the players. We were getting problems like players being able to fly and many other weird behaviors, so we found a fix by disabling our own logic when the spring is active and leaving Unity3D do it.


Link in Action!


The boss plays a really important role in DualtroN, since it represents the ultimate challenge at the end of every level. For the first Falven initially designed one where the fan elevated floor has a big importance. We all thought that it was an interesting approach because while one of the players was killing the boss, the other one had the responsibility of maintaining him/her alive.

After implementing and testing it, we discovered that the design had many flaws, mainly because it was not fun. We tried some improvements on it, but we realized that was going nowhere, so we decided to redesign and rebuild it from scratch.

For this second iteration, Falven had the idea of each player controlling somehow the other lane boss and we both started brainstorming about different attack patterns that would make the boss interesting and natural to play. We ended up creating 5 different attacks for the boss and we are now pretty happy with the result.


Sweep Attack


Self Explosion Attack


Double Sweep Attack


Targeting Explosion Attack


This milestone has been a pretty new experience for me. In the projects I have been working until now (check portfolio), I always took a more technical role and I invested most of my time improving the engine or creating new graphic features that other teammates would after use. During this milestone I have worked mostly on gameplay elements, which requires a completely different mindset when programming and I had never tested myself on that aspect.

Starting with the fusion logic was a good first attempt, since the most important part when programming gameplay is testing it and the fusion has a very simple logic. This part worked well, but when working on the link, everything started to become harder. The development of the link was more a matter of trial and error until we found out the working combination, which it felt more like a fluke. The real challenge came with the boss, which as I explained, had to be rebuilt from scratch. This moment felt a little bit demoralizing because when I realized that the first design was not working, I felt completely responsible of it not working as it should. I think we were able to change that situation and do something interesting, but that moment clearly showed me that when you are programming gameplay, planning how to build something  is not the hard part, because things do not always work as planned.


I think my team and me where able to meet the goals we wanted to achieve. We proposed to have a complete first level build for this milestone and we have it, including some visual improvements that we also think are necessary. We have a clear idea of where we are going and that is something I really like. We all share the idea of the game we want to make and we most of the time agree on what the game needs. The metascore systems will be one of the most important features for next milestone and hopefully everything will work as smoothly as it this for this one.


Prototype Milestone Report

This report is part of the GAM450 class, where every year we create a game in groups. This is my last game class at DigiPen Institute of Technology and so my last project. Until now, I have been part of three more projects (check out the portfolio) were we had to build our own engines. In the end, we are here to learn how to create video games and engines are a big part of it when talking about programming them. GAM450 is just a 4 months course, so my team and I decided to use an already built-in engine for this game, Unity3D. Do not forget to also check out my teammates’ blogs:


This is the first time we will be using an external engine and this first month has been a really interesting experience. We realized how fast the level creation becomes when you can use a solid and powerful editor. This has been the main problem with the projects I have worked on until now and even though we built our own editors, these were always lacking details (undo, redo, copy, paste) that made our level building a longer process. Iterating and testing those levels is also much faster and having the ability to modify things while running is a huge step. But not everything has been great about using Unity3D, we are used to being able to get deep into the code and debugging it completely. We simply cannot do that on Unity and every time we have something that is not working as intended, especially when using physics and collisions, we can only guess what is really happening underneath.

But not everything has been great about using Unity3D, we are used to being able to get deep into the code and debugging it completely. We simply cannot do that on Unity and every time we have something that is not working as intended, especially when using physics and collisions, we can only guess what is really happening underneath.

The Game – DualtroN

DualtroN is a 2D side-scrolling arcade cooperative game, where both players will give to share a single gun to survive. We want to keep the essence of the game in the need to cooperate to be able to move forward. The screen will be divided into two different lanes and the players will be separated during most of the game. The game will pretty fast paced and it will have a big arcade factor, where players will have to avoid bullets or synchronize really well. This means an easy to control player with very polished movement.

Dystopia 2014-10-04 17-26-10-49

My Work

I am supposed to be the lead programmer of the project, but since we already have a built-in engine and the technical challenge is not as big as when we have to create our own, my main job has been to merge what others do from time to time, to make sure that we do not lose sync between our own versions. We are using SourceTree as a version control and although it took me a while to adapt to how it works, I must admit that it helps to manage the merging of different tasks. We realized about the difficulty of merging Unity scenes pretty early so we decided to works in sections of levels. This way we can simply save that section as a prefab and building the levels is just a matter of joining sections. This actually has worked really well, because it removes dependencies between tasks and we can work faster.

I also like being part of the design aspect of the game and when we designed the 15 sections to show and test different mechanics could add variety to our game, I helped Falven as much as I could, by designing some of the sections and discussing what was interesting in each one of them. Once we designed the sections, it was time to build and test them, so we divided the sections and gave a couple to each one of us. I did the first three:

Dystopia 2014-10-04 17-23-39-18

Sections 1 and 2

These two sections were built together because the behaviors needed were very similar and we decided to join them. The first part was to test the idea of both players facing the same enemy and them having to swap the weapon alternatively. It did not turn out as expected since everyone ends up waiting for the other to kill the turret and giving the gun to the partner after finishing. It is still nice to play, but we did not get what we wanted.

The second sections repeat the same turret for one of the players while the other has to survive with and wait for his way to be cleared. The enemies blocking the harder lane are what we call rotating enemies. These enemies shoot in every direction and they create bullet patterns that are harder to avoid. This makes it necessary for the player playing at the bottom lane to kill one of them. This adds the concept of the bottom player being able to shoot to the top lane and for that we added the transparent floor, that bullets cross.


For these two sections I created two enemy behaviors, the mentioned turrets and rotating enemies. The turrets are cylinders that rotate and shoot left when one of the sticks hits the left side. I wanted to create enemies that would give us the possibility to reuse them by changing their shape and I also wanted to be able to know when the enemy was going to shoot just by looking at it. I tried the same thing with the rotating enemies. I added the shooting bars and guns. Guns and shooting bars rotate independently and every time the match the enemy shoots. I always liked shooting patterns and I though this kind of enemy would give us the possibility to tweak them just by changing the amount of bars, guns and the rotation speed of each of them.

Dystopia 2014-10-04 17-26-10-49

Section 3

In the third section the idea is the same as in section 2, but we wanted to force to the player that had the hardest challenge (top) to advance for his partner to be able to kill the turret that was blocking his way. I also wanted to test how reusable the turret enemy was and created a pattern on paper and made it with the turret. It was easier than expected so I think we have a possibility to exploit this kind of shooting enemies. The section itself is now too hard, but I think we will readjust its difficulty and use it.

3D Conversion

Our first idea was to create a purely 2D game, but since we have no artist make our sprites, we decided in one of our meetings to change to 2.5D, where the camera has perspective, instead of the orthogonal we were using. We took the decision because we think we can make richer effects in 3D taking advantage of the power Unity3D gives us. I took care of changing every section to the new format were every object needed a depth and with Falven we re-designed how screen space was going to be divided and where the camera had to be positioned. The change to 3D of the section did not have any polishing, I simply did the change so that we could play the whole game closer to what it will be. The only “beautification” I added was removing the general light and adding it to the players, so they are easier to see and the games looks a little better.

After Prototype

Now that we have made the first tests, I think the game concept has potential to be expanded. Most of the sections we have built show that the mechanics are fun and that we can create levels on top of it. As I mentioned in one of the sections, the difficulty is a problem. Most of the sections are really hard and we have to tune hem down. How the game is going to look is also one of the challenges some of us will have to take care of. Visual appeal is not the only important factor in how the game will look, but how we give feedback about most of the things that happen in screen, weapon change, the maximum distance between players…


I am happy with how we all did during this milestone. We have been able to reach our expectations of the what our prototype was going to be. If we have the ability to focus in solving the problems the prototype has and we intelligently decide what works and what does not, I think we will be able to give a full playable first level for alpha.