I have created an army

Day 3: Basic movement

After remodeling some systems, it's now pretty easy to start building in the A*-Raycasting-Framework™. Each player has a specific unit (to be set at any desired time) that can start moving to any chain of points on the map, determinable by where you click your mouse. Now all that is required is let the pathfinding determine the points, and I'm set!

Interface

Our interface or HUD is similar to that of League of Legends, Heroes of Newerth en Demigod. It works, so why change it.

This version of the HUD is a mock-up, the final version will be build by Sjoerd Buikema who is a 2D- Artist and a friend of Tom.

Mock-up Map

Unfortunately there is not much time for level design, so we decided to base the level on one of the League of Legends maps. The level we are using as a reference is the Twisted Treeline, a 3v3 map. Although the most of the pathing will be the same, there may be some variation because our units differ in size from the League of Legends heroes. There also will be no creeps in our game.

I made this mock-up map for testing purposes and is a direct copy of the Twisted Treeline map. The final map will be added later on.

Measurements

To be able to have a good understanding of the unit and level measurements I made these visuals. As you can see the unit measurements are expressed in meters. This is because unity works in meters.

Note to self: adjust 3ds Max units setup to meters.

Mars

So the game is set on the planet Mars. The greater part the level will exist of a desert with red Martian dust. Boundaries will be made out of hills, rocks, space debris and scrap metal. Visual examples are the game Red Faction: Guerrilla and the films Red Planet and Total recall.

Day 2: grid

Since Unity (quite surprisingly, I must add) does not enjoy creating a bunch of grid tiles, I'll need to work out pathfinding in another manner. After a lot of searching and thinking about it, I'm going to use a slightly cheated version of pathfinding that uses raycasting (see very refined picture above).

Basically, the pathfinding system is going to cast rays that detects whether something is blocking passage up ahead. It's going to cast a bunch of rays to see what directions are good to go, and then continue raycasting from those new "safe" points until it reaches the target. Much like A*, but without a grid. Hopefully, very spiffy! :)

APC

The base unit is going to be a sort of futuristic version of an American military APC. Every class can be distinguished by its turret and amount of wheels. The main color is goin to be NASA white, with black and gray highlights and decals. Good examples are the Lunar 2 in the film Moon, the APC in Aliens, and the Mako in Mass Effect.

Graphics

Since we’re building the game from the ground up, we also need to create custom graphics. And more important, acceptable graphics that can be produced in a limited amount time. This means that the models have to stay low poly and there can be no rigging or complex animation. I also intent to avoid complex texture work.

That why I decided to replace the humanoid heroes with vehicles, existing of a body, a turret and a bunch of wheels. And since I’m a sucker for science fiction they or going to be space vehicles, suitable to ride Mars to be exact.

Day 1: Systems

Yesterday, I set up the primary hierarchy, implemented camera scrolling and your basic hello world things. Also, you can now click anywhere on the map, and it'll tell you where you clicked and on what. Selecting units and giving orders is just around if I can get the grid to not be completely inefficient and slow when loading :)

Game Crunching: Initiate

After midterms evaluations and necessary time in the sun, we've started the Crunch on the Final Game™. Within a month, we're going to recreate a gimped version of League of Legends! This is not at all an overly ambitious and impossible plan, but I believe that we can do it if properly pulled through, which for now is what we're doing :)

At the moment I'm setting up the basic systems (camera, lighting, pathfinding) while Django is creating a style guide and reference unit sizes. Stay tuned for more pics, and wish us luck :)

Mock-up round-up (what-up)

As I'm making these videos to find out What The Hell I'm Doing™, I'm starting to distinguish more broad categories.

I've already looked up a bunch of articles on game music. Generally, music can reinforce/break a certain mood and, more importantly, globally tell us what is going on. Tense music indicates a tense moment is incoming. Sad music when someone dies tells us that we (should) care about the guy who just got another means of breathing by Mr. Bill's samurai sword.

I think that really, really generally speaking, music in visual media serves two purposes:
- say something about the world. (time, place, setting, pace)
- show non-obvious value to stuff happening in the world. (tensity, mystery, wonder, awesomeness)

