Could the real Isaac Newton please stand up?

HEY! Do you happen to be a programmer with good experience in:

- Newton(2) Physics library (you made some advanced projects with it)
- Inverse Kinematics & Skeleton Animations

Ifso, I need some good advice. Sooner or later this year I need to update the physics part. Although I know how to use Newton 1 a little bit, I won't call myself Isaac. So before doing stupid things...

It's not really a programming job offer (but who knows), more like a request to have 1 or 2 experienced people on my side to mail with to dry my tears when the computer said mean words again. To give an idea of what needs to be done:

- Player movement (including @#$ stair climbing)
- Inverse kinematics (feet, hands, snakelike monsters)
- Combine Physics & Animation & IK
- Physics: proper behavior of all objects (now they react "unnatural" on collisions)
- Joints (swinging lamps, chains, doors, ...)
- Advanced raycasting for sensoring the environment
- Trigger volumes (player inside a water mesh?)
- Buoyancy
- Material feedback (on what kind of floor am I walking,
what type of material did I just shot?)
- Hitzones (headshot, hit his balls)
- Collision sounds (hit, scrape, roll, bang, snap, crack)
- Destroy stuff
- Ragdolls
- Multithreading optimizations advise?
- Pour in the engine or a wrapper DLL to simplify

I tried to ask on the Newton forums several times, but let's say my answers often don't get answered there. So, I prefer a personal coach;) On top, Newton 2 has quite some nice new functions, but I'm totally new to them. And last but not least, I’m stupid so please only react if you are patient enough to explain things to a 3-year old. Oh, and it is on voluntary basis of course.

Sounds like fun to have an advisor role? Then feel free to contact me (see "contact" link on the right). Ciao.

Esperanto++

Let's pick a fight :) Not with Gadaffi, but with the C++ camp! NAVO gunships ready? C++ Anti-Aircraft guns ready? Propaganda machines ready?


Are you like me, doing 100 things at the same time for your projects? Yesterday it was ambient lighting, today controls, tomorrow a sound system. Professionally-wise, probably not the best way to get things done. But, since I'm not making this game(engine) on a professional basis anyway, I don't care. As long as it is fun. Motivation is key-factor #1 when it comes to accomplish big things.

So, one of the tasks is updating the sound module to FMOD. OpenAL is nice (and free), but FMOD comes with free coffee, bonus points, and a cool badge. For example, FMOD has a tool called Designer to make the sound libraries. It supports many formats. It does a lot of memory and sound priority management for you. It is multi-platform. It has 3D reverbs. And especially sweet: you can define 3D geometry for sound occlusion. So, I'm making a DLL wrapper, see pic. More details will come when I'm done implementing it.

Engine22? Yeah, we figured a name would be handy. Not the most creative name ever, but I like simple names (Like "Source", brilliant). It doesn't imply to be the best thing since sliced bread. It just does what it's supposed to do: Run Tower22!


Funny detail. Instead of Delphi, I chose C++ to write this wrapper DLL. For two reasons: don't want to make FMOD headers. And B: it's good to refresh the skills once in a while, it has been a while. I use C pretty often for microcontrollers & shaders, but it’s really not the same as C++. The problem of using less popular languages like Delphi, is that you have a limited source of info, downloadable units, examples and forums with helping hands. Then again, I always get reminded why I like Delphi so much when doing C++. First, the old MSVC 6.0 IDE was kind of minimal comparing to the rich Delphi IDE. That changed with MSVC 2005 and higher, which is an excellent environment if I may say so. However, old grumpy C++ himself didn't change a bit of course.

How to put it... C++ is like rocket science, playing with dangerous Godlike powers, reinventing the wheel every day, talking old traditional Chinese to kids, baking a cake with the CERN, flying a thunderbird VI with Russian instructions, reading the entire Bible every day just for fun, sadomasochism for the advanced, bit tripping, writing pyramid hieroglyphs. Choosing the path of agony for the Greater Good.


First there is C. Basic, pure, yet mighty. Kind of cryptic when comparing to more readable languages like VB or Pascal. And of course, pointers don't have remorse for beginners. But you'll love it as soon as your microcontroller is doing a LED disco. You don't need to understand the whole concept of OOP, mastering hundreds of libraries, API's, frameworks or design strategies made up by other people. It's just you and C, blood brothers. Type what you want, and go.

