The Heavenly Sword team have been posting up a number of blog entries over the course of the last few weeks. Finally my level design blog has been posted:

http://blogs.ign.com/Heavenly_Sword/2007/09/10/65817/

Hope you enjoy :)

Blimey! I haven't posted since May? Damn that was a tough few months of Beta then Master tomfoolery. Then August arrived and I jetted with the missus and the little one over to Canada for a month long break. That was very much needed!

Finally back at work. So the game is done, and we are on the steady count down to release on the 12th. Some reviews have come in, averaging around 8/10 - which is really good. I'm really looking forward to seeing how the public received it.

It's been a while since the last post, things have been busy at work what with Beta rearing its ugly head. Anyone who works in the industry knows just how stressful the final stages of game development can be, but at least there is light at the end of the tunnel and you can finally see the game coming together.

Now that the final stages at work at coming to an end I can concentrate more on my own projects again. Having completed a pretty rough prototype for Golf Wars I am now thinking about how to build it properly. In doing so I have ressurected an idea I have been wanting to get my teeth into for a while, and that is creating a system that is purely data driven, using visual scripting to define the game logic. Hence the birth of Logic Engine.

This system is designed to make the process of game development that much more simple, as complex coding will not be required. A generic game engine underlies the entire system, then a network of connections, actions, events and messages will link all the various elements together.

I'll be posting more information on the Logic Engine as it progresses, and of course the first game to be built with it will be Golf Wars. I'm hoping that I will get the engine ship-shape enough to release to the public. I will also be developing a world editor that sits alongside the engine. This world editor - Architect - will be heavily integrated with the game engine. Of course all of this is powered by the XNA framework - I wouldn't attempt this without it!

So the PS3 has finally launched in Europe. After standing in GAME at 9am and deliberating whether to buy a 360 or a PS3, the fanboy inside me squaked his little voice and before I knew it I was at the counter handing over close to five hundred hard earnt pounds.

And I have to say it was actually worth it. First impressions were great. A clean interface, easy to set-up (I was online in a matter of minutes) and more funky features than I had imagined. I hooked up the PSP to it, played around with the web browser, bought some stuff from the store. About 5 hours later I finally played a game - not a typical initial console experience! The one game I did buy was Motorstorm, and I have to say I'm really impressed. There's a fanastic sense of speed, and when you eventually get online, it really does feel great ploughing through the herd.

This console truly is a media centre, and possibly the first console that will successfully tie all of these features together to create what manufacturers have been trying to do since the 3DO. I think the time is finally right, and the PS3 is well poised to be the machine to do it.

David Jaffe has posted one of his design documents, which is a pretty interesting read!

Calling All Cars

Deano sent me this link after a work argument about how much time should be spent making a design document look good. There's a golden ratio of time to quailty. It should be presentable enough to get the point across clearly and be an interesting read, but not take so long to create that it holds up development!

For the first time ever I'm impressed with a games marketing department (at least that I'm involved with). Heavenly Sword was shown on an episode of Heroes, this is really good product placement in my eyes. They've hit the target audience, generated excitement and established some creditability with relative ease.

Now we've just got to get on with getting the game done

Quite pleased with myself after last night's XNA session. I rewrote the collision detection for the ball as my old system was somewhat uneconomical.

Alpha Test Collision - The old method

The old system detected whether the non-alpha parts of textures were overlapping. If a collision was detected it then stepped between the old position and the new position looking for the first collision point. This meant that each frame collisions were being tested for a 24x24 pixel ball against x number of 64x64 tiles. This calculation may have then been performed for every pixel along a line in the same frame during a successful collision test. As you can see this is a hell of a lot of calculations. It could have been sped up by doing midpoint tests on the line rather than a step by step test, but I wanted a radical change to the system for a different reason.

Performance wise it wasn't actually that bad, there was certainly no noticable slow down caused by the collision system. It was also a really neat system for making collision as it enables you to just paint it straight in. However, the issue that made me want to stop using this system is the way I was calculating the landscape vector to use in rebounding. Basically it searched around the pixel for other non transparent pixels and built up a vector based on these. This meant that there were a very limited number of angles available to the collision system, and resulted in pretty samey collisions. There were also a few bugs that I'd bodged my way around rather than investigating the source of the problem.

Vector-Based Collision - The new system

I decided to change the system to a vector based collision system. This lost one of the major advantages of the old system, namely being able to just paint the collision. For the moment I have to calculate the vectors by hand. However, I will do a nice level building tool at some point that should make this really easy.

