CryAckermann (in short)

Ever wondered how the vehicle steering is implemented in CryENGINE? Actually there is nothing really special about it as it simply uses a well known steering geometry implementation: Ackermann Steering.

The more interesting part is how you can use it to define which wheels or axes are steering in CryENGINE. By the way: You shouldn't use more than 18 wheels as this is the default maximum amount of wheels supported. But that should definitely be enough for 99% of the usual game scenarios. So when applying an Action to a wheeled vehicle in CryENGINE you can always define an Ackermann Offset which defines the wheels/axes steering the vehicle. Using an Ackermann Offset of 0 (default value) will set the front axis wheels as the steering wheels. Setting the Ackermann Offset to 1 will use the rear axis wheels as the steering wheels. The most funny setting is obviously if you use an offset of 0.5 which enables steering with the front and rear axes.

You can easily test it in the available CryENGINE 3 FreeSDK. Unpack the Scripts.pak inside the Game folder and open:

Game\Scripts\Entities\Vehicles\Implementations\Xml\HMMWV.xml

Search for the ArcadeWheeled tag and add a new attribute called: ackermanOffset="X.X"
Setting it to either 0.0, 1.0 or 0.5 will have the steering effect mentioned above.

CryENGINE 3 Game Development (Review)

Back in 2004 when i started to play around with the first iteration of CryENGINE all we had back then was the game FarCry. Compared to today we had no documentation at all, so most of us were just self-taught people playing around with an unknown piece of technology: CryENGINE 1.

Of course we had our good old FarCry Modding portal to share information and we were so happy once some Crytek Devs actually started to answer some of our questions on the forum. Today there is a lot more information available for a beginner. The forum, online documentation, tutorial videos etc.. But the main problem for a beginner is: Where do i start?

The forum doesn't really solve that problem as it's more a chaotic collection of information, sure it's useful information (if you know the right threads), but a beginner won't really find the information he needs to start doing stuff. Especially not in an ordered way. Also the online documentation can't really solve the problem as it's main purpose is to store all (possible) information in one place. A bit too much for a beginner.

One solution, even if it's a bit old-school, is to read a (real) book about a certain topic you are interested in and to be honest that is even the best way to start. Of course you could just put the full book content online but it's still not the same. Switching between online documentation and the tools you are using can be a bit annoying after a while.

For CryENGINE development there are actually 2 books available:

This review is about the latest book: CryENGINE 3 Game Development by Sean Tracy and Paul Reindell. Even though the book cover states it's a "Beginner's Guide", also experienced CryENGINE users will gain some knowledge out of it. If not... well... Hail to the king, baby!

The book itself is published by PACKT Publishing and is available as a printed and an e-book version. Especially for learning new stuff i personally prefer a printed version but... that's just me. On 320 pages you will learn about a wide variaty of CryENGINE features, obviously it won't cover everything in detail but that's perfect when you start with a new piece of technology. No one really wants to be overwhelmed by too much detailed information, especially not a beginner. And if you are interested in more information, once you understand the basics, you can move on to the forum, documentation etc..

The book actually starts with a quick overview what CryENGINE is, where it comes from and for what kind of games it was used in the past. It also gives you a quick introduction about the CryENGINE 3 FreeSDK, which is used as a base for all examples across the book, so everyone can play around with them right away. What i really liked was a short explanation about the typical roles in a game development team, which should give most beginners an idea of what maybe their own role would be in such a team. As mentioned before the whole book is example based, so you won't get too much boring theory. Most examples are structered in a couple of sections:

• Short introduction with not too much theory
• Time for action to actually create something right away
• Short summary what just happened
• Optional task for the reader to play around with the learned stuff
• Optional small quiz to check if the reader really understood what he just read

