First of all, UDKs are installed in a folder named to obviously incidate the project, but also the name must show the UDK version.
The format looks like this: SuperFunGame-20XX-XX.
I install the January 2012 UDK for Rooks Keep to a folder named: RooksKeep-2012-01.
This folder sits next to previous project installs like: RooksKeep-2011-09 and so on.
I NEVER try to overwrite the old install!!!

 
Once the fresh install is done, I set up desktop shortcuts for: the x86 game exe, the x64 game exe and the editor. I set the “-log” switch on the game shortcuts so the log output window shows up while the game runs.
I then test out the shortcuts and make sure it all runs.

 
Now on to making it use our own project.
All conent for our projects is always contained in a folder structure seperate from the other UDK and example game content. In this case, the folder where all Rooks Keep’s content goes is ..\UDKGame\Content\RooksKeep.
To put content in the new install is very simple, I just copy the whole RooksKeep content folder. Done.
The localzation files are in a different folder and I have to copy the individual files. There are only three of them in RooksKeep for now. We never edit the stock UDK localization files.
Source code is also quite straight forward. We have three class packages and I just copy those folders across into the …\Development\Src\ folder. I make sure to NEVER edit any of the UDK’s packages and classes, so that whole headache is completely avoided here.
If you noticed that I didn’t copy the compiled .u script files, that was completely deliberate. The old binaries will just crash the new install, so I will have those compiled from source code instead.

Ok, that was all the easy stuff. Next I have to do the config files.
There are a few custom .ini files that are specific to RooksKeep. I just copy those into the new install and there is nothing to overwrite.
The main config files are called DefaultEngine.ini, DefaultGame.ini and DefaultInput.ini. With every new UDK update, something has usually been changed in these and I don’t want to erase those updates so I can’t simply overwrite the .ini files with the ones from teh older RooksKeep install. With these three, I load up both the old and the new of each one and compare them carefully and copy across all the stuff relevant to RooksKeep. I use the ‘Compare’ feature in Notepad++ which makes this whole task bloody quick and simple.

 
Another thing I do is edit the searchpaths in NP++ to search the sourcecode in the new folder. It sucks to edit code and then realize you were editng the old files…
I also edit a config file of NP++ itself to update the run command I have set up to compile the code. After that is done, I compile the code.
This time I was lucky and there were no compiler errors. Nothing in the UDK’s code had been changed that caused in compatabilties in the code. This could also have something to do with avoiding as many dependancies as possible and basing off the least derived classes I possibly can.
Usually, however, there are a few errors and the only way to deal with them is to manually address each one individually as one would normally handle compile errors.
Finally, testing time. I just run the game. The game always takes a long time to start up when running a newly updated project because it has to build all the shaders for all the materials in the project’s content.

When it had finished, it started with Rooks Keep’s front end map and menu and I tested out a map and it all seemed fine. That was a very simple update!

So I’ve just  finished up a bunch of skill icons for Rooks Keep. Gaze upon them in wonderment right here:

A few things I had to remember to do with the icons:

-They had to be descriptive of their skill function
-Each one had to be colored so as to be easily discernible from the others

So at a glance you can easily tell which icon is for what skill. I reckon I got it

Our blog’s been a little lazy here unfortunately, so I’ll strike it with an insightfully intriguing post on the Rooks Keeps character content pipeline. I won’t go into the specifics of actually creating the content, rather focussing on the work inside UnrealEd. This doesn’t include the rather large coding side of things either; it’s simply the content side of things. That’s somehting for another section entirely.

So, let’s start at the beginning then.
————————————–

Firstly, we design the character, followed by the concept art for it. DC does the concept art and modeling for the character, then the UV’s and then renders up all the required maps that I will need for texturing (Normal, Ambient-Occlusion, Cavity and Wireframe). Once texturing concludes, I’ll do the rig and create the required animations, sounds and anything else specific to the character (such as masks).
Once all the work outside of UE is finshed, it’s time to get it all ready for the game. And that’s the stuff I’ll list and explain here.
———————-
-Meshes:
The characters are made up of several meshes, and also require other objects for various gore and FX related purposes.

• Character  [The actual character mesh/rig]
• Weapons  [The weapon(s) and other attachments that the character holds in their hands]
• Head  [This is a character specific head gib used for gore]
• Gibs  [These are a global set of gibs used for all characters. These include both flesh and metal pieces]

-Textures: [Often a character has more than one material slot]
The character requires a fair number of textures, which includes the usual Diffuse/Specular/Normal set and extras such as masks and emissive maps. The textures (primarily the masks) will often have various color channels dedicated to specific material functions, which will be listed here as “RGBA=”.