That second category is harder to do in games because you never know when stuff is going to happen. Even in linear games where you know I'm going to meet the bad guy, I can still be very bad at this game and take forever, or this is the fifteenth time Ive done this bit and Ill have it done in two minutes. So most games tend to have triggers for specific musical cues. If this room is where really fast-paced action is going to take place, I can signal that by playing something tense in the room before that as soon as my hapless victim enters that room.

That's fine and definitely helpful, but that leaves all the other rooms in the level, where potentially a lot of action is going to happen, and it is definitely worth supporting that too with your music. However, you REALLY don't know when it is happening or even how a player is going to defeat the challenge. What I think has been happening is that game developers have been looking for as much of the above-mentioed situations as possible, where they know for sure what is roughly going to happen, and fill up the rest with either silence (to build more atmosphere), or provide a more generic tune that falls into category one.

Lately, there are more and more games who try to define more generic situations to score (Dragon Age comes to mind, where they tried to separate "combat" from "noncombat").

This gets harder in multiplayer, where the room where action happens is not known. In fact, what kind of actions happen can even be largely unknown! So, if you want to score that with more than just setting, you're going to need some kind of system to determine what's roughly going on in your game.

So far I've tried to make a system for tension (the first mockup) and now level of danger. Im going to try to find a game where you do different things (Command & Conquer 4 comes to mind) and score what you're globally doing. Either way, that is the way I'll be going and Im prety excited to see whats coming up :)

Second mockup!

My second mockup is done and is waiting to be rendered.

Like the previous one, it's a movie of game footage with music based on parameters observed from the footage. In this case, I used my brother's recording of a World of Warcraft arena game (2v2). I've edited music based on the level of immediate danger to your life (or your team mate's).

- ....Whát?
During these arena matches and most other competitive formats in games for that matter, you generally do a bunch of stuff to ultimately defeat the other team(s). In some games, like Street Fighter or Super Smash Bros, you are constantly seconds away from victory or defeat. However, this is not true in all games. Strategy games have a period of resource collecting and basebuilding that last anywhere from minutes to hours or even days (curse you, Civilization!). During this time, noone is really in any real danger. Several other games also have built-in "rest" periods where nothing really happens, because players are moving to different positions, regenerating health/mana/tentacles or whatever. Conflict is not constant in all games, but instead has ups and downs (just like the tide, maaann)

- ....Whý?
First of, I think "level of danger" can be a valuable parameter to show a player, like health can be. Level of danger is not a direct parameter in the sense that health is - you don't gain 4 level-of-dangers if someone attacks you - though it cán provide some information that is harder to read from a game.
Giving out this information can definitely be useful in giving some sort of overview on what the bleep is going on (I imagine new players especially would benefit). It can also be useful in games that require you to process a lot of information at the same time, where maintaining an overview is half the game.

When it is done rendering, watch this space :)
It's rendered!

Multiplayer: check

After a week of creative Messing About™ with unity tutorials and network code, I've made a game that can host games and request a list of all available games of that type, and join it. As soon as it joins, it calls a function on all clients that for now just outputs Hello World. In the future, though, that can be "load a level" or anything else we want. Essentially, we have a framework for multiplayer! \o/

Classes update

Today, we completed a first draft of the three classes that are currently in our game, and I'd like to tell something about the process that went into designing them thus far. We'll be testing these as soon as we can to do some iterations.

We currently have three classes, aptly named Offense, Defense and Support. We generally want there to be a division (not all players can do the same thing, and so on) so we're defaulting to a standard archetype for now.

In building up the classes, we were considering what we wanted the classes to do exactly, and particularly how much. Games like Dragon Age and World and Warcraft have classes with a lot of abilities (around forty to fifty), where games like League of Legends have classes with around three to four. While incorporating a lot of abilities can add a great deal of depth and complexity, a well-balanced mix of a few can do the exact same.

Since we'll likely make the game controlled by an Xbox360-controller, we can't have more than three-ish abilities before youll run out of buttons. It also means that we can't use mouse targeting.

We decided on the following outline for all classes:
1. A main attack with a very short cooldown (under 3 seconds).
2. An ability that's useful in a lot of situations, on a moderate cooldown (around 10 seconds).
3. An uber-ability that can be saved for the right moment, with a longer cooldown (around 60)
4. An ability that's always active, like an aura, passive, or constant effect.