After getting some information about the Sandbox Editor basics the reader will directly start to create his/her first level. Guided by the author it is really easy and fast to see some results on the screen. The good thing about it is that it's not just "Click here, click there", the reader will also get information about why he/she should do it like this or about different ways to achieve the goal. All examples are full of screenshots which makes it a lot easier to follow them. They are only black and white in the printed version but you can download the colored screenshots online and to be honest the quality of the printed screenshots are actually more than good enough to follow the examples. 

Once a basic level was created the reader will learn how to add more (dynamic) stuff into the level. Entities, AI, Spawnpoints, Roads, Layers, Brushes and Solids are just a couple of features the reader will play around with. At this point everyone, even experienced users, should be on the same page with CryENGINE and Sandbox Editor basics. 

Now the book starts with the fun stuff: Scripting! This not just includes Visual Scripting (aka. Flowgraph) but also the communication between Flowgraph and Lua, debugging Flowgraphs and playing around with the AI. 

The next big step will be an introduction into C++ and how to compile the Game DLL with some code changes to finally script a custom Entity, including Scriptbinds to communicate directly with C++ from within Lua. Don't worry if you are not part of the Programmer Species, it's well written and covers all needed information for the examples.

"One of my most productive days was throwing away 1000 lines of code."

     — Ken Thompson

The next part of the book is all about Scaleform (Flash), how to create your own HUD (Head-Up-Display) from scratch, bring it in-game and how to test it directly in the Sandbox Editor with the included UI Emulator. A very nice, detailed and interesting section of the book. As a side note: The author of this chapter wrote the actual core system of the UI used in the CryENGINE 3 FreeSDK, so the reader will definitely get some detailed information.

The HUD is actually the first custom asset (apart from the Entity) the reader will create, so the obvious next step is to learn how to bring even more custom assets into CryENGINE. From basic static objects, over destructible objects to skinned characters and animations the reader will get a really good overview about the asset pipeline in one big chapter.

Creating Real-Time cutscenes and Cinematic Events with custom assets or existing ones is what the reader will learn in the next chapter. Animating Cameras, animating Entites and video capturing are just a few keywords which are covered. You want to be the next James Cameron? Go ahead, you will definitely learn the basics to create some cool cutscenes or machinimas yourself.

Everyone knows Hans Zimmer i guess? The god of film music? If someone wants to be the god of his/her game music and sounds the next chapter of the book coveres using the included sound entities and existing sounds but also how to use the FMod designer to create custom sounds and bring them into CryENGINE. Sound and Music are actually the most underrated parts of a game, so read it carefully. It can make the difference between a good and an awesome game experience.

The last chapter is all about how to debug the game and share it with the outside world. Especially debugging and getting an overview of the most important console variables to actually find the problems in the game is a must have knowledge for every future CryENGINE game developer.

So is this book worth buying? Definitely Yes. For a couple of reasons. First i know the authors. No seriously, it's well structered and gives the reader all needed information without overwhelming him/her. I wish i had such a book back in 2004 to start with. It would have saved a lot of trial and error hours... If you buy such a book as a beginner you don't want to read too much about theory, you want do something actively. You want a proper guide on how to achieve a goal and you want to achieve this goal as fast as possible. All of this is actually well done by the authors of the book.

Links:
CryENGINE 3 Cookbook (Packt)
CryENGINE 3 Game Development (Packt)

CryENGINE 3 Cookbook (Amazon)
CryENGINE 3 Game Development (Amazon)

Cheers,

JR

Which Game Engine is the best?

Seems like a valid question and it is also a common starting point for rediculous and endless discussions in hundreds of forums where it sometimes even turns into a cat fight. The problem is there doesn't exist "the best" game engine (surprise...surprise), only a game engine that fits your needs "the best". So simply one you prefer, but it doesn't mean everyone else would prefer it too. That could be an in-house engine developed for only one specific project or a comercial one, where you spend the time you saved developing the core engine in adding additional functionality instead of reinventing the wheel. But the biggest benefit you gain is obviously the engine frontend you get for free, which is the weak spot of most in-house game engines. In my case i always prefered CryENGINE (Captain Obvious Rises), but i wouldn't say it is "the best", at least not in discussions. It's the same as saying: "I have the best Mom in the world!". Of course you have, this little planet is full of "the best" Mom's. Isn't that awesome?

