2004/8/6

This is my first dev update for netKar Pro. I will try to keep this as a constant appointment for people curious to sneak behind the scenes of this project.

At the beginning, I will be forced to keep my reports pretty generic. We don't want to generate false alarms or any possible misunderstanding about what nKpro is going to be, so please keep in mind that every conclusion you might come up with reading these docs is just that: "your" idea :-P

netKar Pro development is divided into different phases; these phases will bring us to the final product and the release of v1.0. This is to say that nKpro is not "features-driven" but "time-driven", meaning, I will stuff as much as I can into the given time costraints.

The first phase is dedicated to graphics, and I am working hard together with Alessandro "Outrunner" to enhance nKpro's graphics experience. Alessandro came out with a big break-through yesterday about shadow generation, I am finishing the code to support his idea so we can try it in-game.

netKar Pro has a much more "professional" approach to 3D editing. The original plans for netKar's 3D engine were assuming no artist working on the graphics, so everything had to be as much automatic as possible. This meant building a series of "rules" to import files from editing packages straight into netKar trying to match the various parameters in the best possible way. This cut down the 3D development process drastically, don't forget that, about 70-80% of the 3D present on the first 0.9.0 release of netKar and the 100% on the Alpha versions was made by be and at that time I would have never imagined to find myself in the position of having a great 3D artist working on the game "full time".

The approach now is based on a custom 3D editor that sits in between the 3D editing package and the game itself; in this editor the artist is able to change dozen of parameters for each texture pass and see the effect of his changes in real time becase there's the 3D engine up and running on another window.

It was a bit of a mess trying to come up with a decent solution to integrate the 3D engine and the user interface needed by an interactive editor. I've looked into many solutions to solve the problem of my 3D engine being based on Microsoft Visual Studio and my user interface based on Borland C++ Builder. I did a lot of hacking with the managed C++ extensions in VS but I've found very very hard to integrate managed code with non managed code, almost impossible.

The decision was to sitck to Borland C++ Builder and use UDP to setup a communication between the editor interface and the 3D "view application" written in Visual Studio, a bit complicate but easier than trying to come up with a custom GUI on the top of DirectX.

I am planning to have more experiments done on C++ Builder using DirectX9 and possibly able to run the 3D inside its own windows, it could be very useful to have a "rendered" view without actually starting the simulation.

This will bring up the cost for me a bit since my C++ Builder licence is only for non commercial applications, so I need to upgrade it to a commercial one.

Another big change done this week was the complete removal of the dll system used in nK since from the start. The new nKpro is 100% based on the nK|dK concept, so there is no need for a "car" dll anymore since the car infos are all stored into nK|dK database. This sort of complicates things a bit when it comes to new features and "special" behaviour; in nK 099 if I wanted something peculiar to happen on the MG I just had to load the dll's code into VS and write the behaviour in native C++. Now, when facing the same scenario I will have to think how to integrate this into nK|dK and then implement it in the game. It takes more forward thinking but, once done, it is easier to test on different cars because all of them are going through the same piece of code, so if ABS works for the MG it is supposed to work for XX.

From a pure software engineering point of view nKpro is simpler than nK 099 beacuse it is made of 2 exe files (the interface and the simulation) and no additional dlls since I've moved the old nkClient.dll code into nks.exe as well. There is a very small improvement in performance since the compiler doesn't have to cope with all the interfaces between the dlls module. Now the main application class (CKar2.cpp) has a direct pointer to a car class (CCar) and not to an interface car class (ICar).

Although not needed I decided to keep the code generation setting in VS to use the Multithread DLL libraries I still want to keep the possibility of "plugins" open. The scenario here is, if I really need to hack a very unique behaviour in a car, I can write a "plugin" to the simulation that can react to different events by implementing a virtual function and access the internals of the game. Probably AI could use this system, other good applications could be custom telemetry or strange devices like "fans" or movable wings.

Physics is just a blast, it's one of the part in nK where I would feel confident enough to release "tomorrow". Major bugs in ARBs and camber where fixed over nK 099 and now the car is just perfect, it does what you'd expect in every condition, and it is so "regular" that, once you learn to drive "ahead" of the car you can really have fun sliding around everywhere.

ARBs has been my headache since the beginning of nK because my original "assumptions" where all wrong. Every version of nK had a sort of "hack" to cure the problem.. but it is easy to find the problem in nK 099, just drive at Donington Long with a 3000 or a MG with very stiff ARBS. On the last "complex", the first left/right corner hit the kerb on the right apex and, it is very likely that the car will spin in the air out of control.. that's the old ARBs code going crazy..

That is a very evident manifestation of the problem but the "wrong" behaviour was infecting the car in every manouver, new ARBs code, months ago made Aris go wild on MSN with "what have you done? It is a DIFFERENT game!".

Camber formula had another stupid problem with a missing division by the load on the tyre making it seriously unstable.

After these 2 major fixes the only adjective that describe nK's physics is "smooth", actually, sometimes "too" smooth, we're looking into making the tracks a bit more "alive".

I've also rewritten from scratch the code for wall collision response, and I am very pleased with the results, now the car bounces witht he right amount of "structural damping", scratches the wall when hitting from a side and so on.

For Kidcodea's pleasure now cars don't disappear under the ground when flipped ;-).

I've added a "PayPal" donate button on the homepage. This project doesn't have anything to offer as download or something, but netKar "free" gave many people hours of enjoyment in these 2 years, so if you feel bad about it, that's the magic button that will take away your feeling guilty ;-).

It is a nice feeling to be back on this, it is a real stress that will drive me crazy eventually because I still have to divide my time between my job and nKpro, but it is amazing what a couple of hours difference on my alarm can make ;-), after all, I am lucky enough to be at just 10 minutes from my office, and that, in Tokyo, is a real priviledge. I hope nKpro V1.0 sells will solve this "problem" and allow me to make nK my only "to do" in my life.

back to you next time.

ciao

stefano