Also, we further defined the flavour for the three classes:
Offense: the guy who deals the damage. Enemies are scared of how effectively this guy is at killing things.
Defense: the guy to assist the sphere carrier or defend the base. Enemies are scared of how they are disabled.
Support: in charge of flag carrying and scouting. Enemies are worried of how fast this guy is.

I'll post again tomorrow with the exact abilities and why they are what they are. Stay tuned :)

Small map update

I just made a few map changes:

• front and back lanes are wider to create more moving space
• added a backdoor to the based + connected lanes
• bases are reduce to half their size
• player now spawn in front of their lane instead of inside

Prototype newsflash

It’s been almost a week since we posted or last message, but we have not stood still at all. Last weeks prototype contained not much more then basic character navigation and the ability to collect orbs. Off course we added some mechanics in the meantime. Core mechanics are in place and working, the game has a win/lose condition. Overall, the game is playable and mostly enjoyable. So we are now mainly playtesting and iterating on what we have, focussing heavily on character class abilities,balance, and the level design obviously.

That’s all for now.

Pretty Little Game Jam

A few days ago I came up with this crazy idea to do a 48 hour game jam session to come up with a suitable game concept for both our projects.
We started this game jam yesterday and have now come up with the most original and epic multiplayer concept ever (sarcasm).

Lets say we took the harassment mechanics from League of Legends, the tiberium collecting from Command & Conquer 4 and de control set from Fat princes and put them in a giant blender to create sort of crossbreed. So it’s not a totally original concept, but it is going to be fun fun fun.

So how does it work? Well, there are two sides or factions or teams (it doesn’t really matter now what you call it) that compete against each other to gain these still unnamed orbs. The goal of the game is to gather these orbs and to mount them in the predetermined sockets in the player’s base. The team that has gathered and mounted all four orbs wins the game.
Note: orbs can be stolen back from the base. Collecting orbs isn’t as easy as it sound though because the orbs position gets shown on the mini map while it is carried. Another downside is the limited field of view, you may run into an unexpected ambush.

To give the combat (yes there is combat) a bit of depth we added three classes that will encourage the player to make use of a certain play style. The available classes are: Offence, Defence and Support. The class abilities will be defined later on.

Tom is working on a gameplay prototype in the good old Warcraft 3 editor ad I’m doing not that much (yet). I guest I will be working on the level design when most of the mechanics are in place, and off course there will be a lot of testing later on.

So, what’s next? Complete the prototype, level design, testing testing testing.
We’ll keep you posted.

Articles and Video on Game Sound

Below, you'll find several summaries of articles dedicated to the function of sound in games, and what kinds of audio there can be in a game. Each article offers a different model on how to map the kinds of sounds in any game.

The past few week, I've been mostly gathering and summarising articles (the result of which can be found below this post), playing and recording more games with which to make more mock-up videos.

One mockup is already done and can be found here: UT-CTF1.wmv (warning: large file - ~400 MB)
I'll explain. What I've done in the mockup is use fragments of a single song from The Dark Knight soundtrack, and paste them under a Capture the Flag battle in Unreal Tournament 2004. The music changes based on a few parameters:
- whether a flag is taken (visible in the center at the top of the screen)
- where the flag carrier is. If the guy carrying the enemy flag is in our base, naturally that's more intense than if he's just picked it up, and vice versa.
- whether you're near a flag carrier. If you're walking next to a flag carrier (friendly or enemy), you're doing something more important than just walking around.
- where you are in the map, if no flags have been taken.

There are probably some more rules I followed and as you can see this is still a bit all over the place, but it's an indication of what kind of thing I want my end product to be / to do. I'll be making more mockups with more specific rulesets in the coming week(s) to explore further.

Summary - An Introduction to the Participatory and Non-Linear Aspects of Video Games Audio