"Didn't you see [insert random marketing screenshot] of Engine A? It looks far better than Engine B!"

"Are you serious? The Engine A [insert random marketing video] shows that it looks far better and everything is realtime, same as in Engine B!"


"Of course there exists the best engine! Engine A has Feature Z which Engine B doesn't have! So Engine A is obviously better!"

If you really argue like that and think that it is the right way to discuss what kind of game engine you prefer i feel really sorry for you and i hope you don't work in the games industry and you hopefully never will. First of all saying that one engine is superior over another engine based on a marketing screenshot is like saying those magazine cover girls are looking the exact same while buying stuff in the supermarket. Of course they never had a date with Captain Photoshop. A static scene simply doesn't say anything about the real capabilities of a game engine, which you should know is normally not used for static scenes. Of course you can squeeze the shit out of a game engine to get this fancy looking, marketing fulfilling one screenshot. A bit of Captain Photoshop magic and BAM! The best game engine in the world is born, right? No.

"Ha! So a video makes your argument obsolete! It is not static! It's like playing a game!"


But a video can be "optimized" the same way as you can optimize a screenshot. You don't care about the framerate while recording it, you can enable ridiculously high settings for all of the rendering features your game engine supports (which includes resolutions you could never use in a game). You simply don't care if it in the end renders with 1 frame per second, but you do so while playing a game based on a specific engine. Most of the time you simply render out single frames similar to an offline renderer.

"Ok! But if Engine A has Feature Z which Engine B doesn't have and the rest of the feature list is the same, Engine A is obviously better! No matter what you say."


Ok, let's say Engine A has this awesome new rendering feature and i will tell you a secret: sometimes it is just a different name for an already well known feature... but let's say it is really a cool new feature no other engine has. Imagine this fancy new feature is on the feature list of the engine, even an awesome screenshot / video exists, but do you really know the drawbacks of that feature? Do you know if it is well optimized and works well together with all other rendering features? Or is it limited to a specific way of presenting a scene and can't even be used in all possible ways without cutting your framerate. And even if this fancy feature is super optimized and doesn't really impact your framerate, does it mean this engine is far better just because of it? Nope. Do you know the exact profiling numbers for every rendering feature both engines have in common under the exact same conditions? What if Engine B misses Feature Z for a reason, what if Engine B's Feature X is 5 times faster than Engine A's implementation? Is now Engine B the best? Imagine you don't even need this fancy feature...scary.What if all rendering features are equally fast but it's a pain in the ass to actually create a game with this "graphics demo / benchmark" Engine A? Is it still the best? I guess designers, programmers and artists in the games industry would say: "Hell, no... i don't want to waste my time...", some of you would just say: "Hell, yes! It looks better, that's all that counts...N00b!".

If that would be your answer simply "goto line 1" of this blog post. So maybe the next time you try to fight for the one and only game engine across the internet you should instead just try to present a list of arguments why you prefer a given game engine and listen to people who might have different preferences.

How to successfully create a game (modification)...

...or at least "how to not do the common mistakes while trying".

Being in the CryENGINE Mod-Community for almost 8 years showed me the ups and downs of the next AAA game (modification) developers and all the common mistakes you see over and over again. The first obvious mistake most people do is to spend too much time on finding a team name, some even create threads on forums to find a proper one. Pretending that you are: "A Company", "A Studio" or whatever with a fancy team name like: "1337 Game Productions", "NoTech Studios" doesn't help you to create a good game (modification). People wasting so much time to find a name instead of thinking about proper game design, game mechanics or just playing around with the engine itself, testing stuff, reading the documentation, prototyping ideas... It's crazy.

"Guys, finally we have a name: BlaBla Productions! We are so excited! THANK YOU!"
Awesome and you only wasted 1-2 weeks for it. You all know what comes next, right?:

"But now we need your help again... We need a name for our first big project! HELP PLEASE! We thought about something like Crytinator!"
How about: "CryBam", "CryMoon", "MoonCry", "Gears of Cry", "Crytastic", "Cry me a river". Why do you want a Cry in your game (modification) name? Apart from the Cry in the name, did you spot the master mistake?

What project? What is it all about? What kind of game (modification)? Any information? Did you even think about that before you posted on the forum? Or you are even allowed to read "the one and only" (Captain Obvious) idea:

"Nomad Inc. searches for people for the first big project. We want to recreate Battlefield 3...but better!" 
BAM! Fail!

"Counterstrike?"
NO!

"...we want to bring Minecraft to CryENGINE..." 
BAM! Fail!

Seriously, you want to clone an already existing concept? By the way, in most cases, those people post a few threads later that every AAA game developer sucks because they are just creating Battlefield, Modern Warfare or Call of Duty clones or just booooring sequels. Ouch!

Don't get me wrong, i saw awesome "clones" recreated with CryENGINE but those people usually just do it behind the scenes with proper motivation.

Sometimes the project even sounds really promising because they start with something like the following:
"...after 2 years planing the actual game design we came up with something you never saw before:"
Normally you would think: "Ok, where is the 1000 pages PDF attachment?"
Nope, they compressed the whole 2 years into 10 sentences. Pretty impressive compression algorithm if you ask me. I'm in!

So what's next? We have an awesome team name, an outstanding project name, a fully compressed game design and? Correct, you post: "How do i start the SDK!?!?" on the forum. I mean seriously, there was no time to read the documentation, so that is obviously the first step and you can't find the damn SDK.exe! After 20 minutes of waiting for a response you have to bump your post of course. After 24 bumps and 34 minutes (!) of waiting you start to insult everyone who didn't answer because: "!§$§!$!§$ N00BS!!!1111"

Some people finally find the documentation and start the production of the next awesome AAA game (modification). The first terrain is done, some random objects are placed. You can even go in-game and shoot! (*cough* out of the box *cough*)

So the next step is? Correct, IT'S TRAILER TIME! I mean, you spend almost 30 minutes on this masterpiece and you need more people, so you definitely need a trailer to advertise your concept! Every big developer does it, right?

*Hans Zimmer Music starts*
"NoMercy Productions proudly presents..."
*Fancy Adobe Premiere effects...*
"Something you never saw before..."

And i don't want to see again.

Talking about more people... Never ever ever ever call yourself: Founder, CEO or President of an imaginary game studio. And never ever post your actual team list like:

- CEO / Founder / Lead Programmer / Lead Level Designer: Myself! (frag0r1998)
- Co-Founder / Lead Game Designer / Lead Sound Artist: My Brother (gam0r1986)

Open Positions:
- Lead Scripter / Game Programmer
- Senior AI Programmer

"WE NEED AT LEAST ONE MORE CODER!"

To all programmers out there: Run! Run for your digital life. You will live in slavery with vague or ridiculous feature requests.

So your project grows and grows (almost 2 days in production!) and wait, what's that!? A BUG! NO WAY! N00BS! THAT IS A BLOCKER FOR YOUR PROJECT! THAT PIXEL DEFINITELY LOOKS WRONG! FORUM TIME!

"This engine is full of bugs! I will switch to ENGINEXYZ if Crytek doesn't fix it! I can't work on my project! It's a blocker! AND BTW IT IS EASIER WITH ENGINEXYZ! NO BUGS AT ALL!"


And i'm the President of Uganda. No, not really. In most cases that is the end of this promising next AAA game (modification), that pixel definitely made the difference. Maybe you will see a "reunion" or "comeback" a couple of weeks/months later, but it won't last that long.

I told you so many things you should not do, but how do you really create an awesome game (modification)? The funny thing is it is pretty easy but also close to impossible:

Fun, Motivation, Ideas, Luck, Passion and Time is all you need.
[/0x00000000]