• Diffuse  [This is the characters primary color map and sets the overall look of the character]  [A=OpacityMask]
• Specular  [This sets the 'shininess' of the character texture]
• Normal  [The normal map appears to add extra detail to the mesh, by performing some voodoo magic]
• Emissive  [This map indicates areas of the texture that are unaffected by lighting, and is often used to make areas glow]
• MaterialMask  [We use this texture to set various properties on the characters material, such as reflection intensity, specular power and others]  [R=Reflection G=SpecularPower B=Fresnel A=DetailNormal]
• Color Mask  [This mask indicates which areas of the character can be colored by the in-game color chooser. It also sets where blood appears]  [R=PrimaryColor G=SecondaryColor B=WeaponBlood A=SprayBlood]
• Gore Mask  [The gore mask indicates specific areas used by the gore system]  [R=Decapitation G=FootBlood B=InjuryBlood]
• Footsteps  [These are bloody footstep textures used as decals when a character walks through a blood pool]
• Head Gibs  [The textures used by the head gib meshes]
• Gibs  [Gib textures]
• Decals  [Blood decals used for various gore requirements, such as spatters, explosions, pools and drips]
• Particles  [These are the textures used by the various particle systems, including gore and weapon effects]

-Animations:

• Walk
• Run
• Charge  [A walking sequence used when a piece is in combat with another]
• Idle
• Idle one-shots  [Idle sequences to break up the otherwise looping idle animation]
• Blocking
• Quick Attacks
• Slow Attacks
• Parry: Left / Right / Up / Down  [Each piece requires a parry sequence in each basic direction]
• Quick Attacks Parried  [These sequences are used when the attack of the character is parried by the enemy]
• Slow Attacks Parried  [These sequences are used when the attack of the character is parried by the enemy]
• Death: Stab / Slash / Decapitated / Fried
• Pain
• Dodge

-Sounds:

