ERA – Week 7 of Production

This week I mainly worked on a myriad of smaller tasks. Either to patch up or polish existing behaviors or to add new smaller features to the game.

One thing I did was to make sure all renderers (drawable parts) of an object responded to the fog of war. So if an object is in the fog, it and all its GUI layers will be invisible to the enemy teams camera.

I also added a basic GUI setup to the commander, similar to the champion’s. This GUI only displays the commander’s spell cooldowns and total gold as it is, but it still feels nice to have a solid GUI setup for the commander that displays what it’s supposed to display. Some of the other things I worked on this week was applying the new graphics to our map and making the new victory/defeat screen.

The most challenging task I worked on this week was definitely the targeting and rotation of the new tower prefab.

The tower picks up it’s targets from the enemies that enter its attack-trigger sphere. once it has chosen a target it must rotate towards it before it can shoot a projectile. The previous tower we had had only two parts, a head and a body, and the entire head rotated to face its targets.

This new tower our graphical artists has made is significantly more sophisticated. It comes with three parts, a body, a head and a barrel that is attached as a child to the head. The head (along with the barrel) is to rotate only around it’s y-axis, while the barrel is to rotate around it’s local x-axis, set by the direction the head is already turned.

I didn’t manage to get this setup working perfectly. As the barrel is a child object of the head, any rotation of the head will also rotate the barrel and thus deciding the barrels own rotation (independent of the head) is very hard. I did manage to simulate the effect quite well though by letting both the head and the barrel turn smoothly towards their target at the same time. This meant that the barrel got slightly ahead of the head, but it was adjusted automatically once the head stopped rotating.

ERA – Week 6 of Production

This week I have worked mainly on the fog of war and the minimap. It has been a pretty tricky process to get it all to fit together.

For the fog of war setup we have worked with an external tool from the unity app-store. This has made it possible for us to get the fog working decently quite fast, but it makes it harder to make adjustments and establish connections to for example the minimap.

The first thing I did this week was look at how the fog of war was implemented. It collects a list of clients (players enemies etc.) that produce vision for their team; it then applies this vision as alpha settings on the pixels to a small 2D-texture. This texture is then applied via a shader to a plane covering the entire map that is positioned between the world and the camera. We want our fog of war to be not completely black, but actually revel the world that is in shadow as well, so therefor we have to make sure to disable all rendering for all characters that are under parts of of the fog of war plane that isn’t entirely transparent.

Having this fog of war texture available was good for me when I was working on the minimap. Unfortunately it turned out that the texture’s colors was inverted before the shader was applied. The areas where the team had vision was dark and vice versa. What I had to do was to go into the code and invert the colors that was set to this texture. I also had to go into the shader and invert how it applied the colors of the texture to the plane. Once this was done though it was easy to simply place a reference-sprite of this texture over the minimap. I could then create minimap GUI representations for all the characters in the game. Converting the world coordinates to minimap positions for these was pretty tricky but after a lot of trial and error I finally got it right.

Towards the end of the week we realized though that we wanted the minimap and the camera angle turned 45 degrees. So this created quite a bit of extra work of refitting the minimap that was pretty tedious to be honest.

ERA – Week 5 of Production

This was the week of our Alpha. Unfortunately it’s also been a week during which I’ve been sick with a cold, pretty badly the first few days, and it never got completely well. So the the work I’ve done has suffered for it.

What I’ve done has mainly been to keep working with the floating GUI, now for structures (towers, barracks and generators), and also to add base structures for each team that will end the game once destroyed. This enters an end game scene where the winning team is displayed.

Working with the structures was a bit of a hassle as they were only represented visually on the client-side of the game,in order to attach health GUI to them I had to make sure their attributes where instantiated and updated over the network. In this process I also wrote the function to remove buildings whose health had reached zero.

Once this was done I added another type of structure, the base, and attached a script to it that would end the game once it had been destroyed and make sure to record the team opposing the destroyed base as the winners.

The final thing I’ve been working on this week has been to update the towers attack so that it deals splash damage once its projectile hits the ground. I’ve also adjusted the aiming of the towers to be more accurate.

ERA – Week 4 of Production

This has been another tough week with much of the focus going towards trying to fix malfunctions and crashes in unity. Monday my entire game inexplicably crashed after I entered the game scene, we found no clue to the cause of this, and everything was working fine on the other ends of the project so what I ended up doing was removing the entire project, after making a backup, and then download it again from the asset server, manually copying and pasting the backed up code I had lost. The second problem arose when the plugin we use for handling GUI, Daikon Forge crashed Unity for me due to encountering corrupt files in our project folder. It took some while to locate them all and get someone with working copies of them all to refresh them on the asset server… I guess Unity just doesn’t like me very much. Setbacks like these get incredibly annoying when all you want is to be able to ever increase your productivity to reach the deadlines.