The massive advantage is performance - there are only a few calculations necessary in comparison to checking each pixel. At the moment I check against every vector in the world, but this will be easy to optimise to check only tiles that the ball path travels through. Being a line intersection calculation it also means that the exact point of collision is easy to find (and doesnt require stepping through each pixel).

I'll post the code up in a bit in case you might find it useful :)

So GDC is underway and the first videos of stuff is coming through. I'm particularly excited by Little Big Planet shown by the Media Molecule guys (with Mark Healey the guy behind Ragdoll Kung Fu). It has a lovely rendering style coupled with a really solid physics engine. I particularly like the potential of the Co-operative gameplay, something that seems to be ever increasing in popularity and deservedly so!

It seems that Sony had a pretty good showing at GDC, and really pulled out some impressive stuff. Hopefully this will ease some of the pressure on them, certainly they are investing in making the PS3 a success, it's funny how that now they are the number one in the market, they recieve all the flak. Seems like no one ever likes a winner! 

Home is also very interesting (and rather topical to me in regard to my post a day or two ago about building community). I'd heard ruminations about a 3D hub world, but I wasn't expecting the end result to look quite as nice. The aspect I really like is the integrated mini games - the way that you can become a spectator just by being there. I can see real potential in this stuff, shared experiences with a simple interface. However, it does remove some of the benefits of being in a virtual space to begin with, like moving wherever you please. Are we now in a situation where someone's avatar will obscure your view of the action?

My work colleague here at Ninja Theory (the day job), Deano C (blog.deanoc.com) has enabled the Lua language to be used with XNA. My first thought was "why?", but then there are plenty of features of Lua that are really great for game development. Certainly tables really become invaluable for quickly creating arrays of data, in a manner that would be much more lengthly in other languages. Its also interesting to note that Lua is becoming somewhat of an industry standard in professional game scripting, probably for exactly this reason.

For example - say I have a group of blokes that I want to play anims on. Any normal language would probably require a new data structure to handle all this info. With Lua I can quickly bash together an indexed table to represent the data and cycle through it very quickly i.e.

AnimTable = { {Entity = "Bob", Anim = "Run01", AnimSpeed = 1},
              {Entity = "Harry", Anim = "Run02", AnimSpeed = 0.75},
              {Entity = "Sally", Anim = "Wave01", AnimSpeed = 1}
            }

This can then be cycled through with the key pairs combo, let's say we had a function to play the anim on each entity:

for key, value in pairs(AnimTable) do

     value.Entity.PlayAnim(value.Anim, value.AnimSpeed)

end

Easy peasy. Sure, you could do this in any other language with arrays, lists, etc, but not quite as easily as you can in Lua!

I haven't actually had the chance to take a look at Dean's offering for the moment, as it doesn't have any immediate need for the project I'm currently labouring on, but I will certainly think about using it for particular applications in the future. Nice one Deano!

XNA guys have just released the Creator's Club site:

creators.xna.com

Having read this month's Develop magazine (a UK based game dev monthly), the article on Games 2.0 sparked ideas that have been lying dormant at the back of the brain for a while. For those that haven't read the article, it basically explores the lessons we can learn from Web 2.0 (essentially user generated content websites).

It is a pertinent issue, and one that I always try to design into the POV projects, simply because the creation of a community will increase the longevity and the gameplay that users will get out of it. As a plus side, particularly if you are trying to get money out of a project, the stronger the sense of community, the more likely you are to be able to sell downloadable content or create other revenue streams from the players.

So how exactly do you build community?

1. Extensibility

Extensibility is not included in every game, but there are several examples of games in the past that have lived way beyond their initial scope because of their extensibility features. Perhaps the best case study of this is Half-Life. Originally a single player experience built in 1998, the game was still being played in one form or another right up to the release of the sequel several years later (and is probably still around today even). One part of this was the openness to the Mod community - allowing almost anyone to create their own content. Complete conversions found varying success, but by far the most well known is of course counter-strike.

So opening up your game to allow people to generate user content is a good stepping stone, but within this itself there are varying degrees. The game may have very limited user content such as props or outfits for characters, decals for vehicles or something similarly mundane. Alternatively every single aspect of the game might be tweakable, allowing players to completely change it to their own desires. An important part of increasing the size of a community in this aspect is releasing good tools. The better the tools are and the easier they are to understand, the more people will be able to generate content, thus in turn increasing the size of the community.

2. Co-opetition

A horrible buzz word, but essentially competition and co-operative aspects to a game will both generate community, perhaps in different ways.