Then there is C++... The evil little brother of the old friendly giant C. Still pure compared to other languages, not that much different at a first glance, but expanded with OOP in a rather horrible way. Not horrible in a functional sense - it's probably the most powerful language there is - but horrible in terms of user-friendliness. Where other languages tried to simplify things by presenting coding strategies with some human-logic, C++ took the bumpy path.

The already difficult syntax got even more tricky, and countless of options and boobytraps will make sure the newcomer pees his pants. I wasted hours and days, with vague errors. The compiler doesn't help you with "look here sir, you can't assign text to a numeric value.". Instead it barks angry C++ compiler messages that require a translator. And once you thought you solved them, the program still doesn't run because of that #@#$! Linker. Things got re-declared, Header files included in a wrong way, strange symbols, whatever.

Off topic. Another room for the next demo in progress. Far from done though, all the interior objects still have to be made, and all the textures have to be replaced with our own work. But ok, previous week it was still a MS Paint drawing.

I know, it's a matter of learning. And still, C++ is the most popular language when it comes to gaming engine. Because of its purity, and thus potential performance (IF, IF you use it right). And probably because "the others do it" as well... ? So, the good news is that there are many forums and helpers on the internet to save the day... However, it strikes me that many C++ programmers are just as user-friendly as their language is. Jesus Christ. While other communities are relative friendly, helpful, and patient, the C++ disciples are strict and edgy. Little Jimmy, 8 years old, from Illinois wrote:
"Dear friends,
why is this not compiling:
. float factorDiv = 1 * 2 + 3;
. int a += b; // <- error
"
The first answer never try to advise something. It's just: "Is this C or C++?(angry)". "Which compiler are you using?". "I can't solve the problem without seeing the entire code". “read the forum rules.”, or "why are you using factorDiv"? Valid questions maybe, but the undertone is like “get lost boy, we don’t take your kind around here.”. Yes, you should feel stupid.

It's if those C++ guru's are frustrated by their own difficult language. Pissing about small details, and always in a bad mood. Ok. ok, ok... a little nuance. It's not all that bad of course. I got helped more than once by C++ guru's, in a kind way. And remember, languages don't put spelling or grammar errors on paper, you do. And... it has to be said, some guys just don't know how to ask. How many times I've read something like
"Hello. having probs wit code blow. could u look @ it plz? I ned quick reply becuz this is
for school tomorow :#
--- 500 lines of (shit)code ---
"
Yet, while searching the internet when having a Johny Quest error message again, the atmosphere in some C++ forums is just different. This language is the hardest to master, maybe that brings some arrogance to the pro's. But allright, my C++ DLL runs now, and it can be used by a Delphi program. Not without a struggle of course. C(++ whatever) thinks it's a good idea to change the export names of your functions. Even when using declarations like
- extern "C" __declspec(dllexport) void __stdcall lickMyButt(){}
the "mangling" still happened. I had to use "dependency walker" (nice little free tool to analyze the exports of a DLL and what other libs it needs) to discover why my Delphi app couldn't find the entry-point. Strange, because another DLL with exact the same declarations DID work. When replacing __stdcall with __cdecl, the problem was gone. Uh... ok. Trying to find a logical explanation - no way.

Call me a n00b R-Tard amateur, but how come that ALL other languages I know don't have this crazy backstabbing tricks? I know why C++ changes names: so you can overload the functions with different parameters. But why not warning about it, or disable name-decorations and forbid overloading export functions by default? I'm sure the C club has arguments, but fact is that other languages solve this problem with ease.

Just another typical C++ struggle I had last days. Hey, C++ is not crazy, the rest of the world is crazy. But it works now, and especially with a hardcore language like C++, that feels good.


What kind of sound to put here?

Compiling:
error C4430: - 22 bad-English syntax errors - \blog.h 46
error C2310: - 3 falsehoods found - \blog.h 47
warning: - don’t take it all too serious! -
Happy debugging! --

Puppeteer Part #1

Hot damn, seems mama Earth is angry again. Tectonic violence, God frustrated, Godzilla, who knows. Thank God the death toll didn't exceed a 5-zeroed number like in Haiti or the 2004 tsunami. When I saw that monstrous whirlpool (wtf, I thought only cartoons had these), and massive waves swallowing up everything with the greatest ease, I expected the casualties to be a lot higher to be honest.

Nevertheless, what a drama. And now that Fukushima reactor. Not only is it still threatening with a meltdown, the whole economy in Japan (the number 3 economy in the world) is offline. Yet, one cold comfort, I was amazed how calm the Japanese people remain. No chaos, plundering, raping or complete dismay. They behave like intelligent, civilized people. Hard working has never been a problem for the Japanese, so I'm sure they have the knowledge, strength and will to overcome all of this. You can do it, let the sun rise again Japan!
-------------------------------------------------------------------------------


