We’re getting there, open Outcast fans! We’ve just started testing our first internal builds of our upcoming CryEngine 3 Tech Demo to make sure that everything is released into a brilliant and polished package. Some CryEngine 3 screenshots can be found below.

Adelpha looks better than ever this time around!

The internal test builds still need some work before we will be able to publish our work – expect a few more weeks before the newest release will hit “Gold” status and we can present it to you guys! This time around you’ll face some resistance during your adventure. This means that you can measure your strength against some AI foes and finally put that UZA-SH2 into some real use! Oh yeah, one more thing… look forward to see us rebranded with a completely new image as a celebration to our CryEngine 3 port.

This is also why we are really looking out now for a web designer! Check out the job description for information how to apply.

Have a great, cold winter! The Talan don’t really enjoy the snow though…

Keep a look out for more information somewhere around February. Things will get quite interesting around that time… ( if not… well, “Zort!”).

However with great power come great unforeseen problems, or something like that. We don’t want to go into details here but we encountered a few things we can’t easily solve on our own, or at least didn’t expect we had to. But don’t worry, we’re still moving steadily towards a demo release…

Furthermore there have been some serious changes in the general project structure and other things we think you’ll like to hear/see/expierence, so you see 2012 is going to be an interesting year for anyone following our endeavour to create a worthy Outcast sequel.

Waiting will pay off, we promise!

Everyone who played Outcast will remember this truly legendary weapon shown above – The LN Duo 500. In this blog posting I would like to explain the process behind the re-design of that weapon for openOutcast from the very first idea in 2D to the finished model in 3D…

The first thing we do at the 2D sector is to look at the original weapon in all possible angles and think of a possible new design. How could it look like ? What was bad in the original design? What could we do better ? To answer these questions we need sketches, a lot of ideas and – the most important thing – lots of feedback.

With the first draft of the weapon design I tried to “improve” the original shape with dynamic lines…unfortunately it didn’t really look like a weapon because of the bulky and squarry base shape. One of the questions at this time was, if the new weapons should more look like the old ones or not. And if Appeal used very primitive shapes because of the technical limitations back in the days when OC1 was designed? Would they have taken more “human-army-look-a-like” weapons with a more or less sci-fi look if they could? In the end we decided to create something new BUT to keep parts of the original and recognizable design in the new concept. And this is what was coming out then:

I wanted to keep the element of  “take your hand IN the weapon to grab it”. So I just thought: “Let’s improve that weapon only with more barrels and lets see how it’d look like.” You can see the sketch below but I finally recognized that this design wasn’t the right direction neither. The rotation element would maybe look cool but it is not very useful (Basically you could shot yourself with it ). It could be dangerous and why should someone use such a system if we already have the revolver system in most of other nade launchers ?

So after some more discussions and feedback we finally started to approach to the final idea. I decided to also keep the characteristic barrel angle of about 45°. In this case I only needed to redesign the rest of the gun, instead of the barrels and for that I searched the net for similar ideas. Team member Berserkr posted some reference pictures and videos and so I came to the pencil sketches below. Pencil sketches are always my first step on the way to the final pictures. They can be done everywhere and it is always something else to draw on paper instead of using some tablets and a monitor.

If I’m needed to create a digital version of this pencil sketch, I just take a photo and overpaint/colour it in “Sketchbook” or “Photoshop”. After a few more feedback rounds I was able to show up the final sketch of the LN DUO II  then:

What’s missing now is some material information for the 3D artists and a short 2 frame sketch of the reload animation. Because these sketches aren’t done yet we will present them in the next episode where you can see how our 3D artist are working on the actual 3D mesh and the reload animation of the LN DUO II. I hope you enjoyed reading the post and be patient: The next episode is coming really soon

After some inactivity in the programming dept. things are back on track again. As announced one of the features we’re currently working on is the item system and everything related to it – such as the OC-typical item tracker. AtomicJo looked into this matter and, while some tweaking is still needed, the results look pretty presentable:

But what is the item tracker without the typical HUD voice (e.g. original OC footage at 0:32)? If you think you can do the job, don’t hesitate to apply and your voice will guide the player in our next demo!

Note that the “focus borders” are placeholders from CW. As it happens we’re looking for Flash designers right now. If you have experience with designing Flash websites or other user interfaces, take a look at the open jobs.

—

Oasis 1.2

While working on the components of the actual game (story, assets, levels) and other stuff (document procedures, …) kept us busy in the last months, we decided to give you something playable again soon: Oasis 1.2, our next demo!