What I’ve been working with besides these issues is mainly the general network setup and GUI updates for all clients. I’ve also introduced death functionality for the champion players, tracking their HP and disabling them for a set respawn time while they are dead.

I’ve implemented specialized GUI that will be instantiated only on the owner-client of a champion that shows cooldowns of abilities and health and also darkens the entire screen and show a re spawn timer if the champion is dead. I’ve also created floating GUI health bars that will hover above all actors in the game. These are instantiated and updated on every client; and they will track the team tag of the actor they are attached to, so a player belonging to team red will see the health bars of all red actors as green, while all blue actors will have red health bars, and vice versa. In doing all this I’ve also had to make a substantial update to the soldiers implementation over the network, so that all their attributes, health etc. can be updated correctly all over the network once they are affected by spell effects.

ERA – Week 3 of Production

This week I mainly worked on the player input class we set up to handle the input the player gives to control a champion that is being updated on the server. I also made sure the champion and its GUI is updated correctly for the network.

The setup we chose for our network was to have the mother-instance of all game objects placed on the server, and also mainly updated on the server. Only necessary data like object’s positions and rotations are then sent to all the clients so that the game can be updated visually on each client.

This setup require a light touch though as each player needed to be able to send their input to the server to update the individual champion instance they are controlling, at the same time the server needs to update each individual champion based on that input and then make calls to each client in order to have each champion instance updating one each client connected to the server. An additional call also had to be made from the server back to the owner-player of the champion in order to have their GUI update.

Getting all this to work was very tough for me; not only because the setup is quite complex, but also because the networking syntax is restricted. Trying to set these functions up I ran into many blocks I could only solve after some research of network solutions.

In the end though I feel getting this setup on place may have been worth it, even though it ended up taking far more time than I would have wished. Having this network setup in place means we don’t have to fear that two players end up playing two different versions of the same game due to a miss-sync of the network; as everything essential to the game functionality is run and updated only at the server.

ERA – The Struggles Continue

So week two of production has come to an end. It’s been a tough week with many delays and unforeseen obstacles, but I still feel we have managed to get far. Our pre-alpha was due for today and while we have not reached all the goals we set ourselves for it, I feel we have reached enough of them for there to be no need for despair. (Yet)

This week I wrote a generalized system that handles the interaction between spells and actors within the game. Me and the other programmers set up a system where any object within the game can either have the tag ”Team Red” or ”Team Blue”, then we made it so that objects would act over the different Layers:

• ”Champions”, ”Soldiers” and ”Structures” : for actors with rigid bodies that collide with each other.
• ”SpellTargetAll”, ”SpellTargetChampions”, ”SpellTargetLiving”, ”SpellTargetStructures” : For spells that are triggered only by the appropriate actor-layer.

This put together means that a champion can create a spell that will only interact with i.e. the enemy teams champions. I created an ”OutcomeCalculator”-script that automates this process, and also applies the correct effect; such as HP-loss, on the actor hit by the spell.

I’ve also worked a great deal with the GUI and animations for the champions this week. For the GUI I used an external Unity-tool called Daikon Forge. Me and Daikon Forge got off to the worst possible start when a weird bug in Unity made it so that I could not select the GUI objects I created in the Unity editor. After hours of obscure Google searches, several reinstalls of both our project, Daikon Forge and the whole of Unity. Finally after having almost given up we found a post describing something similar and of course the solution was incredibly simple, yet impossible to guess at. It was a pre-set Layer in the Daikon forge editor named ”GUI” that failed to connect with the Layer we had defined in Unity named ”GUI”. The layer settings of Daikon Forge simply had to be removed and set again manually.

After this horrible start, though; Daikon Forge turned out to be a really smooth tool to work with. I managed to quickly create polished GUI that linked up with the champions health and abilities and their cooldowns. The character animations was also a joy to work with, It was simple and intuitive to set up the triggers that would connect one animation with another.

Finally the merging we did of our branches of the project has made it so we have a nice little pre-alpha, or maybe pre-pre-alpha (or… you get the idea). We have a champion with a nice animated mesh and GUI that can activate three unique abilities on cooldown (a ranged missile, a strike and a dash). These can be used to fight the soldiers that spawn automatically from barracks in the game world. We also have a network that has not yet been connected with all of the game, but have gotten four champions spawned by different players working together.