Karen Collins
An Introduction to the Participatory and Non-Linear Aspects of Video Games Audio
(retrieved from http://gamessound.com/texts/interactive.pdf, 2010)

Audio in games is different from audio in movies. Movies are linear; games are generally not. Games are less predictable in what audio will be played at what time. This property of games creates new possible roles for audio, as well as providing problems when designing it and handling it in the game. The article constructs a theoretical framework that includes degree of interactivity, articulates problems that can occur both during design and when playing the game, and offers a list of possibilities roles for game audio that it can fulfill beside its traditional role in film.

Read the full, lengthier summary right here.

Summary - What Makes Great Game Sound?

George Spanos
What Makes Great Game Sound?
(retrieved from http://www.gamesounddesign.com/WhatMakesGreatGameSound.html)

Sound is generally recognised as an important part of games. But on what scale can you measure that quality?

Obviously, composing techniques are important in enhancing your sound files to a certain level of quality. But at the heart of good game sound stands a good idea, a central theme, in the way that all forms of entertainment each have a central theme. Without this theme, game audio can only be so much.

A technique to support this central theme is by breaking situations in a game down into separate, very specific, cues, and then support those cues as well as possible with sound, and leaving out everything that does not directly support that cue at the time. This focuses the player on the events you deem important as a game designer, and that can keep the player aware of the essence of what is happening at any time in the game.

Besides greatly focusing on the supportive role of audio, this has some other advantages. By reducing the number of sound files heard at once, memory is saved in both file size and RAM load. More importantly however, is that by supporting important game cues, it is easier to attain a higher degree of adaptivity, since the cues are all the game system would care about when determining what sound to play.

Summary - IEZA: A Framework For Game Audio

Sander Huibrechts, Richard van Tol
IEZA: A Framework For Game Audio
(retrieved from http://www.gamasutra.com/view/feature/3509/ieza_a_framework_for_game_audio.php)

The article attempts to define a clear definition of different kinds of game audio.

Quite a number of definitions have already been offered, usually originating from film sound, or some from how sound assets are handled in the game code, or where a sound originates from in the game.

The article offers a model based on what triggers the sound, and whether it can be heard in the game world or not.



The horizontal axis confers what triggers the sound. Activity means that a sound is triggered because something happens; be it in the game, by the player or by the game itself, or by an action in the interface. Setting indicates that no specific action has triggered the sound or a more general one such as being in the level. Sound in this region is there to enhance the feel of the game.

The vertical axis is one of diegesis: whether the sound takes place within the game world (can the game characters hear the sound?). Non-diegetic sounds are all sounds that do not come from the game world, such as music or interface clicks.

Combining these two axes leads to four zones of sound, which are combinations of the two properties. These are Interface, Effect, Zone and Affect (IEZA). Interface sounds are Non-Diegetic sounds linked to activity, Effect sounds are diegetic. Affect sounds are Non-Diegetic sounds linked to setting, Zone sounds are diegetic.

This model is mainly a model for designers to determine what kinds of sound are in the game. It also provides some information on what kind of sound to make to get a certain effect.

Summary - The Sound of the Early Warner Bros. Cartoons

Scott Curtis
The Sound of the Early Warner Bros. Cartoons

Traditionally, sound and image have always been pretty closely synced in cartoons. At first, this was for economical reasons as music in cartoons was usually an adaptation of compositions that Warner Bros wanted to sell or show off. Technical issues also played a part: it was not possible early on to pre-record separate tracks for music, sound and dialogue, so the orchestra doing the music would also need to create sound effects and whatever else was needed.

The result is that very often, the animation in cartoons syncs to the music and vice versa. The music itself is not diegetic (doesn’t come from inside the world), but characters respond to it anyway. The article therefore suggests another way to describe sound; based on how it relates to the images: isomorphic and iconic.

Isomorphic sound is audio that matches the rhythm of the action and images. If a character walks quickly, the music is quick. If he pauses, the music stops.

Iconic sound is audio based on an analogy with the action. Iconic sound provides feedback on an action, but does with sound that only has some relation to the action, not all. For instance, a cymbal crash can accompany someone being smacked in the face. While a cymbal crash does have matching components such as volume, shock and so on, its sound is still a symbol for what is happening.

These definitions are not mutually exclusive; a particular sound can be both. Where the line of diegesis is blurred, this can be a useful model to define audio. Isomorphic and iconic sounds do not just occur in cartoons, but in other forms of entertainment as well.