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.
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:
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.
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.
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.
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.