This is not quite the alpha we had planned for; lacking the commander overview, the fully working network as well as the fog of war. But it’s definitely not nothing and with the possible exception for the network completion, which it is hard to get accurate time estimates on I feel we are not more than a few days behind our planning.

There is hope yet! 

ERA – First week of production

This Monday Escape Reality Studios started producing the game Eternal Resonance: Area E.R.A;  a new type of MOBA/RTS hybrid. For more info on the studio as well as the project, please check out our Facebook page: https://www.facebook.com/EscapeRealityStudio

My roll in this project is primarily as a Unity programmer and secondarily as an assisting designer; Daniel Svensson is our lead Designer.

As Unity is a game development tool I have not worked with before; this first week has been quite slow. I have worked hard getting accustomed with the editor of Unity and researching how various programming tasks are best completed  using the Unity script setup.

The main artifact I have been working on this week is the champion; champions will be controlled by the MOBA players of the game, and will handle much like a League of Legends Champion or a Dota hero. I have set up a general champion class to which I can attach the various abilities the different champions will have. So far I have created basic abilities (eg. ranged bullet, mele strike, dash) for the first champion of the game: Copperman. I have also set up a Unity Isometric Camera that can follow the champion and can be moved using the mouse cursor. I have also made it so that the champion a player controls accepts the input from that player for activating abilities as well as moving to the location the player clicks.

This week the three programmers; me, Inge Olaisen and Henrik Andersson have also set down together to try to work on an overarching structure for the project. We have divided most of the game objects into actors (champions, minions, buildings) and spells (bullets, attack effects) so that we can create the general scripts that will handle the interactions between these.

Overall I’m happy that I have gotten some flow going even though I feel it is building very slowly due to the barriers of learning and mastering a new environment: Unity.

Final Sprint

During the last week we have worked heavily on getting the game presentable. Fortunately for us, the remake of the system has worked well when testing. We have gotten much feedback that the game itself is slow though, so I have been thinking about what can be done to fix that. Listed below are the ideas I come up whit that I feel would have a positive impact on the game experience and pace:

• Have the players draw an event card at the start of each round instead of at the end. (This makes it less likely that a player can be certain to win even before their final turn.)
• Make blowing breaches and building monuments instant; similar to trading. (This increases the pace of the game slightly and makes collapses less annoying.)
• Remove ability to blow blockades. (This removes the option for players to sabotage heavily and basically bringing the game down to snail speed.)
• Add Sabotage event: “Your dwarf subjects have tunneled into position and are ready to collapse a passage – move one dwarf (of any clan) through any passage of the room they are currently in and place a blockade tile over that passage.” (This would effectively replace the blowing of blockades. It has the advantage of not costing the players dynamite, and also allowing players to target any room to focus on bringing the leading players down. With a sabotage event we as designers can also decide the frequency at which sabotages can occur which I believe is a good thing.)
• Add ability to scare of a thief by discarding one stick of dynamite. (This makes the gem stolen event less fatal for players and makes an event that can actually be prepared for.)
• Give two dynamite inventory slots. (Together with the other changes this would make it easier for players to deal with thieves and blockades, it may also encourage dynamite trading.)
• Make mushroom event give the character the ability to make two moves during their turn. (Way to many of the events in the game does nothing, making the mushrooms give players a slight boost would both increase the pace and make it so the game feels more eventful.)
• Remove Gem Find event; add Magic Gem Finds event instead. (Sometimes magic gem finds completely swings the game by giving an almost instant monument. This would decrease the impact gem finds can have, and also encourage player interaction and trading.)
• Add Gem Transform event that turns one of your gems into any other. (This would be another positive event that is not over powered but still makes flipping event cards more fun.)
• Add Event Room Tiles. Once one of these rooms is explored, the player who stepped into it immediately draws an extra event card. (If most events are positive this will give a slight incentive to explore new tiles instead of only exploring when a passage between two points is needed. It also increases the pace of the game and makes it feel more eventful.)

I would definitely like to test all of these changes. Together I think they can have a huge impact on the pace of the game, the dramatic curve and the fairness players perceive; which all are issues that our players have brought up.

Week 43 Reflection