As the name suggests we don’t consider it as pure technical demo anymore (e.g. demonstrating the possiblity of nonlinear dialogues and persistent levels). This one will feature all the core components of the game.

If you tried Oasis 1.1 you probably know what was missing: some action! (read: combat system and enemy AI)

Additionally the whole questline and dialogues were rewritten and our leveldesigners Demogorgon and Linkin Muse rebuilt the oasis level from scratch and tweaked the island level.

This milestone will also incorporate the feedback we received from the technical demo, while under the hood many systems have been revised to enable easy porting. Expect it… ehm… well, at least before the release of the…

—

… Cryengine 3 SDK

When we decided to use Crysis (Wars) and CryEngine 2 as technical base for the project, we got a state-of-the-art engine with great tools for the price of not being able to create a standalone game.

As the UDK was released, many Unreal Engine based mods went indie and while no real struggle emerged about changing the engine inside our team, spirits were down a bit since the Crysis Wars SDK is in some ways buggy and not really well documented (much time was spent on figuring out how to do something that could be explained in not more than three lines). Additionally there was the feeling that even after finishing the project some players MAY hesitate to try the thing if they have to buy another game in advance or download a ~6GB demo (even in the times of high-speed internet).

When Crytek recently published a release date for the Cryengine 3 SDK and confirmed it will come for free for noncommercial projects, things have changed for the better: we’ll be able to release open Outcast as a standalone game!

Although everyone in the team is excited about the new perspectives (going indie, better documentation, regular updates and bug fixes directly from Crytek), we’re trying even harder to reach a new level of quality in our last CryEngine 2 (and Crysis Wars) based demo in order to have a good starting point when the battle of the SDKs gets into the next level this summer (UDK – Unity – CE3 SDK).

—

Jobs

Want to jump into CE2 based game development (and learn using the tools) to be ready when CE3 SDK gets out? Always wanted to work in a team, that’s determined to reach AAA quality in all fields, to enhance your portfolio? You can apply for:

• Female Voice Talent – be the voice of our HUD! See original OC footage at 0:32 for an example in the original Outcast game
• 3D Artist – everything from simple decoration to architeture, animals and characters
• Flash artist – always wanted to use your skills to design an user interface of a game?
• Action Script programmer – Give some functionality to our HUD and menus.
• Gamedesigner – You’re always complaining about dull quests, imbalanced weapons or THAT huge design flaw? Here is your chance to make it better! You should be ready to learn some tools and do some scripting – but that’s worth it, right?
• Writer – Like writing stories or plays? How about giving more depth to our storyline or creating some ingame dialogues?
• Translator – make sure Oasis 1.2 gets localized to $YOUR_LANGUAGE as well!

If something of this is appealing to you check out the detailed job descriptions.

—

So far for now and Happy Easter to everyone!

Long time no see, huh? The good news are that we are still there and working. The bad news are…sorry, there are no bad news today Some of you may already have noticed that we are currently not that active in PR and that we are missing a lot of updates as well on ModDB as also on the blog and on the boards. What we recently started to counter this a bit is that we are now twittering a lot on our internal twitter account which can be found here:

http://twitter.com/openoutcast

This is our first step to get back to a normal operation in PR. Really sorry about our latest inactivity in showing pictures and stuff. We will try hard to do better!

I would like to give you a short update on what the current status is. So… Okasankaar is at about 60% now. The terrain is existing and we are – slowly but steady – proceeding with decorating the map with flora (tree’s, bushes etc.)  and other decoration assets. But I think most of you guys are just interested in the status of Cyana, the capital city of Okasankaar. Good news there! The sketch of the city is done. That means that the city is already there but not with the final assets. We created a lot of dummy assets for that purpose and it worked quite well. Expect some pictures there soon.

We also just created a small “fisher village” these days which is located on another island near Cyana and this village will be featured in a bigger news update soon. But hey, we can’t just leave you here with those ten lines of text, can we?

There you go…proudly presenting “The new fisher village”

Stay tuned!

Open Outcast had a really great year 2010 and we were able to reach a lot of important milestones in this project. We released Oasis 1.0 and 1.1 and we made a real step forward…

We just wanted to say “Thank you” for all of your efforts in supporting our project. No matter if you reported bugs of the Oasis demos,wrote some blog posting about our project or just voted for us in the Mod of the year challenge on ModDB…! Of course we will also count on this superb support in the next year and we can already promise you that 2011 will be an even better oOC-year than this one.

We posted a big “Christmas special feature” on our ModDB profile with some more information about the targets for 2011 and some pictures as well It’s not yet authorized but it surely will be in the next days…!