Ok, programming then. Instead of graphics I'd like to focus on something else for a change. Controls. You mean keyboards, Wii Nunchucks and that kind of stuff? Yawn. C'mon, everyone knows how to detect a mouse-click or how to check whether the forward button was pressed. Basic stuff, already invented in the Commodore 64 era. Hell, Pong era.

True. But how would you implement everything without knowing what to expect? When dealing with I/O, you usually exactly know what should happen. Sensor X goes off. Then engage actuator Y if analog value Z is lower than Setpoint W. Got to love the logic when dealing with PLC's or Microcontrollers. Clear & simple. Games aren't different, although the diversity of "output" goes a lot wider than switching a few relays or proportional valves. What happens if you press Forward? Pfff, just a grasp:

- Change animation to "walk" (if possible. Maybe the game is paused, or playing a cuts-cene, or you are dead, or ...)
- Move the character forwards... how fast by the way?
- Play sounds (GAS!, in case you drive a vehicle)
- Maybe trigger some A.I. (others can see you better, motion-detector sees you & triggers alarm, ...)

But it gets worse. Games are often context-sensitive. C.J. can walk & run in GTA, but also drive cars, bicycles, apaches, or even jetpacks. And in other situations that "forward" button (or analog stick) has yet another meaning. Like doing dance-moves in that annoying mini-game. And who says Forward = forward? Maybe you prefer the WASD keys for movement. Or maybe you use a gyro-scope sensor in the joystick. Or telekinesis.

Hence, who says you are steering a vehicle or trigger-happy idiot anyway? Maybe you are navigating through a menu, or playing Tetris. Controls(input) on themselves do not know what happens if they are triggered. Unless you hard-code all actions right behind the "onPress(key)" event:

procedure onKeyDown( keyCode : asciiCode );
begin
 case keyCode of
  13{enter}  : player.doHijackCarBiatch();
  38:{up}  : player.moveForward( doRun := isKeyDown(shift) );
  27:{esc} : game.escapeToMainMenu();  
 end;
end;

I don't like this approach though. First of all, you should be able to change the key-bindings. You can replace the exact ASCII codes with variables of course. But... what if you don't use a keyboard at all? If you plan anything multi-platform, dealing with different input is certainly on the menu. And how about complex controls (pressure sensitive buttons, analog sticks, gyro-scopes, motion detectors) that become more and more popular? Or… howto check a good old Mortal Kombat comb? (FINISH HIM! up, up, left, hold A 2 secs, tap B 3 times within 200 millisecs --> Raiden stuffed in Johny Cages arse, Excellent! Johny Wins).

Then there are also some conditions. The forward button shouldn’t work if your player is dead of course. And walking away during a cut-scene is just plain rude. Asides from all these little problems, I just don't want to hardcode the outcome of a key-event inside the engine core. Who says you are controlling a player at all? And who says it should "walk" when pressing forward? Maybe I like to use the same engine for a wheelchair racing game. Separating engine core business from specific game-related events always makes the design of apparent simple things a lot more difficult.

Off topic. New scene in the make. No, this isn't an engine shot. It's a simple Lightwave model with a MS Paint jacket. Got to start somewhere. By showing each other relative simple models like these, there is still space to suggest, improve, fix or to throw it away.

So… we need some abstraction. Both on input & output sides. I saw a lot of engines have a separate "Input" module (like a DLL), so I started there. This module simply detects input, and puts it in a ControlState we can pass further. Now you can't make EVERYTHING abstract. You could make the Input module so universal that it can handle a NES-8bit joystick, as well as a Space shuttle Simulator. But it will cost you (too) much time. So what I did was defining a list of common inputs:

- forward, backward, left, right, leanleft, leanright, boost
- action1,2,3, reload
- use, examine, pickup, drop
- get down, get up / ascend, descend
- jump
- toggle items / jump to item 0..9
- quick item 1,2,3 (flashlight, nightvision toggle, gun fire modus, etc.)
- team command1,2,3
- focus / aim / zoom
- inventory, stats, briefing, exit
- ...

As you can see, these inputs can be translated to most games. Whether you do a racing, RTS, puzzling or sports game: some navigation, menu and action buttons are always welcome. These inputs have a record with its current state:

TControlInput = record
   keybinding : integer; // Key/mouse/button to listen at <-- configurable
   isDown     : boolean;// pressed at the moment
   isPressed  : boolean;// from false to true
   isReleased : boolean;// from true to false
   pressure   : single; // 0..100% for analog controls. A keyboard button is just 0 or 100%
   releasedTime : single; // secs being released since last down
   downTime   : single; // secs being down currently
   tapCount   : integer; // Amount of presses within a short time
end;

// Polling the input (in another module) would be something like this:
if (controlState.input[ INPUT_FORWARD ].isDown) and
   (controlState.input[ INPUT_BOOST ].isDown) then --> run

With that info, you can check if a (mouse)button is down, but you can also check for more complex controls, like combo's or button bashing. I also store a few combined controls to make motion vectors (for analog stick, motion sensors, or gyro-scopes). Depending on pressure from 2 (X and Y) inputs, you can make a 2D position and motion vector. In a normal PC game, thise would be used for the Mouselook & cursor position.


Each game cycle updates all (active) inputs by polling the physical key, mouse, stick or whatever it is. What to do with the input depends on other modules, we just pass the info. Don't shoot the messenger! Finally there is also feedback to the Input module. Most joysticks have "rumble" or "force-feedback" function these days. Or other physical output (LED's, sound, buzzers, ...).

To make a long story full of stupid jokes a little bit shorter:

And what we got for all this? Well, we can remove some code from the main-engine. And believe me, less is better when your project grows and grows. But more important, you can reuse and replace this module. If the physical inputs require a complete different approach, we can make adjustments in the DLL or ship the game with a specific platform DLL. The outcome of the DLL remains the same, no matter what key-bindings or inputs you use. That makes input handling in the engine or other modules easier, and reduces the chance on errors.

So far the Input module. It can handle the mouse and keyboard for now, but you can also relative easily add other controllers for specific platforms, without having to litter the core engine or game-code. Next time I’ll tell how you can handle all that input without having to litter your engine with game-specific code.

Talking about input… Still have to make my own Zapper one day, so I can play Halflife with a real gun in my hands. Would be a nice Microcontroller fun project. Ah, another time.

Killing Spree

Progress anyone? Still toying around with the ambient-shaders. There is an annoying little bug somewhere, can't really trace it. Each time I change 2 letters in the shader-code, then reload the program... wait 2 minutes (with Windows 7 it suddenly takes 6 times longer to load ?!). Shit, typo in the shader. Reload... In the meanwhile, my daughter and I are watching old 1945 Goofy cartoons on the right side of the screen. In other words, not so much progress.

The others were busy as well. Visiting the GDC (Game Development Congress), doing a CG Society contest, or earning money (not totally unimportant). Most progress was probably done in fantasy-land, in the upper chambers. Drawing floorplans, and Robert made some character sketches. Lot's of ideas have been written down. But... without actual 3D content all those ideas still aren't worth much. Maybe I should make some simple test-maps in the meanwhile. Just to try out some new mechanics that have to be implemented... Such as climbing a ladder.

Hello, my name is Custard pie head. Piece of sketch from Robert looking around the corner. One of the (fun!) things to do is to create a huge base of sketches & ideas. Then a jury (Tyra Banks, Sharon Osbourne and Dolph Lundgren) will judge which ones go to the next round.

I Also had a look at the Crysis 2 Multiplayer demo. Ah, that's always frustrating. Just when you are catching up with all the graphics, those bastards at Crytek sweep the floor again. As suspected, it looks darn good (even though the realtime ambient lighting isn't that accurate). On the other hand, I didn't had a real good chance to observe everything though. Each time when I was looking peacefully at the flowerbeds, bumpmap walls, reflecting floors, or the indirect light casted by a TV, I got killed by some asshole with a shotgun. No, Multiplayer games aren't my piece of pie.

Then I realised again that awesome graphics still don't make a game refreshing. I can't judge Crysis2 based on small demo of course. But asides the good looking futuristic maps (no jungles this time), I doubt if this shooter will be truly innovative (like Farcry was). At least the Multiplayer was the same as usual; 10 guys running around like mad, firing 500 bullets per second, having an average lifecycle of 11,74 seconds.