This was another tough week for us. Many of us (me included) we’re sick and away during the start of the week. When we all finally got together at Wednesday we had some major issues facing us. Both from the testing session last week and from the meeting we had with Marcus Monday we learned that the game we had simply did not work. The biggest issue we had was perhaps with sabotage; it was set up so that it was costly in resources for the one who performed the sabotaged and drained much resources for the target of the sabotage. If all four players of the game got into sabotaging the game would basically come to a standstill and all resource flows would stop. If three players got into sabotaging and the fourth player stayed in her/his own corner, avoiding all player interaction, that player would win by a landslide. This system felt unfair to players and was really not fun as it made the most tactical players interact less with each other instead of more.

Another problem we had was with the resource system. The victor of the game was determined by the first to reach 20 resources. But these were the same resources you used to build mines and saboteurs and new workers. This made it hard to know what the best strategy of the game was. If you never bought anything, but simply used your first worker to explore and gather resources you might win. This is really counter-intuitive and definitely not how we intended the game to be played.

All in all, it’s safe to say we all felt quite uneasy when our meeting Wednesday started and we knew we needed to somehow fix these issues. For some time we just threw out ideas; these ideas where usually cut down immediately by the group on the grounds of not solving any of the problems we were facing and sometimes on the grounds of creating a whole new range of problems. Needless to say, our spirits were quite low. Some of us wanted to change something drastic, while others wanted to take smaller steps to be able to test what worked with each iteration. It didn’t really matter though as we had no strong ideas for what we wanted to change, and how that change should look.

Eventually it all collapsed when we started screaming at each other. I think I was the one who managed to save the situation by suggesting we cut down features to the very basics of our game and then take another look at our aesthetic goal and work from there. We scraped the entire sabotage system and resource system. We went back to the aesthetic goal of being an explorer in a struggle for resources, and our first order of business was to create a new resource system. We settled for a system where the resources you got would not be able to buy you more income or additional characters, but would only work to get you closer to the victory condition.

What we eventually got was a game where each player controls two characters. There were four types of resources; A, B, C and D. The different resources where located in the four corners of the map, and two different types were needed to build a victory structure. The first player to build three victory structures of different types would win. Sabotage was a lot more subtle now as players could block each other from building structures, but not directly steal or destroy what others had build. To fill the void we introduced trading into the game. 

Players can trade any resources with each other if their characters are in the same room. To further encourage trading we also introduced a trading resource which the players could get from their structures. A trading resource could not be used to build structures, but if it is traded the player who receives it would be able to swap it for any other resource. (Inspired by Pokemons evolving only when traded).

With these changes the game felt much more tactical; players would have a clear goal to work towards and clear available paths to reach that goal. Player interaction also became much more meaningful as trading is heavily encouraged by the game and because sabotaging isn’t so present and is much more tactical when it occurs. For the first time we actually enjoyed the game when we tested it during this iteration!

Finally we have used the rest of the week for testing and iterating and adding some flavor to the game. Our setting is in a cave and we changed the resources to gems of emerald, ruby, sapphire and topaz. The trading resource became magic gems. The players are controlling the king and queen of their respective dwarf-clans and they are racing to become the first to build three gemstone monuments!

 

Week 42 review

This week we made our first prototype of our game. We focused heavily on or two goals; to have an interesting exploring mechanic and to generate a race for resources between players.

Originally we had an idea that was very focused around a cave. This week however we scaled most of that back in order to get base level systems we can test on their own merit. This has made our system much more modular, the theme of exploring as part of a race for resources can be used in many settings other than mining a cave. One example we imagine is the colonialism era where the European superpowers competed through exploration for the rights to various resources. You could also have completely fictional settings if you imagine the resource-race aspect of Star Craft or Heroes of Might and Magic singled out.

Having the first prototype feature only the necessary elements; we can now test and polish so that these elements become more powerful and stable if we for example want to go on to build a cave-based game using our system.

We do still have much testing and revising to do though, as our first testing session showed us that the sabotaging features of our game works poorly. Sabotaging in the game is basically just a drain at this point both for the player performing the sabotage and for the subject they attack. This lead to our testers feeling that the optimal way to play the game was to avoid player interaction altogether and focus on exploring your own corner.

This, of course, is unfortunate. What we really want in the game I feel is a curve looking somewhat like the one in Settlers, where the players experience steady growth towards the goal of winning the game. This growth, once there, cannot be removed, but players will use part of their resources to increment their own progress towards the goal and part of their resources to slow down other player’s progress. Getting this balance right is incredibly important. You don’t want your game to end up in a look down the way we felt abduction tended to do, and at the same time you don’t want the players to feel their is no meaningful interaction between players to be had in the game.

So to recap; we have much work to do, but I think we have a good foundation to work from.