Wishing you all the best and a happy new year!
Eternal Outcasts

The voting for the Mod of the Year 2010 over at ModDB is closed and we are desperately waiting for the results now. We think that we have chances to win one (or more? ) of the following awards, which will be published on the dates below:

• December 19 – Editors Choice Original Art Mod + Original Art Indie
• December 20 – Editors Choice Unreleased Mod + Unreleased Indie
• December 24 – Players Choice Unreleased Mod + Unreleased Indie

So stay tuned and visit ModDB regularly for any updates on this. Thanks again for your help in voting for us!

Lets win this!

Regards,
Eternal Outcasts

• putting different meshes together in character editor
• thin and fat mesh variations (for any mesh)
• mesh decals
• texture decals
• material variations and diffuse texture coloring by decals

Putting different meshes together is used in OOC quite a lot, we have different heads, eyes, clothing, hats, belts and other accessories.

Thin and fat mesh variations – this comes in two flavors. Generally thin/fat mesh variations mean that you can morph a body into it’s fat version or thin version with slider, so you may have 50% of the fat body or even 150%. The flavors I mentioned means that you can supply a fat body mesh and thin body mesh, but you don’t have to. If you supply them, they are used as the morph target. If you don’t supply them, cryengine pushes the vertexes outwards to simulate some fatness, or pulling them inside to simulate thinness. This is similar to using Push modifier in 3dsmax. Of course the result is much better when you supply thin/fat meshes, because you have more control over the shape.

Because we are also using mesh decals I have decided that for the general body which most talans should use we will use the “automatic” cryengine fatness/thinness. For some variation it does good job, even though the result is probably more of a thick/slim variation then fat/thin. Later we may introduce a fat body for specific talans, but generally this simpler version will be used (which also saves a bit of memory because no real fat and thin mesh data have to be hold in memory). Also a real fat stomach could be achieved through “fat” clothing (under which body without torso may be used).

Here are a few examples of thin/fat body using the simple engine push/pull vertexes:

(thin – normal – fat)

On the picture the whole body gets thicker, but we have control over which parts should get thick/thin (like legs, torso or hands). Also on the picture head changes, but it wouldn’t have to. Another thing to note is that body doesn’t have muscles painted int the diffuse and normal map. This is because it would spoil the fat or very thin character. We still have textures and materials for the normal/muscular talans of course. Heads can also use thin/fat variations, but for OOC I have decided that for these thin and fat variations we will use different head altogether and that way we can generate lot of heads variations.

Mesh decals are small pieces of mesh which are textured with some decal like a tattoo, scar or some other distinctive feature. To optimize for drawcals, more decals are placed on the same texture (512×512) and then they are “selected” by changingn uv tiles and offset parameters inside sandbox. Mesh decals have their own material and their mesh is “skinned” on the skeleton so that they move and deform same as the body underneath.

Then we have texture decals. These are applied in the same material as the face texture. Advantage is that head diffuse texture can be in higher resolution, for example 1024×1024 and the tattoo decal can be as low as 256×256. This saves memory because the hi-res diffuse texture is shared among many talans (682 kB) and the head tattoo adds only 85kB on top of that. Of course borders of the tattoo will have a bit jaggy edges, but still they are worth the saved memory.

The same technique can be used for body dirt. Body diffuse texture which is shared among talans can be in much higher resolution that a few dirt decal textures. Diffuse body texture takes 1.33MB, while 5 different dirt decal textures for the whole body take only 853kB (even though there is visually no dirt on a particular body part, dirt decal is there too).

Here is an example – clean – dirty hands – dirty feet – dirty hands and feet – fully dirty

Next are the material variations like different skin brightness (tweaking melanin parameter with the same diffuse texture) or diffuse texture coloring. Coloring can happen through diffuse color in sandbox material editor. This is great feature for tweaking colors, but less great when we would want to color a greyscale texture completely by diffuse color. One of the reasons is rather obvious, we couldn’t have diferent colors on a more complex clothing, for simple skirt it could do, but something like Lora’s or Shamaaz robe which have different colors in different parts would break it completely. Another reason but much less visible is that if we color plain surface with only one color then it’s not very natural, even solid color in real life varies on hue a bit.
Here coloring (in cloth shader) by a decal comes to help. First we have to break the diffuse texture to it’s shading component and color component. Shading component can be higher res (contains all the detail) like 1024×1024 and the color component can be as low as 128×128. Let’s have a look at an example:

