Combat Starter Kit code changes explained

I was not part of the CSK team from the beginning but I was lead developer on this kit for several weeks (full time - remote) amounting to about two hundred hours of C++ development before I departed from the team with all required coded changes completed . Several poorly informed people have made comments that this is just a bunch of resources thrown together to play nice etc. Well two hundred hours of C++ development time says otherwise.


Here follows a detailed explanation of what development I did for the kit. Hopefully it will help set the record straight..

About four years ago I made a cross country racing game using TGE and solved many of the inherent problems associated with TGE vehicles, including many collision improvements. All of those fixes and enhancements have been put into this kit. My own gearbox and engine rev changes are in here as well. Other people have since released resources to do similar but anyone who played my racing game will know that my version preceeds any of those resources by years. All these code changes amount to well over a hundred hours of debugging and development time which is above and beyond the 200 hours I mentioned before.

The tank was a huge headache to solve, The previous developers had tried to attach a mountable turret and have the driver control both the vehicle and the turret. But that led to huge lag problems and very jerky turret movement over the network, It took many hours of debugging to find what the source of the problem was and solve it permanently. It also required writing NEW turret movement code as part of the vehicle class. I chose to let the engine calculate the barrel and turret position rather than expect the artist to animate the movement over some rotational range. To use the tank you just mount a turret and a barrel, the source code will animate the movement for you. Likewise, the track animation can be a headache and traditional solutions require the artists to animate the track via UV animations. I dispensed with that by having the game engine animate the tank track texture for you based on vehicle ground speed. The artists just has to UV map a texture for the track and name it according to the naming convention. The game engine takes care of the rest. This makes it possible to make game content 'tanks' using 3D tools like Blender and Milkshape, neither of which could export UV animations at the time the kit was made.

I coded the commander map from scratch based on an initial idea I got from some terrain camera code written by Ben Garney. My commander map let's you pan and zoom across the map using your mouse (click and drag) or mouse wheel for zoom. Unfortunately most people are unaware of this feature because the map is initially zoomed out to maximum and people think that's all there is to it. It's very useful when you want to drop supplies to you troops in the field. You can pan across to their position, zoom in, then drop the supplies within a few meters of their location. The troops will see the supplies falling out the sky on parachutes. Really cool. The commander map also uses icons to display tanks, vehicles etc. This makes it possible for you to change them to suit your own game just by replacing the icon pictures. Another unknown feature is that the commander map lets the camera swoop down from the sky and attach to the player as he spawns, making a seamless transition from commander map to player control. This feature can be turned on via a setting in the commander map datablock.

The player climbing a ladder is also original code. There was a need for the player to climb a 90 degree ladder and it took many hours of delving through the player class to achieve a smooth, seamless transition from walking up to a ladder, climbing it and getting off at the top, ready for action.

I also developed code for parachutes which let players gently glide down to the ground with some slight forward thrust. There were many, many other fixes and enhancements to the player class, too numerous to remember. A new collision system was developed which uses the weapon tip as a collision point rather than have the weapon slide backwards when it encounters an obstacle. By default this is off but can be enabled by a setting in the player datablock.

Advanced camera work: This has nothing to do with the advanced camera resource. I had tried that resource back when I made my racing game and found it to be buggy and it even ceased to function when the camera left the initial terrain tile. So I developed my own camera code to do smoothing and neat 3rd person enhancements. A game camera is really important and should give you the view you want without intruding on the game. You don't want to draw attention to the camera, if you do then you have just taken attention away from the game. Test drive the 3rd person vehicle camera in starter.racing (default TGE camera) then test drive the vehicles in CSK in 3rd person and see the difference. I also modified the 1st person weapon camera to keep it upright even when the vehicle is bucking over bumpy terrain. Unfortunately most people don't notice the advanced camera work in CSK, because, you are not supposed to notice it.

The "capture the flag" code was initially a resource that someone had put in to CSK but it was very buggy and I was asked to take a look at it. Once I figured out what it was trying to do, I rewrote it from the ground up and handed it back to the scriptor (Kittle) who polished it to perfection. I also developed C++ code to efficiently send the flag position across the network to all clients. The artist now animates the flag with two frames, fully up and fully down. The script then sets the flag position between 0 and 1 and this value is networked to all clients so that they all see the flag at the same position on the pole.

When I took over development for CSK, the crawl,swim resource was already in place as was some helicopter code. The crawl, swim resource had a major bug in that it did not handle the player collision box correctly. TGE player code does not rotate the player collision box by default because keeping the box orientated per the game axis system allows for a less CPU intensive collision algorithm to be used. I spent many hows debugging the system to find where the changes need to be made to get the player collision box rotated in the direction the player is facing.

The helicopter code had very unrealistic physics and I was asked to polish that which I did and the result is much more believable and I also incorporated damage effects. The more damage the helicopter takes, the harder it is to fly.

There were may other small enhancements done, such as being able to mount an object with an offset. This is good news for artists because sometimes a mount node is in the wrong place and moving it can play havoc with animations. Being able to keep the node where it was but just specify and offset position for the mounted object saves the day.

TGE bug fixes. Many old time TGE bugs were fixed. The player weapon would sometimes vanish if you aimed it out side of the players bounds box. People used to "fix" this bug by making the players bounds box bigger, but this also makes the player collision box bigger. I spent many hours debugging this problem and got it fixed proper, at the source where the problem occurs. Also one of the C++ classes did not have the necessary network code for updating mounted object positions. Noticeable when you drove a vehicle away and parts of it remained where you had spawned it. Fixed in CSK but both these bugs still exist in stock TGE 1.52

I know there is much more that was developed for this kit but the above are the stand out features which come to mind.

I have only referred to the C++ changes but a ton of scripting work was also done, some by me but mostly by Kittle and I'm sure the scripting also adds up to over a hundred hours of work done.



I doubt there is any other TGE kit available that has so many man hours behind it.