Realm Wars Dev Diary

RW Dev Diary #3
A change of view



Work on this latest phase of Realm Wars kicked into gear in early January. This was due to two things, the first being that our team was pretty bagged after getting a build ready for IGC to demonstrate and as such needed some time off, the second being that December is essentially a write-off month due to all the distractions of the holiday season. As such, many of us were eager to get the ball rolling again and get back to work on getting Realm Wars 2 a few steps closer to that ever elusive "completed" state that we are aiming for.

One of the first orders of business was to complete our upgrade of Torque to version 1.4 (since you may recall from the previous developer diary that we were using a slightly modified version of 1.3). This also allowed us to take advantage of an upgrade to the new Torque Lighting Kit (TLK) that John Kabus had worked so very hard to integrate into Torque 1.4 (great work John). This allowed us to take advantage of some great new features in Torque that a helped to speed up our development process, particuliarily the ability to load changes while the application is still running was a huge benefit towards production (and keeping one's sanity).



With those backend changes completed it was time to really work on the changes that we needed to integrate into the game. Many of these changes were either things we wanted to do, things we saw while playing the game and feedback from GarageGames with regards to what they though would be good for moving the game forward.

Of all the changes that we did, the following two were the most significant in regards to our development and adjusting how the game felt to play. The first was to shift the game from a first person view to a top-down approach. The second was to integrate support for game pads. This overall would give Realm Wars a faster more tactical feeling game that also presented itself as a more unique application.

Now this might sound easy, but fundamentally they are huge changes to integrate. Why? Well primarily because those two elements dictate a lot about how your game will play, how it will look and how it will feel and present itself to the end user. This is something that we as a team wrestled with for quite some time and we really broke the problem down into a couple of possible solutions.

Solution A Fixed Camera. A camera is positioned at a certain location above the player and always keeps the player in the center of its view. The player then manipulate his/her character based on inputs that are relative to the game world. So for example, up on the game pad would move your player up on the screen.

Pros:
- Where you point on your thumb pad is where you tell your character to move.
- Gives a better tactics feel.
- Very easy to setup effects since you know that the player will always view it the same.
Cons:
- It is possible for geometry to hide objects or items, so a lot of care and effort would need to be put in to ensure that nothing is allowed to hide out of view.
- Aiming can be a bit tricky since you really only have 8 major directions a player can accurately hit on a controller.
- Game can feel a bit flat and lose its sense of depth so the art becomes less awe inspiring.

Solution B Local. The camera is positioned above and slightly behind the player's character. This camera is setup to always follow the player and the player interacts and moves in the game world relative to their characters local position. So for example if the player presses up on the game pad they would move the direction their character is facing. If the player turned their character to the left, both the player and the camera would turn with the player.

Pros:
- Gives a great action sense.
- Logical movement for a player since everything is local to your current view.
- Really gives you an opportunity to see all the art, lighting and features in action.
Cons:
- Required some custom camera code to ensure that the camera stayed at a fixed distance, followed the player and did not clip through anything.
- Aiming can be tricky because the player needs to properly aim at a target.

What is rather interesting here is that at this same time 21-6 was already well along the way at doing something similar on their great action/arcade game "Destroy All Robots" (which some of you probably saw at IGC). Destroy All Robots uses the Fixed Camera route and because we have a great working relationship with the guys at 21-6 we had a great opportunity to sample what they had done and relate it to the work we were going to do with Realm Wars. As such after a lot of research playing and analyzing games with similar control styles and setups, the team decided that going with the "Local" system would feel best overall for Realm Wars.

With a game plan in hand, a list of tasks to complete and an eagerness in our mind to see what the game would play like top down, the team went to work. Over the next month we slowly gnawed away at our features list and gave input to one another on how things were going via local testing. Things looked good, things felt good, so what possibly could go wrong? The answer to that was soon about to hit us in the face.

With the majority of our features integrated and ready for testing the team decided to do some multi-player testing to see what the game was like. We had all played locally on our own machines and we didn't have any issues and as such we were grossly unprepared for what we would find. What we had managed to create wasn't fun, in fact it was a long way from fun and in fact was incredibly frustrating to play! Honestly, take a look at these complaints that we logged:

- The camera is way too close to your player. This makes it nearly impossible to really get a feel for what is going on around you or get into combat with another player. (Note: In fact it was so bad that I can remember one particular incident where Markus and I ran around one another for a few minutes using only our radar to know we were getting close).
- Camera feels too lagy when moving
- Movement with the controllers felt a bit funny. This was due to the fact that the players upper body is twisted to the right a bit for the rifle and melee poses and this in turn creates a bit of a visually illusion in regards to which direction you are actually pointing.
- Game visuals are rather bland. This was primarily due to the fact that the test mission that we were using was a modified version of the mission we had at IGC. Although that mission was OK in a first-person view, it really looked ugly when all you had to view was the terrain and the occasional low poly DIF. Personally speaking this is part of the reason why I hate relying on terrain to do everything for you in a game.
- Hard animation switches. Well this was more of a problem with Torque, there aren't any decent options available off the get-go to have smoothly transition between some sequences, the engine just adds, deletes or switches between them as its told.
- Player movement didn't feel right. Not because of the movement speeds themselves but because of the uncanny ability in Torque based games for players to slide around a bit on the terrain, which feels a bit unnatural.
- Delayed projectile particles. This is another glorious Torque issue that comes from the client/server update between weapon projectile particles. As such the faster your projectile travels in game, the more of a chance you will have of it drawing the projectile trail late.
- Impossible aiming. Ranged combat was just too difficult now, especially on open terrain.
- Team designations. As we moved the camera back further it made things more and more difficult with regards to being able to see the team textures that were on the models. Eventually it got to the point where you could only tell the different player models apart. (Keep in mind too that the camera is too close right now to see the mission area, so it's a double wammy).

So we had some issues, sure a lot of them were our fault and it really goes to show the importance of testing both single and multi-player features as you develop, but irregardless the end result was that the game was simply not fun.

The team was pretty dejected at this point. Not only had we worked so hard to get all these changes in, changes that we were initially questionable about doing but had good faith in trying out since they came from some pretty experienced sources. But also because this was the first time in our development that we felt that we really didn't hit the nail on the head the very first time through. Even in the past when we always felt that even if something was wrong it was at least on the right path. This time though it was just wrong and no where near what any of us were expecting or even wanted.

I can personally remember sitting at my computer for 30 minutes staring blankly at the screen at this god-awful build that we had done, wondering what we had done, where we went wrong and how the hell we would fix it. Worse yet, the team was beginning to question whether Realm Wars was something worth continuing on since was feeling like it was something none of us really wanted to play. So our solution was this, if we cannot find a solution to the problem, since most of it was due to the implementation that we had done, then we would say to hell with the top-down approach and return to FPS. Our deadline... a weekend.

So what could we possibly accomplish in a weekend to make it a better experience to play?
- Create a new level/mission that is essentially a dungeon with rooms and hallways only. If we confine the space and the area that the player has to run around it, it should make the game easier and more enjoyable to play, aiming should be a lot easier to perform and best of all we can make the game environment look really nice.
- Add more Z to the camera distance from the player, this way you can see more of the world around you and interact with it better. Note: We also added the ability at this point to cycle between predefined camera locations so that we could better test camera angles while in game. This way if you wanted a pure top down camera you had it, if you wanted behind the player you had it, same with any angle in between the two.
- We reduced the projectile speeds of all the ranged weapons. We knew from experience this would make the projectile trails appear better and since we are playing in such a confined space no one would know that the projectiles don't travel as fast.

Since we were all kinda pissed off at the game we didn't put our full effort in here and managed to bang out these changes in only a day. Oddly enough for the last ditch attempt, we ended up finding something that we felt that we liked a lot more. Even with these very simple changes in. The game felt a lot more fun, it definitely felt like it had a style to it and we could really see how with some more additions it could maybe, just maybe come together.



From here on in, we kept plugging away at the game, slowly attacking our initial problems piece by piece and adding and refining features until we became more and more happy with them. All in all we added various features such as:

- Orientation decals. This decal simply helped tell you which true direction you were facing so that you wouldn't get fooled by any of the animations that were playing on the model.
- Team decals. Very similar to the orientation decals, except that these decals were unique for each team and also had a unique color blended into them to match their team. This way if we had the ability to keep the decals very dynamic and reusable with minimal work.
- Movement limits. Markus added in a whole bunch of code to prevent the issue of player sliding which would occur if you tried to strafe from a run.
- Controller input. Markus added in some new code that would allow us to assign and use an exponential curve with a scale value to sample the input that we were reading from the thumb sticks. This allowed the game to feel more forgiving to player input so that you weren't always trying to zig-zag your way around.
- I created a whole new dungeon DIF for us to use entitled the "Forgotten Temple". The goal here was to create a cool looking environment that felt very complex and cool to look at while still being a bit of a challenge to play.
- New animations were create for weapon switching and to wind many of our current weapon pose animations in and out so that it didn't feel like the game would jump between them.
- Markus added in the aforementioned ability for us to quickly switch between camera angles so that we could test out and see if there were other angles that we felt worked better in the game.
- Markus also created an alternate game pad control style which is pretty cool. Initially we just had a console FPS method, but this new style that Markus created (which I dub "left-stick") allowed for you to control both the forward and back movement and your rotation with just a left thumb stick (which I will admit is a lot of fun to use).

At this point the game was really starting to shape up and feel like a fun product once again. I am so amazed that things turned around so fast within a few short weeks, going from something we hated to play to something that we really liked and were excited once again to work on.

With things going smoothly we decided to pull together our CVS build into a release that we gave a couple of close associates the project. The main goal here was to get some feedback on the controls and to also ensure that we weren't missing or overlooking something, which can easily happen when you get so close to a project. The feedback that we received was pretty positive though there were some thoughts and comments from people that they would like to see what the game was like using a Fixed camera and controls that were similar to Destroy All Robots. There was also the suggestion of restoring the FPS gamepad control options and how problematic that aiming was to the game (which is an issue we know of and had a solution on the drawing board). All off these suggestions were pretty easy to integrate with a bit of work, the difficult one though was getting a camera and control system in that was like Destroy All Robots. Why? Well the simple answer is that we were not using the stock TGE camera system anymore, Markus had so heavily modified Torque with what we call "the Custom Camera" that the old system wasn't too functional.



At this point I am sure that any of you who are reading this are probably thinking that you would make the necessary changes to the current build and that would be it. With us though we really wanted the ability to sample all of these changes and options in-game and on the fly. Our big worry here was that we didn't want to run into the "grass is greener on the other side of the fence" syndrome where you make some changes and think they're awesome and without having a valid comparison. This would in turn allow us to get a fair and honest sampling of different camera angles, different controller setups, different control schemes and even swap between the Fixed and Local systems! Sure this seems like a lot of work, but when you want to try to get the best dammed camera and control system for your game you need to do it.

With all this work done, the CVS build feeling rock solid and a desire for us to get this thing out the door and get some much needed feedback from people outside of the team, we compiled together a test build for release. This build though was only privately available to GarageGames, community Associates and special friends of MGT (which explains why most of you probably never heard about it until now). To help facilitate this test, Adrian setup for us a PHP Survey system so that we can gather anonymous feedback from our testers.

So with that all said, where are we now? Well to be perfectly honest it's a fork in the road and which path we take depends on how the cards fall with regards to funding and publishing. The game feels good, the feedback we have received will really help it move further and there are a few more things we want to do to finish the game. But as much as the team loves working on Realm Wars, there are also unfortunately paying gigs out there and in many ways its foolish for us to continue to put all of our eggs into one basket if we are unsure that this work is going to go where we need and want it to go.

Hopefully I will have more news to share on this in the future but for now I will have to leave you all hanging.



Note: Before anyone asks, no we have absolutely no plans on releasing any of the source files for the code and work that we have done. There are numerous reasons from this from contractual obligations, code we have licensed and a desire to evolve our assets for use in other projects. We hope that you understand this.