Try to find two same talan . What you see on the picture should be further enhanced so that any of the two same colors except the short skirt version should be at least slightly different hues and the dirt you see on the cloth has no variation. Now interesting facts about memory usage:

• main diffuse texture is 1024×1024 large, has opacity included (for short skirt) and takes 1.33MB of memory
• everything else is made by small textures in resolution 128×128 and they all take only 300kB of memory

This is how the big diffuse and all other small coloring decal textures look like:

They say eyes are important, so here are our talan eyes using simple diffuse coloring for the cornea of the eye to bring different colored eyes, example:

The smaller pupil on the middle image is different eye texture similar as this “damaged eye” which could and should be a bit better

and yo mama, someone said high, but how high?

That’s all folks. Let me know if something needs some more explanation.

With characters there are usually two approaches, one where the whole character is exported from 3D application and later only a weapon or other asset is “linked” to his hand. This is very common for older games and simpler characters as animals. Another approach is to have different parts of the characters exported as separate pieces. These pieces are then glued together in some form of character editor.

Cryengine2 goes the more advanced options. Crysis characters have usually heads, hands, eyes and all the small accessories as separate objects glued together in sub-editor called “Character editor” inside Sanbox editor. Character editor also allows to select specific material for the piece of chracter. One could more or less ignore this system and just have a character consisting of one mesh, but this takes away the flexibility.

For OOC I have decided to make as good use of Cryengine2 character system as I was able to figure out . As far as I know, for now and for the most common talan characters I have ignored (on purpose) only one available feature and that is thin and fat meshes of the body and abused the same system for heads, but I will talk about this in second article that will go online soon.

I will start my explanation with what is happening in 3dsmax. There I took the dual-skeleton approach. Dual-skeleton approach means that there are two skeletons. The first skeleton is the one that is supposed to be animated, therefor called “animation skeleton”, “anim skeleton” or “anim rig”. The other skeleton is the “export skeleton”. Export skeleton as the name hints is meant to be exported and is meant for both, export with character meshes and for animation. Now the important part is that this export skeleton is constrained to the animation skeleton, so any motion on the animation skeleton moves the export skeleton too.

This approach has a few advantages, for example:

• Cryengine is using skeleton geometry as physical ragdoll and hit detection geometry and therefor the skeleton has to be shaped to fit that purpose. Such a shaped skeleton may not be very animation friendly, so using dual-skeleton approach, export skeleton may be shaped wildly and it doesn’t matter for the animation skeleton.
• Using dual-skeleton is much more flexible when we get to the point of making the rig more complex with some fancy features. This is because cryengine and other game engines may be expecting certain standards from the incoming skeleton like hierarchies, names. When we have two skeletons, export skeleton can be build with the engine rules in mind, whereas animation skeleton may be build with animator in mind.
• Another advantage is that export skeleton may be simpler in terms of different helper bones and helpers. Animation skeleton may have many different helper objects which may not be required for the export skeleton.
• Surely some more advantages

Now a bit about optimizations. For characters to move in game, vertexes of the character’s mesh have to be assigned to the bones. This process is called skinning. In cryengine up to 4 bone may influence the motion of one vertex. For example Loras has around 8000 vertexes as a complete character and as far as i know those 8000 vertexes have to be transformed to bone motion many times each second. So that may be lot of math running in the background. Usually these days all that math is done on GPU (hardware skinning), but could be running on CPU too.  As far as I know CE is using hardware skinning (please correct me in comments if I’m wrong). Either way, it’s always good to optimize how many vertexes will be transformed and this is even more important in games with many characters and we all know we would love to have really crowded streets in Open Outcast.

So to do a bit of optimizations for our characters, we have a few different body meshes, one is full naked body (don’t worry, they always will have some clothing ), then we have a few versions with parts of body cut away – body without the whole torso, body with hands and feet only and a few other. We are also using LOD’s for the bodies.

And back to Character editor. When character is glued together in editor, it is saved out as a definition file with .def extension which is actually a xml file. When creating a new character one has to start with some mesh. Usually this would be the naked body or some simplified version (part’s cut away) of it. I wanted to have this a bit simpler and a bit more flexible. Therefor we are using one extra mesh for our talans that ties them all together. This is a file/mesh called TalanSkeleton. This mesh contains only the bones from the export skeleton and a little triangle mesh. This triangle mesh serves for the exporter to export the skeleton at all . In character editor we then open this TalanSkeleton and start attaching different meshes including the body, head, clothing, accessories and decals. We also have to assign different material variations.

Hope you enjoyed reading and if there is anything not so clear, let me know and i may update the article or make a new one if there is more to talk about.