There are varying degrees as to how this can work, from basic score tables to online matches. Generally, the larger the community the better this aspect will be, as there will be more choice for players - although smaller communties often stick together and have more gentlemanly conduct than huge communities of players.

Clans, guilds, etc are great forms of community that encourage sharing of knowledge between players, in fact co-operative play is increasing in popularity.

Microsoft's Gamer Points system is really a platform wide version of this, and is a particularly successful way of doing it. It even pulls up games that might not do so well normally, because they offer valuable points to competitive gamers. A very clever system!

3. Updates

By releasing updates and fixes to a game you can respond to a community's wishes and involve them in the development process, thereby engendering them more to the game itself. However, this should not be used as an excuse to patch things that weren't right in the first place!

4. Information

Information is a powerful and inexpensive way of building community. By having good discourse with the players of your game, even before it is released, you will build their confidence in your product, and will make them feel part of something.

5. Make a Good Game

All the above is fairly important, however, it will count for nothing if your game isn't good. The most powerful way to build a community is to build a good game in the first place, otherwise all your hard work in building that community will dissapear as soon as they actually get to play it.

Got hold of the demo for the latest C&C today and had a quick lunchtime blast. Was very enjoyable actually, EA have really pulled out all the stops for this one - lots of no doubt very expensive live action FMVs, a pretty smooth and impressive 3D engine and polish in spadefuls. It's really made me want to go out and buy the actual game.

I may be behind on the RTS world though, think the last one I played was Red Alert, so I may be looking at the genre with fresh eyes, having perhaps missed out on years of evolution that has occured in the mean time. Still, whilst the strategy is a fairly loose term in the series, it is great fun. I just hope the multiplayer isn't the standard tank rush of old. I like to build a huge base and greedily defend it, but I suspect the rush and crush strategy will rear its ugly head once more.

Bosses are somewhat of a cliche - do they still deserve to be in games?

Jeff Minter's monthly column in Edge this month talks about his game Space Giraffe, and how he is avoiding the cliche of an end of level boss. Instead he is doing what he has dubbed  the Anti-Boss by having a bonus stage where the risk has been removed and it becomes a tranquil respite between levels. Certainly in a game like Space Giraffe, which looks like a breakneck shooter through and through, to embelish the already manic pace of a level may well overwhelm the player.

However, in large scale exploration games the boss often acts as the pinacle of pacing across the level, what has gone before leads up to this climactic moment. However, it does deserve to be said that the majority of boss encounters tend to be rather turgid affairs.

The big problems often lie with completely different mechanics to the main game, or poor signposting of the required solution to the boss's defeat. My favourite boss encounters nearly always use some feature of the environment to defeat the boss. Often simpler is better. The final boss in Ico is a good example of a simple idea that works well, and is a pretty enjoyable boss encounter.

For me Shadow of the Colossus or God of War are masterclasses in the art of boss encounters. Large impressive bosses that tower above the player and require particular (yet readable) interactions with the environment or the boss itself to overcome.

Alternatively one of the most frustrating boss encounters I've played of late was Raam in Gears of War. I found it to be pretty poorly signposted, and not a satisfying mechanic at its core (I won't give you a spoiler as to how to complete it though...)

Good boss design is actually pretty tough, surprising little thought is actually given to the complexities of producing a decent boss fight. Most of all your game needs to be built with your boss mechanics in mind from the start, as it will become almost impossible to shoehorn them in at the last minute.

I had a bit of a problem recently when it came to remembering the vector maths required for a 2D ball collision. It's pretty simple when you hit an axis aligned surface, as you reverse the direction of the vector in the axis perpendicular to the wall, however, as soon as you try colliding with a slope its a different matter entirely. After scratching my head for ages and scouring the internet I eventually found an article that had a decent answer to what I was looking for:

http://www.heroicvirtuecreations.com/2DCollisions.html

Which game me the following code snippet that might prove useful should you be experiencing similar frustrations!

// Calculate surface normal

Vector2 surfaceNormal = newVector2(-landscapeVector.Y, landscapeVector.X);

Vector2 unitNormal = Vector2.Normalize(surfaceNormal);

// Calculate reflected velocity

//projection vector = (-I · n) * n

Vector2 projectedVector = Vector2.Dot(-checkItem.Velocity, unitNormal) * unitNormal;

// which we will add to the initial vector twice to get the resultant vector.

Vector2 resultantVector = checkItem.Velocity + Vector2.Multiply(projectedVector, 2);