Author Archive

Our initial plan for 2014 was to have time end on the 31st of December 2013. As it turns out, there was betrayal, things were said, contracts with certain deities were severed and now we have to roll with the hastily concocted “Plan B”.

First up, we’re working on fixes for the most troublesome problems in Viscera Cleanup Detail and its bonus editions. We’re hoping to be able to release updates weekly even if they only include fixes and the mostly uninteresting changes of the week. An update for the most pressing problems in VCD: Santa’s Rampage is scheduled for the end of this week. VCD: Shadow Warrior and full VCD will also be getting updates of course.

The next major step is getting VCD on Steam Early Access. It will involve a general polishing and sanding off the worst rough edges of what we already have – maybe there’ll be some new content too, we can’t seem to resist feature creep! That’s aimed at mid February.
Alongside VCD, we’re also going to be bringing RooksKeep to Steam now that it has been greenlit. The biggest change will be using Steamworks for the multi-player matchmaking and other online jazz. There’ll also be the usual raft of fixes and improvements.

All that has to happen at the same time as setting up some super serious business funk to vacuum up time and generate disruptions. Oh, and also experimental prototypes.

As for the finger puppets, we’re keeping those plans secret until the time is right to unleash the devastating fury on an unsuspecting world…

The way we have been working is not sustainable, especially the crunches just before release. Several days on my work log peaked over 15 hours and that is not really sane. …And that log doesn’t count lunch or any other breaks as work time (unless lunch is eaten with the other hand on the keyboard)

There has been a lot of this crunching because there have been many releases.
Going back to June, we finally pushed through to get Rooks Keep released which was met with a pretty depressing reception. That was not really surprising. We realised as development dragged on that it was a mistake to make such a big game with no clearly communicable hook, but we wanted it done.

Very shortly afterwards, born from a thread of otherwise rather cynical contemplation, inspiration struck and we dove into Viscera Cleanup Detail.
After that we had the deal to do VCD:Shadow Warrior and that took longer than expected. Following that a major update for VCD and the insane idea of VCD: Santa’s Rampage came up. We could either cram it in before Christmas with a very tight deadline or wait a year (yeah, that’d work…)

We crunched to get VCD v0.2 on the date we’d set for the end of November and went straight into VCD:SR for 2 more weeks. Arn started working on Santa after regular VCD work and I gradually started as VCD v0.2 neared its target. It wasn’t all *gruelling, but it was not healthy and the team needs a break.

All in all, it has been a pretty punishing schedule and it was all compounded by my eye surgery and subsequently complicated recovery which devoured lots of time before and around VCD:SW.

However, time management has been steadily improving – we somehow got 5 significant releases out on schedule in the last 6 months – but it’s not nearly good enough.
Getting this right is a major focus of mine for the coming year. Properly spacing out milestones and being disciplined about feature creep is going to be challenging, especially since ‘feature creep’ introduced some of the most interesting elements of VCD. Allowing space for unexpected changes and time to experiment will need to be done. This is challenging because it is planning around the unknown, combined with the perpetual certainty that there is not enough time to do everything already on the list.

It is also vital to make sure there is time to continue experimenting with new prototypes. Game jams and experimental projects are not just a way for studios to possibly scoop a new hit, for indies, I feel they are essential to long term survival, because the ability to produce crazy, unique and unconventional games is one of our best edges compared to big studios with massive production capacity. Making one new crazy game that stands out is great, but once that becomes old and done, we need to have something new up our sleeve and it better be damn good and it better not be the same as everything else. In order to reach that, many prototypes must be produced and discarded in the process. Somehow, those have to be produced while still developing the main, proven games.

That will be an interesting challenge and it won’t happen at once. It will be a continuation of the process that has (I think) been evolving and improving. I will just put more concious effort into it and try to push myself to better understand where the limits of the game development process are for us.

TL:DR – Less burnt-out devs, more crazy stuff, time will kill us all – don’t say I didn’t warn you!

*some of it really was; fucking physics, yeah you!

Hail all noble space station sanitation engineers and hygiene technicians, time for a small update on proceedings.

Progress has been a bit slower over the last two weeks with lots of other things going on. ShadowBlade, especially, has been preoccupied so there has not been much change on the maps.
There has been some advancement, though, and we are expecting to be able to get back up to full speed moving on from next week.

In the meantime, here is some work in progress
The supply vending machine:

This new machine (ignore the fugly placeholder mesh) will be able to provide the janitor with all kinds of equipment needed to clean up or repair and replace damaged parts of the facility.
If those pesky marines blew up all the video monitors or stole all the medical supplies, this is where the replacements would come from.
It can also provide new lanterns for working in the dark or anything else we come up with down the line.
In keeping with our design of having minimal HUD and on-screen UI, we have a system for putting the UI on a panel on the side of the machine. These in-world UI panels can be operated using the janitor hands.

Welding Laser:

The laser will be used for repairing bullet holes, scratches and other types of damage or deposits that the mop can’t deal with. It may also have a few other nifty uses and devious traits.

There has also been work on improving the mopping and bucket when cleaning up scorch marks.

As always, there are also many other fixes and smaller changes and plenty more to come before the next version.

This is a basic look at the procedure we use to update our projects to newer UDK builds. I use the update for Rooks Keep I performed today as an example.

 
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!

Greetings mortals and all others who have come!

 
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.

That’s right, there have been some big changes to Rooks Keep! The beasts set has been implemented in-game, the UIs are starting to look wicked and music is starting to go in, but the biggest change of all has been to the combat.
The combat system has been given a total overhaul so instead of having limited movement in 1vs1 combat, players will now be able to roam freely around the arena in third person and engage any number of enemies. This opens up lots of crazy new game possibilities including mass battles against many other players and bots, invasion game types and large team battle. BlackEagle is busy right now working on realizing these new gametype possibilities.

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.

Time for a small update while we wait for some bigger stuff.
Right now, there’s a lot of crazy stuff going down on the gameplay side of things and I’ll post some shots of the finished Queen when I get round to rendering them. Very soon, we’ll have nice shots of the beasts in-game too, but for now here’s something else.

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.

Every faction needs a leader. For the beasts, we ellected a shining, magnificent beacon of glory to be king. We elected someone who would embody all that the iconic king stands for.

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…

Ok, the Rook and Pawn meshes for the Beasts side have been finished for a while and sitting around begging to be shown, so I finally decided to finish off the HD renders and actually post them.
here we have the finished Ogre (Rook) HD mesh:


This guy has all the finesse of a drunk elephant. He’ll obviously enter into diplomatic discourse and use that menacing club to outline all the important points.

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?

Its 3:30 AM in the cold dark night and like any mad indie developer (or mad scientist), instead of sleeping, I’m hard at work on some diabolical creation.

This time, I’m crafting the grotesque creatures that hail from the darker recesses of Rooks Keep.
In Rooks Keep players will get a selection of chess sets to play as.
While our previous set of characters were all a bit cleaner and outfitted with metal suits of armor, these beasts have a different style. Their bulky bodies are bulging with muscle and while some of them use only their natural claws or blades. They all wear minimal armor and what litte equipment they do have is crude and worn.
If you stretch your mind a bit, you might notice that the monsters of Quake 1 lent an inspirational hand to their design.

BE WARNED: What you are about to see includes graphic representation of endevours not entirely finished, one might even call them work-in-progress…

Knight
This friendly customer is going to be the Knight for the beasts side. It will joyfully hack its oppoents with two big sharp implements.

As you can see it doesn’t have textures yet and the materials are not the most fancy. This is the high-detail sculpted mesh with about 8 million polygons. As you can see I’ve been having lots of fun with muscles and trying to get a reasonable skin on him.
We’ll be sure to post some updated shots when SB gets to work on the textures.

Here are some shots showing the early construction of the mesh. Now you can see how I used box modelling and took it from that initial, basic “box chicken” to the snarling beast at the end. I then stuck a piece of armor on top and moved on to the high detail work.



To get it to this stage took about 5 hours.
Here is a shot of the state it was in just before sculpting.

I did the armore and it’s straps in high detail and prepared the rest of the mesh for scuplting by applying smoothing. I also cut some extra loops into the teeth and spike to retain their shape when smoothed.

Ogre / Rook
And then there’s the next one! Right now, I am working on the brutish ogre that will be the Rook on the beasts side!
He’s not done yet. I am in the middle of sculpting my way through the various pieces.


As you can see I’m getting lots of practice on muscles. Its tough, but its getting easier. I think I am getting better at them with each mesh. What makes them even more fun is that there are slight differences on every reference I’ve got.

And for good measure, here are some earlier shots.

That is the LD mesh and the other is the other is the partial HD mesh just before going to sculpting. Notice how the hard ‘mechanic’ style parts have been detailed out while the organic pieces are just smoothed out.

Ok, enough for now. When I’ve finished this little bugger, I’ll fire off arender or two and post those along with some shots of the initial progression.