• Pain[Beasts]
• Effort[Beasts]  [Used when the character attacks and performs some other movements]
• Die[Beasts]
• Impacts  [These are sounds of weapons successfully hitting characters. They come in both flesh and metal variants]
• Footsteps  [These include various foot types on various surface types]
• Swing Weapon  [Played when weapons are swung]
• Attacks  [Character attack sounds. Right now, these are used by the Bishops of both sides]
• Parry Attack  [The sound played by the attackers weapon when it is parried]
• Enemy Parry  [Played by the victims weapon when it successfully parries an attack]
• Weapons on ground  [Played by weapons left by dead players as they are moved around]
• Corpse Impacts  [Sounds of dead bodies been moved around by other players]
• Blood Splats  [When blood hits a surface]
• Decapitation  [The joyous sound of a head leaving it's owner]
• Gibs  [Gib impacts with surfaces]
• Heads  [Decapitated head impacts with surfaces]
• Explosion  [When a character explodes]

-FX:
-Particles

• Gore Slash
• Gore Stab
• Gore Smash
• Gore Decap
• Gore Explode
• Gib Trails  [Blood particles flicking off flying bits]
• Weapon Impacts  [Played when weapons parry]
• Weapon Drips  [Blood drips from bloody weapons]
• Weapon Trails  [Trails left by weapons swinging through the air]
• Attacks  [Effects used by certain attacks, such as the Bishop fire and lighting]

-Decals

• Blood Pools
• Blood Splats
• Blood Footsteps
• Gib Impacts
• Blood Explosion

-Other/Miscellaneous: These are some of the other, equally important, elements that need to be added:

Material
The primary material/shader of all characters. This blends all the character textures and masks into the final shader that is applied to the meshes.

Material Instances
These are instances of the main character material that simply change variables from it’s parent.

AnimTree
The ‘AnimTree’ handles most animation functionallity, animation blending, and is used for other features such as: Shrinking head bones for decapitation and Foot placement IK.

Physics Asset
The Physics asset is used for Ragdoll physics and other physics based calculations and collisions.

Mesh LOD’s
The main character mesh also requires 3 extra LOD’s to improve performance when required. These can, fortunately, be generated inside UE.

Sockets
Sockets are locations placed on meshes that are referenced by code.

• Neck [Spawns a head stump mesh when decapitated]
• HeadGore [Gore particle spray upon decapitation]
• Three Weapon Edges [These are used by weapon FX trails, referenced by animation notifies]
• Weapon Sockets [Held weapons]

Notifies
Notifies set events during animation sequences, such as when to play trails left by weapons as they swing and when to play footstep sounds.

Cloth
Physics calculated cloth objects, such as the cloaks on the King and Queen of the ‘Knights’ faction.

Physics Material
Physics materials set various properties on meshes and physics objects.

SoundCues
Sounds Cues are used to blend together various sounds, tweak volumes, attenuation and other audio properties. Almost all sounds played are SoundCues.

Map Based Environment/Reflection-maps
We’ve added support to character materials, that allows them to search for map-specific reflection maps.
———————————————–

Whew! And that’s that for now! As you can see, a lot of work goes into each character piece, and this doesn’t include the actual content creation and coding for them.

I trust you found this insightful, useful or an otherwise educational experience. If, on the other hand, you were bored stiff and angry by the end of it.. Hahaha! Sucker!

 
It is on this auspicious day (well it is now) that we announce that we are planning to operate with a whole, crazy new development/business model!

 
Rather than using the traditional model of “Develop, Test, Release”, we’ll be using something I think I’ll call “Release During Development”.

 
Basically it works like this: Instead of making a full big game that takes 1 – 2 years then releasing that and hoping everyone likes it, we make our game in several parts or episodes, starting with a pilot or prototype, and release each one as it’s finished.
I think there are many great things about this, but some of the main points are: games get released quicker, developers get some revenue during development and players can give feedback to affect the main development cycle of the game.
As development advances, more installments are released and all together, they make up a full game, only it’s been thoroughly tested and improved according to actual player input. The final design of the game is not fixed at the beginning, but it develops as the game goes and as we see what players want, what they don’t want and how they play.
I’d sound like a marketing stereotype if I said this was a ‘dynamic’ way to make a game, so lets call it ‘fluidy’.

 
The other awesome thing about this is that it means we can actually develop and try out experimental games and release them. Games that are good, we can continue to work on while lousy ideas don’t have to waste years of time! You might be walking on ceilings while firing a giant golden minigun at radioactive banana troopers sooner than you think!

 
Here’s a comparison of the new model vs the traditional method with pros and cons:

Release During Development

1: Game is developed and released in smaller pieces or episodes
2: Repeated design, develop, test, release cycles
3: + Releasable game is ready much quicker
4: + A smaller time and resource investment is needed to get to release
5: + Feedback from players can be factored into the main design and development
6: + Experimental games are much more possible
7: + Developers get funding during development
8: + Greater community involvment as players have an effect on game development
9: + Games are better as they get more testing and get tested in release situations
10: + Good games are expanded and improved, lousy games don’t waste lots of time
11: – Initial game release has less content and is much smaller
12: Initial release and subsequent parts have a much lower price point
13: + Players can try out the game for a much smaller investment
14: + Better marketing as game stays live and active for a longer period of time
15: – Harder to release a demo for the first release
16: + Big, high production games can still be made
17: – Can affect game design. Won’t work well with some types of games
18: – Subsequent parts would need the first and may depend on other previous ones

Traditional Method

1: A full game is developed and has one big release with possible addons later
2: One big design, develop, test, release cycle
3: – It takes a long time before game release is ready
4: – Huge time and resource investemnt is needed before there is any return
5: – Design and development is finished by the time most players can provide feedback
6: – Experimental games are much more risky and unlikely
7: – Developer gets no funding until final release (if they’re still alive by then)
8: – Little community involvement. Players can have some effect on patches and DLC
9: – Games get limited beta testing and alpha testing
10: – Lousy games waste lots of time
11: + Game starts off big with lots of content
12: Full release has a much higher price point
13: – If there is no demo, players can’t really try out the game
14: – Marketing is all hype around a brief release period
15: + Full game has enough content to make a demo
16: – Safer to make small games. Big games are much more risky
17: + Long linear, story and exploration games are better kept in one big release

Other Notes:

Initial game is released as a polished prototype rather than an early beta.
At a later stage, all parts can be packaged and sold as a single unit like a normal game.
Game does not need to rely on microtransactions.
This is not pre-order, subscription, “free to play”, “pay to win” or “sucks until you pay”.
Pre-orders can be offered where players buy the initial game and get the later episodes as they come out.
Initial release can be made free later on.

 
Well, there it all is. I think it could be better for everyone and looks like it might be a great way for small indies to make games, especially the bigger kind with HD production values!

 
But first, we want to get your thoughts and feedback on the idea. Are you interested in buying games as they are made and being able to have your say while the game is in development? Do you want to see experimental projects and be involved in their advancement?

 
P.S. Speaking of experimental games, we’ll soon be revealing the project we’re intending to develop and release this way.

With this, player controlled combat is now the primary focus of Rooks Keep, putting chess into the backseat. If you can’t imagine how the game works, to try to give you a general idea of what exactly Rooks Keep is; basically, Rooks Keep is a bit like Unreal Tournament with swords!

Also not minor is that the Beasts have been added. This means there are now 12 characters in-game to engage in various flavors of brutal asymmetric combat.

Screenshots:

Don’t let the wild character colors frighten you, we’ll be attending to those as we go.
Also notice ShadowBlade’s new UI graphics compared to the previous shots of the UI I posted.

I’ve not shown much of my own work here on the blog, but today I decided to render up some of the animations I’ve been doing for the Beast side in Rooks Keep.

These Beasts were much quicker for me than the ‘Knights’ side i’d already done. The Knights were the first real character anims i’d ever done (with the exception of some sequences for Crucible UT3). I had to get the hang of some of the more advanced rigging aspects, requirements for the engine and the game itself, and then finally tackle the animations themselves.

To start off with, here is the Pawn from the Beasts in action. You can see the walking(forward), parrying at various angles and some quick attacks on display here. Each piece in the game thus far, requires about 30 separate sequences for the combat system to look proper neat

And here is the Beasts Bishop doing his thing. Similar to the Pawn, he features moving(forward), parrying (which will probably also include some neat FX down the line) and some attacks.

I’ll post more short videos in the coming weeks, and try to document more of the goings on on my side

Rooks Keep will not be using Scaleform. Instead, it will be using our own custom built in UnrealScript GUI. The reason for this is because, well Scaleform is probably great for large teams which can find someone who just does flash coding and give them a job. Web coders are more easily available then UScript coders, so that makes sense. Unfortunately, this makes the whole job much bigger and you still need someone to do the UScript side of things. For a tiny team which has more experienced UScript coders, Scaleform and having to go through another interface between the UI and the game doesn’t make much sense.
That’s the reasoning, but probably a bigger contributor is that BlackEagle didn’t like working on Scaleform and we figured we could make a simpler, more solid and totally ass kicking UI system ourselves!

I already had a widget system that was used for organizing the HUD and some primitive UI controls in the game, so I upgraded its design for a full UI system and iterated. At the moment, the system is well developed and functioning quite nicely.

Here is the placeholder main menu we’ve been using:

Those are just placeholder graphics and not all those options will be there like that in the real version.
Unfortunately, you can’t see the animations or hear the sounds it plays in that shot.

Here you can see some more bits.

There you can see that it has tab controls, lists, a test drag thing and a drop down list. Nobody appreciates how much goes into dropdown lists, but they are tricky little buggers!

For now, its looking a bit primitive, ShadowBlade is working on the real graphics for our UI and its gonna look a whole lot better! We are aiming for something similar to what you’d expect of a GUI in Blizzard’s games. Similar in style, simplicity and solidness!

Some cool things about our UI system:
It supports materials and all the effects that come with them!
Simple and direct interface with game.
Opacity and fading effects.
WidgetMods. These are not too simple to describe, but they allow designers to apply all kinds of modifications and effects to UI widgets such as animation, fading, sounds, texture layers, material layers, text and even custom things.

It just so happens that the beasts have a bishop as well and here is the creature that is the bishop of the beasts. Don’t worry, it doesn’t bite… or scrath… or use evil magic… unless it does.

How about some scupltures… Behold the olympian physique of a champion warrior and leader, but for now heres king blubber bag:

This is the bishop in shades of brightened black:

Just one more to go…

Next up, you can see my the next installment in my ongoing quest to master muscles. This is the Pawn. You can call him the “Ratman”, but he doesn’t really like that.

Well, there you have the the first three beasts. It was quite a bit of work (learning more about muscle structure, especially on the forearms), but it got more fun as I learnt. Hopefully you like them.

Here are some shots of how the initial meshes were built:

And the Pawn:

And these for good measure:

Next up, the King and the Bishop…
Can anyone guess what they’ll look like?

I’ve been working recently on some more maps for Rooks Keep, and I do have plenty of ideas that I think would cool to see, but only a few can be made. I’ll go over the progress so far here, starting with our first map that we’ve used for all our screenshots up until now.

Courtyard:

I’ve added some new foliage and changed the trees in the Courtyard this time. There are a few passes we need to do still, but it’s nearly done. Every now and then, i’ll update it with some new features, textures or details, especially with each new UDK release.

Forest:

Forests are cool! Right? Well, i’ve wanted to add one to Rooks Keep since the early stages, so i finally got around to it. Save for some mesh work (on the trees and cliff’s), it’s mostly done. I’ve created some foliage and trees to add to improve the forests, so those will go in soon.

Fields:

This map i created just this morning basically. I created some trees and textures last night, then just this morning created some more textures, imported the meshes, and then made the map. I really like how it turned out for just a couple hours work. There are a bunch of improvements i need to make, but i’m pleased that the idea for the setting works well!

Crypt:

This started more of an exercise in theme than a map idea. But the way it turned out was awesome, so i turned it into a playable environment. Made some dead trees, grabbed the gravestones from The Crucible, and added them all into the place, and here we are!

RedYard:

I’ve wanted to create an environment like this for a while, the red sky, the weird lighting. It took about a day to get the bulk of it made, then a bit of the next day to polish it up a bit. I’ve got to work on the sky a bit, because the orange sun doesn’t match the blue sunlight quite yet

Keep:

Just another map I whipped up quickly with the batch of meshes from the Courtyard. As usual i need to go over it with some more polish, but it’s another map

Anyway, i’ll be working on more maps as the game surges forwards, so stick around!