Multiplayer games... Always enjoyed beating 1.000 Footclan ninja's in Turtles in Time(snes) together with my little brother. Arguing together because of Mario Kart. Sneaked for hours towards German bunkers in Hidden & Dangerous Cooperative modus. Then end up fighting again because either my brother or I threw a grenade only 1 meter far, killing the whole squad. Had quite some fun building custom maps for Age of Empires II, then playing them together with friends. Usually I had a large empire, and the others were placed in slave-camps to break out. Revolution mid-east style. Favorite multiplayer game? Goldeneye (n64). Also liked the Counter-operative modus in Perfect Dark (n64). Why do proper shooters such as Halflife2 never have a Coop or that Counter-Operative modus? Those shitty mods never work very well, or get released 3 years after when you already got tired of that game. Oh, in case you wonder what “Counter-Operative” is: one player had to finish a normal Single-Player mission, as usual. The other could take over control of a random (weak) foe. Pretty fun to look play a map from the CPU perspective.



But "fragging" other strangers in Quake, Unreal Tournament, Crysis or Battlefield? Hmmm... no. In theory those team-based multiplayer games sound like a lot fun. Realistic opponents, real teamwork, headsets, planning tactics, helping each other... The few times I played Battlefield 1942, I stranded up the front cover of a jeep, driven by a guy named "Joop". 20 seconds later the jeep with the two of us drove into a cliff. A tragically but fun dead. Tactics? Everyone who spawned stole a tank or airplane ASAP, then to commit Kamikaze in the enemy camp. So I decided to go bananaz as well, hi-jacked a Aircraft Carrier ship (every soldier knows how to steer those) and crashed the big boat onto Wake Island. To get scolded for "fking n00b!#!", "lame-ass, pls ban that dork" or "GWEG34 ROLFOL" whatever that may mean.

Turns out these soldiers were bloody serious about there defeating the Japs after all. Like real killers, they ran into an enemy base, started unloading their M1-Garand on another Japanese while circling around each other at high-speed in a bloodcurdling duel on life and death. Running, shooting, jumping, crouching, firing bazooka’s, reloading… Who would fall first?! Realism. Now I finally understand what our boys went through in Afghanistan. Running circles around "n00b!" shouting terrorists, throwing grenades at our guys. And even worse, the fallen ones get humiliated; the terrorist "p0wns" him by repeating jumping and heeling on the dead body.

I did the same. With the 7800 tons USS Wake Island. Parents worry that games get more and more realistic.

Either you play it serious, or you make jokes all together. But playing such games with semi-professional 15 year old Killers is just stupid. At least for me. I'm sure a game like Battlefield offers everything to play the game with real general Patton or Navy Seals tactics. But unless you organize matches with clans & playrules where each fills his role seriously(medic, defensive, assault, scout), it just doesn't happen. People don't know each other, medkits are used to knock out the enemy, and dying because of stupidity has no consequences. Just wait 20 seconds (or 2 minutes for Counter Strike) and you'll be back in battle. All that really matters is your score. The more kills, the better. Your teammates help you, they run into the frontline with Duke Nukem Reaper cannons, destroying everything that moves. Then to get killed themselves 2.5 seconds later.

And even if you are slowly sneaking through a map, taking good care of yourself, you'll get banned because of "camping" (staying hidden on the same spot all the time). That's what happens to deserters.



If I had to make a multiplayer game, I would the force the players to follow a 2 week bootcamp with a fixed assigned group of fellow-recruits, under the lead of capt. Sobel. Then when they get killed during a campaign later on, they have to restart or shut the game and do their homework for school. But hey, that's just me. I'm old and grumpy, and a few billion others enjoy p0wning each other on a chaotic battlefield, so maybe I should shut my mouth.

Will T22 have multiplayer then? Hmmm, probably not. Although I do like co-operative games. Or maybe let the other one take control of the enemies. Only problem is that story/puzzle driven games usually don't lend themselves very well for multi-player, because of the specific triggers. If you get locked in a room with a time-bomb that requires a puzzle while the other is sitting on a toilet two stores below, the scripting sequence could mess up. You really have to design a game for cooperative action (like they did in Resident Evil 5 for example).

On top, a horror game like this won't be that scary anymore if you can baseball-bat opponents like a bunch of drunk hooligans. And since T22 isn't exactly a combat game, having a partner doesn't add much value. You could just as well invite your mother to look over your shoulder at the PC screen, helping with solving puzzles. But who knows... Despite my grumbling above, two doubles the fun. But maybe we should finish a second demo first, don’t you think?


Got a couple more building photo’s from a friend. I couldn’t decide which was the worst so I just posted one. Dunno what kind of architects they had there, but it looks like someone won a box stacking contest from the local supermarket. Hey, if you live in one of those things, feel free to send us a vacation card!