Game Design Blog #1

And hot-on-the-heels of my Game Engines blog is Game Design! For this one I'm not totally sure what to do, so I'm going to play it safe and talk about the recent topics and how they relate to one of the few games I have played recently: Tales of Xillia 2! The two topics I'm going to focus most prominently on are the controls and the UI.

First a little summary of the game: Tales of Xillia 2 is a role-playing game with instanced, party-based combat. When the player enters combat they are in a circular arena with a character they control and up to 3 AI (or player controlled) characters. Now on to gameplay!

The controls of the game, on a PS3 controller. The game itself switches between two states (not including things like menus and not going into a LOT of detail): The overworld state and the combat state. The overworld state is when the player is able to run around freely (i.e. towns, fields and dungeons), obviously this has been simplified but that's more to cut down on length. In this state the player can encounter monsters (in the latter two) and controls by using the left joystick to move their avatar and the X key to interact with objects. The player can then transition to the combat state by colliding with an enemy on-screen and in this state the controls become drastically more complex. The player moves their character by moving the left joystick left or right (the player is on a fixed axes for the most part), but can press L2 to enter a 'free-run' mode where they can move in any direction on the field with the left joystick. The player can attack and guard using the X and square buttons respectively. The player can also use the circle button with the left joystick or the just the right joystick to activate special attacks. This is more or less the basic gameplay (not going into the depth of special stuff). Now a quick breakdown of how intuitive the gameplay feels!

The overworld gameplay doesn't have that much that needs to be said about it. It worked pretty well but it wasn't exactly special. The gameplay in the combat state though flows very smoothly, the basic attack handles very smoothly and the idea of tying the special attacks to the movement in a small-but-unaffecting way actually helps make the gameplay much easier to handle without breaking the flow. I don't think that there's anything that could be done to improve the gameplay as it requires the least amount of movements on the players part to change actions.

One gameplay mechanic for combat that I had previously omitted was the ability to partner with one other party member to work with them in combat (i.e. the character can block to stop you from being attacked from behind or flank an enemy you're fighting). The way a player links with another character is by pressing on the D-pad in the direction of the character's icon on the HUD. My reason for listing this is separately from everything else is to tie into the....

UI! The UI for the overworld state is pretty straight forward with a mini-map that shows where the player and other things of note are, as well as the option for pop-ups like objectives. It's very simple to understand and isn't intrusive, so it gets a pass! The combat state UI is very much geared towards melding with the controls by having it so that important meters are on the left and right while the names and stats of the 4 party members is laid out in a diamond on the bottom-center portion of the screen. This last part works very well with the the ability to link with the other party members as they line-up perfectly with the D-pad so that it's very intuitive. Overall, the UI is very clean and easy to read (for me, anyway). But I'll let you decide by finally providing a screenshot of the game!

And I'm not going to be going into super-fine detail on everything (I'm sure you can see that there are quite a few finer detalis) but that will just entail going into a lot of depth that you learn over-time.

At the end of the day, the game is very well-designed and friendly to both old and new players. Though far more importantly than that: The game is FUN!

And with that, I'm going to call this blog done...Namely because I'm rambling.

Thanks for reading, cheers!

Game Engines 1: The Source

Alright, after a long delay I'm back! Jumping right into this I'm gonna be talking about one of my favourite game engines for this new class, the wonderful engine that has given us so many games by Valve: The Source Engine! I'll be doing a quick-review off it from its beginnings to its future while going through some of the special features implemented it as time went by, but first I'll give a quick summary of what the engine is!

As mentioned before, the Source Engine is Valve's in-house game engine. It was designed to be used for first-person shooters (a genre which Valve excels in) but has been successfully repurposed to be used for other genres (such as top-down shooters like Alien Swarm).  It evolved from the GoldSource Engine which was built off of the Quake Engine.

Now, there's something rather special about the Source Engine in relation to our class: It is made entirely in C++ (well, C++ and then it uses OpenGL and DirectX3D for shaders). This means that there are only two things to stop a UOIT student from making an engine as powerful as Source: Experience and manpower. I consider that fantastic motivation to start learning the ins-and-outs of engines to make my own. Anyway, on to the features that were added!

So the Source Engine is constantly evolving with new games adding new features to it. For example Left 4 Dead 2 added dynamic 3D wounds for the engine, these essentially being a unique way of creating wounds on characters that would change the appearance of the model in a drastic way (i.e. arms falling off and having the bone sticking out). The game DOTA 2 introduced keyframed vertex animation to the engine and then there's a much longer list of features (with things like blending skeletal animation, inverse kinematics, dynamic water effects, etc.). The development of the engine does not have them keeping track of it by versions like you would typically see (i.e. version 1.0.0, version 1.0.1, etc.), instead simply updating in smaller or bigger ways as required.

Looking at its design, the Source Engine has the capacity to constantly grow as time goes on and add new features. Though this approach would ultimately prove a bad idea as new techniques and design patterns are constantly emerging and the base code for the engine simply could not easily be altered without potentially ruining the engine. This seems to be something that Valve has picked up on as they are currently developing (or, if rumors are to be believed, have already released) a Source Engine 2. This engine should see an overhaul to the lower-level architecture of the system so that it could run much more efficiently and have greater potential than the previous one.

On a semi-unrelated note though, the Source Engine is also a great example of how powerful a game engine can be in the right hands. Valve has used their engine not only to make games but also to make offline tools such as the Source Filmmaker and Hammer Editor which they could then use to improve their production pipelines. The Source Filmmaker allows for easy development of in-engine cutscenes by allowing them to create a scene in the engine like you would with Maya, but it instead uses the engines lighting systems. The best example of its potential is the Meet the Team videos for Team Fortress 2. Meanwhile, the Hammer Editor functions as the company's in-house map editing tool, Not only does it allow users to create the shape of the map, it also allows them to set up things such as game triggers which the engine can then use to construct the full level experience.

Overall, the Source Engine is a fantastic piece of technology, in my mostly biased opinion. Unfortunately, I have not ever used it so I could not make any comments on how user-friendly it is or some of the downsides it has developing for it. I hope you've enjoyed reading this rambling blog!

Cheers!