O-GL/Desperado2185

Desperado2185

Desperado2185 is a fps shooter game set on another planet and in the future. The planet is newly colonized so it has wierd things crossing between western and futuristic such as robotic horses. It started out in January as part of a Gaming and Puppetry Course at the [Film & Telivision Institute]. It was basically me and 3 artists, one of whom decided to use the UT2003 engine because it seemed like it had alot of support.... Anyway, it took me a fair while to change over from c++ apps and start learning mods!

The guy which came up with the concept for the game had a very rough singleplayer script, with optional multiplayer deathmatch support later. I tried to understand and implement replication fairly early on, but I didn't understand some concepts of it back then and therefore my multiplayer progress was very slow compared to singleplayer code progress. The multiplayer aspect sorta went by the wayside when I realised there was a whole lot more I needed to learn about multiplayer in general. I felt I needed to disregard all current multiplayer design progression and figure it out on my own :s ... but that would take time, so I left it until after I had implemented the singleplayer script.

Desperado2185 Singleplayer

The singleplayer project ended sometime in August, and was quite dodgy, if I do say so myself. Basically, we have this town, and you have to go through it talking to people and stuff in order to get a train ticket out of the town in a certain time limit. The main problem with it, was that the character interaction was done with scripted sequences. I spent a hell of a lot of time modifying the unreal scripted sequence code to support things such as choices when talking to characters and handing inventory items to them (which in turn creates different choices for the user). I now realise that scripted sequences are NOT the way of the future ... the complexity can get too high and as such the interactivity is limited. In the end, I ran out of time tracking down branching errors in the source code that I basically got one interaction with one character done – and I couldn't be bothered with scripted sequences anymore. I think the way of the future is AI characters that have specified knowledge and abilities ... can some1 take some time-out to make an AI SDK plz!? lol

Some of the better things I had completed by August were:

1. Realistic hovering vehicle simulation code.

Ok, let me start by saying this isn't complete ... its just cool. Like .. I had it working back then, but I had some bob, so I reworked it and now its buggered and waiting for me to finish it off . Let me tell you something though, it was a great learning experience and hacks can't substitute for real hover code! What I mean by this is you have to hover by only applying force and without knowing your mass. Name any game except maybe UT2004's repulsors and I doubt they have done it hack free. Have a look at the hover vehicle in the halflife2 vids for an example of unrealistic hover code.

2. New player movement/animation code.

In our singleplayer map, we have a saloon. Our modeller likes the karma stuff and experimented with some karma swinging saloon doors. One problem was that the unreal pawn physics cannot push the door to walk through it. To solve this problem, I spawned a bulldog tire, set pawn PHYS_None and SetLocation(BulldogTire.Location) and then you have new pawn physics. Next was the control code to make sure it moves like a pawn, and then the more confusing part for me was to find out which direction you are moving relative to your rotation and then play the appropriate animation. Prolly the trickiest animation was the jump because you needa make sure that you can only jump once while in air. One of the annoying things about doing all that work was that ... perhaps a month after I'd done it, Steven Polge surprisingly released the native animation/movement code on the epic mailing list which was like 10x more efficiently-coded than mine ... and therefore, probably runs 200x faster . Even though I was glad to see the simplicity of their code, I still kept mine because I can't bring myself to delete it somehow lol ....

3. Realistic physics for player interaction to objects such as doors and pickups.

Made it so u can carry objects around with certain tags. The l33t3st thing about the singleplayer aspect of the mod for me is the doors. Gone are the days of magically moving, robotic doors, my friend. Say hello to Karma doors. What you do is bump into a door and it moves ... wow! When looking at a door you can either "push" [LMB] or pull [RMB] ... wow! When the door angle is within its lock angle either "push" or "pull" will change to "lock door" ... wow! When a looking at a locked door, it checks your inventory for the key required to unlock the door. If you have the key, a mouse button will say "unlock door". If not, "you need a key". Pretty good?

4. New weapon projectile system.

I know its not much but I re-did the weapon fire design to make all shots projectile shots and redid most of the weapon fire classes. The projectile system works similar to the rail gun in Q3. Whatever your cursor is on, you will hit, if it is a one trace shot. If a slow moving projectile thats not instant hit, the projectile will hit things along the way from the tip of the gun. However, the rail can theoretically go through things along the path from the gun tip to the cursor's destination. So, what I have basically done, is the shot goes from the 'camera', finds the hit location, and then the projectile goes from gun tip to that hit location. That way you always hit what the 'camera' is looking at, unlike other games such as Troopers where what you hit is what the 'gun' is looking at, not what the camera is looking at. I have found UT2003 is very strange because their weapons vary wildly ... some will use the camera, some will use the camera with the projectile coming from the camera, some will use the gun aim, and some just seem to have aim positions based on other things.

5. New inventory system.

Our game required 2 slots for guns and 8 slots for pickup items. I didn't spend much time trying to use the UT2003 system because it seemed like it was going to be complicated to use. I just made two arrays of class pickups [2] and [8] in Pawn which makes things quicker/easier to access. When the pickup detects a Pawn touching itself, it attemps to get the Pawn to add itself to the appropriate array. If so, it disables collision detection and the Pawn attaches the mesh to one of his bones. Btw, our player model is visible so you can look down and see your feet etc. This seems to give a more realistic view and helps make weapon creation easier because you dont have to make a separate FP mesh placed in the right position. Making the player mesh visible requires the modeller to place a bone for the camera to set its location to. The modeller also creates an animation going between looking up and looking down so that the 10 UU wide camera doesn't clip the player model.

6. 3D Hud.

My hardcore modeller friend, Gareth, (who left the team June/July to do other stuff) is a real frames/detail nut. I told him how slow drawing to the canvas is (the default ut2003 hud can take you from 280 to 210 fps), we decided to go full 3d hud. This guy loves UT2003 static meshes and antiportals and went full on hardcore and converted our 2d hud pic into 3d with a massive 500 or so polys staticmesh. We dont use drawactor either because that has a slight decrease in fps. Just have to make sure that other players dont see a flying hud by making it not replicated.

Desperado2185 Multiplayer

This is what I've been working on since August. I'm not sure if I should say my ideas here since I'm not sure they're going to work :S.

Comments

O-GL: Btw, if anyone wants source code ... tell me the most important things you want and I'll make a tut page for it instead of wasting my time playing starcraft .

Foxpaw: 280 fps! Eek, my computer only runs UT2003 at about 20 fps. One issue that I could foresee with having a 3D HUD like that is - how do you update the values on it? If you use a scripted texture to do it, you forego all compatibility with Max, Linux, and PC boxes not running Direct3D.

O-GL: Thats 280 fps looking at corner wall in a simple map, Deathmatch, all details lowest, and no weapon visible. Updating values was first done with placing a very small 3d version of an item in the appropriate position ... but that was canned due to many annoying problems. We ended up placing thumbnail pics on the Canvas in the appropriate place instead.

EricBlade: I would be very interested in talking with you a bit more about having the player model in view in SP.. thats something i was just toying around with yesterday, and obviously you've figured out a way to defeat the obvious problems that crop when just turning the option on