Single player Total conversion

[Mr N]

Hi all I am new to Modding so please bear with me. I am posting to ask anybody on this forum with experience (or not) if they know or if they have tried making a single player mod using the Unreal 3 engine (specifically UT3 UED)? The reason I ask this is because I am intending to make a single player set of levels (id say about 3 or 4) with a single player narrative. I have a little experience with UED2 but not UED3 and with the new kismet system was wondering how easy it would be to do? For a university project (5 years ago now) I constructed a set of levels for a single player narrative and would very much like to realise this in UED3 but without the time constraints of uni project deadlines. My goal is to flesh out the story and level environments + implement the gameplay mechanics as I intended them to be.



I am also considering the Cryengine from the game (Crysis) for this as well and am debating still which one to use. At the moment I have more experience with UED but find the Cryengine editor appealing for some of its more unique features (voxels etc).

You can see my game progressions on my site www.seantucker.co.uk screen shots of my last levels and my progressions this time around. The main thing I think is to get making and see how test ideas turn out in each engine and then make a decisions but thought id get people opinions here first!

Many thanks for your help and look forward to reading
Mr N

[ambershee]

You should find it just as feasible as before, however with the added amount of time it would require to produce art assets up to current graphics engine standards. UT3 is actually quite well set up for single player games, even if it doesn't do much itself.

One of the projects my team has on the back-burner, after creating an open-source Total Conversion framework is a Single Player framework, including pertinent AI and a few specialist triggers and such - but it's literally on the back burner. We'll be wanting to put together a show case example of what the framework can do, so perhaps you'd be interested in helping us get it started - after all you only know what you need to include in a singleplayer game when you come to actually make one.

[BigJim]

I spent ages producing SP maps for the previous engine, using the Old Skool Monsta Tools mod (links in sig), and once you've got a certain amount of the basics, it's brilliant - great fun.

Superape had a fair bit of work to do though, getting it to work under UT2k4, mainly stuff with the monster AI coding.
At it's most basic, you would need a new gametype subclassed from UTGame (forgive me if some of the class names have changed in UT3, but you'll get me).

Then you'll need an array of Events, which will correspond to objectives that the player will trigger-off (ie; Get to the end, hit a Trigger actor, trigger the objective which "wins" the game).

If you recall how Assault worked, it had a specific ObjectiveManager actor that the mapper placed, and you could expand it's Objectives array with the names of Events that the player had to trigger, and sometimes in a particular order, etc..

OSMT used a similar setup, and by clever use of Tags/Events, you could do some very interesting objectives, in my case I had specific monsters you had to assassinate, powering up engines, breaking into locations, all the kinds of interesting things you want, but all tied to a relatively simple Trigger system.

You can use Triggered movers to block off areas until the previous objective is complete, or simply use the previous objective as a hook to spawn the next objective, your imagination literally is the only limit, to use a cliché.

When it comes to Kismet, you can do a lot with it, but bear in mind that it might be more effective to produce small custom actors, I know that I produced a ton of small actors specifically for my own campaigns that did specific stuff, and while I'm sure you could reproduce my of those same effects with Kismet, it won't hurt to know a bit of UScript.


Now, the tricky bit I'm sure will be your monsters/baddies.
I was lucky because SuperApe did the real hard work in coding the "base" monster AI, and produced a set of monsters for us mappers to use.
Remember the Invasion monsters, which were basically ports from the Unreal monsters?
He created custom AI, using those models & meshes as the art assets, so right from the beginning we had monsters to work with, and the way he designed them, you could use custom models & meshes with a minimum of tweaking - I was using a load of custom monsters with only the minimum of coding by myself to get them in game & working how I wanted (to be honest, I could not have hoped to do the AI by myself).

Imo, that'll be your hardest task, no matter what game engine you use.
You *could* use basic pawns placed in your map, but the problem there is they will behave like Bots, which are very different from the kinds of monsters we are used to in SP shooters - things like ambushes, patrols, etc.. will be tricky to set up without custom AI.


If you're interested in doing it then it might be a good idea to drop by Unreal Playground (again, link in sig) for some pointers if you want to tackle your own AI, but I'm sure it won't be easy. Hope some of this helps.

[Mr N]

Hi guys

Thanks for your replies to this. I'll answer in order or post.

ambershee: I understand completely, there are things I will only be able to get my head around when I am deep in creating / making the game etc. I would like to understand some more of what your team and you are doing and how you think id fit into it. It defiantly sounds exciting!

BigJim: Alot of information to take in here. My scripting knowledge (in any language) is very limited. My hope was (in vain) was to try and use the kismet system to create alot of what you have explained to me in your reply. Perhaps using the UT3 version of the engine wouldn't be in my best interest unless I could perhaps get some help or 'a team' together to help move some of the more technical aspects of the idea along. I am still in the planning phase of things at the moment But I do know one of the mechanics I want to employ (more explained on my site www.seantucker.co.uk) is to remove the use of weapons ala ‘Penumbra: Overture’ and ‘Penumbra: Black Plague’ ( I really respect what these guys are doing) I want to in fact strip away the HUD and other elements of FPS ‘convention’ a lot more thought my end is going to have to be used to work my idea around the limits of what I know. Im sure that certain aspects of what I want to do will eventually have to come down to adding some functionality to change the multiplayer tools to single player ones.

That is also part of the reason I was considering the Cryengine because this mechanic is already set up ( I would just have to remove the functionality of the ‘suit’ etc using their visual editor) its only certain aspects of the engine that are putting me off (lack of BSP etc).

You have defiantly given me a lot of food for thought, so thank you for your post. I will post more developments on my site (www.seantucker.co.uk) and this forum as they happen and / or if the Unreal engine is the one I go for, as I will defiantly need a lot of help ;-)

Thank you kindly for you thoughts guys

Mr N

[BigJim]

BigJim: Alot of information to take in here. My scripting knowledge (in any language) is very limited. My hope was (in vain) was to try and use the kismet system to create alot of what you have explained to me in your reply.

Ah, well please don't be disheartened, all that stuff *is* possible with Kismet, I was just trying to refer back to the old way of doing things in case you were more familiar with it.

I suppose a good way of describing it would be to say that Kismet is just a visual representation of all the advanced trigger system gubbins, plus a bunch of other stuff that in prior engines you could *only* do via custom actors.

Kismet itself would not be a limitation.

I want to in fact strip away the HUD and other elements of FPS ‘convention’ a lot more thought my end is going to have to be used to work my idea around the limits of what I know. Im sure that certain aspects of what I want to do will eventually have to come down to adding some functionality to change the multiplayer tools to single player ones.

That is also part of the reason I was considering the Cryengine because this mechanic is already set up ( I would just have to remove the functionality of the ‘suit’ etc using their visual editor) its only certain aspects of the engine that are putting me off (lack of BSP etc).

I get you.
Removing the HUD or radically changing it again would be no problem.
The controller class is what defines the HUD you see among other jobs, basically the Controller receives your input, and knows where you're looking, based on your mouse movement, and then it passes this info on to your Pawn class.

Every TC mod will probably want it's own player-controller class anyway (monsters and bots also have their own controller classes), so you would not really be creating extra work by using a custom controller, and that's where you would either define a custom HUD or just remove it.

n prior versions, whether you could double-jump, or how hight your eye-height was, etc.. were defined by properties of the player controller class, and folks who wanted extra behaviour like leaning, or sprinting, etc... for their players used the player controller to define this behaviour too - I used a custom controller for some basic player tweaks in Use of Weaps 2 so it's not that hard a task (really, I'm very noob with UScript too).


I honestly can't give you any info on the Cryengine, because I've never used it, or even played Cysis tbh, but I can say that nothing you've described so far is that difficult with UE.

Ps: Best of luck to you, whichever way you decide to go.

[Mr N]

Hi BigJim: Many thanks for your input into this. I doesn't seem daunting when you disect it and take each part in chunks. Im basically doing a remake of the maps I did before (by a long way) visually and functionally and putting into the project the knowledge of doing things I have now. I still need to think through the mechanics of what I would realistically want the player to do within the scheme of the story / level but also keep in mind what is possible by myself. There is a long way to go and I do reatly appreciate you taking the time to answer my questions, much appreciated.

one question though would be if I wanted to create say (oh cliche of cliche) a battery powerd torch (ala halfl ife 2) I would need to create a class for that?

many thanks

Mr N

[ambershee]

BigJim is pretty much bang on. Personally, I'm of the opinion that Kismet is a little clunky, and that you'll largely be wanting to program things in using UScript.

AI is definitely the largest and hardest part of what you'll be wanting to do.

A battery powered torch would be programmed using UScript and use a lot of custom materials, a Kismet implementation would be very difficult and hacky.

To answer your previous question, our mod team is primarily working on a multiplayer racing game, but we're also working on a couple of side projects. The first is a total conversion framework. We need to do this for ourselves anyway, so we're building an open source base package that can be adopted and used by anyone else that wants to do the same and work from the base up with blank pawns / controllers / game rules etc.

On top of that, we have the Cover System framework, a framework that concentrates on introducing a cover based system for single and multiplayer games, as well as destructible objects, semi-realistic weapons, bullet-penetration and a proper fire system. We'll be using that to generate a small 'almost TC' multiplayer game as a showcase.

On top of that we're working on a Single Player framework, although the name is a bit of a misnomer, since it is intended to also allow for the components to be used in multiplayer environments (e.g Coop). We aren't intending to put together a show case for that, as we feel it would detract far too much time from our main project. Because we're not building a show case, we don't really know what we would be needing in such a framework.

[Warhead]

I would think a UT3 SP game would be totally doable. Im in the process of creating one right now. Like ambershee and BigJim said, it will more than likely require some coding, but that doesnt mean you cant build the levels before then.

As for the CryEngine, that does not have the SDK released yet although it is not too far away. What sort of levels do you plan to do? UT3 can be easier to do indoor and outdoor levels with the use of BSP and static meshes to add detail. CryEngine can do pretty much the same thing. The only difference is that indoor levels have to be modeled in a 3d app and then imported in to get an indoor level.

Really, they both are good engines. You might want to keep in mind the system requirements. Crysis does need a pretty beefy computer to run, while UT3 does a great job on most midrange PCs. Crysis is certainly more detailed, but it takes a framerate hit (for me anyway) when you walk around some of those really detailed environments.

Personally, I would lean towards the Unreal Engine. Its editor is easy to use, easy to make BSP for levels, static meshes dont have to have loads of details, terrain can look very nice, runs great on my computer.

[BigJim]

one question though would be if I wanted to create say (oh cliche of cliche) a battery powerd torch (ala halfl ife 2) I would need to create a class for that?

I think you could do this quite easily tbh.
All a torch needs to be is a custom weapon that doesn't actually have any fire-modes (no primary or sec fire classes in it's array) but with a dynamic projector (a projector that can move) hard-attached to the weapon model, since it's just something you hold in your hand, and points the way you look.

In fact, since dynamic lights are now so much cooler in UE3, a dynamic spotlight (portable spotlight I think they're called now) would be better, and you could do cool things with it, like a simple timer function within the weapon's code that as it counts down, slowly reduces the Brightness of the spotlight to represent the battery dying, or a function to change the colour of the light, for I dunno, levels with funny coloured lighting, or some other cool thing you can imagine.

You could also do a Quake4, and subclass the *normal* weapons to include an under-slung torch, just using the same method, the base weapon with a small portable spotlight hard attached to it, facing the direction of the weapon.
You *might* need to add a line or two of code that checks what direction the Player Controller is facing (which is your way of finding out what the player is looking at) and re-orientating the light to match, but that's easy).


But yeah, imo a custom weapon subclass would be the way to go, as long as you *promise* not to do a Doom3...
In fact, iirc the most recent version of OSMT also featured a torch, I bet you could check out the code for that & use the same method for UT3..

[Mr N]

Big Jim: Once again thanks for your insights and I have registered to unreal playground with gain some more knowledge of the U3 engine.

Here are some more images of my previous level I had done in U2

[ambershee]

But yeah, imo a custom weapon subclass would be the way to go, as long as you *promise* not to do a Doom3...
In fact, iirc the most recent version of OSMT also featured a torch, I bet you could check out the code for that & use the same method for UT3..

Doom 3's torch was an excellent game mechanic that helped improve the atmosphere and tension a great deal. I'll never understand why people badmouth it so; it's a perfect psychological clincher - do you feel safer being able to see your enemies, or safer being able to fight them? Had they allowed you to carry the torch and weapon at the same time, it just wouldn't have had such a potent effect. Perhaps the fact that people didn't like having to put a weapon away is really more of a demonstration of the psychological success of that component of the game.

OSMTs Torch would be a more limited approach due to the differing nature of UE2 versus UE3s lighting. I'd probably go with a dynamic spotlight.

[BigJim]

Doom 3's torch was an excellent game mechanic that helped improve the atmosphere and tension a great deal. I'll never understand why people badmouth it so; it's a perfect psychological clincher - do you feel safer being able to see your enemies, or safer being able to fight them? Had they allowed you to carry the torch and weapon at the same time, it just wouldn't have had such a potent effect. Perhaps the fact that people didn't like having to put a weapon away is really more of a demonstration of the psychological success of that component of the game.

I agree with much of what you say - I only recently played through Doom3 (about a fortnight ago) & while I think it did it's job perfectly in the psych stakes, the problem was that the *entire* game demanded you use the torch all the time..

If they had just used darkness a little more sparingly I'd be a massive fan of the mechanic - I certainly agree that it scared the cr** outta me when it was meant to, but in the end, you just ended up with the torch constantly out all the time, & running backwards as soon as you hear any noise swapping to a weapon - anything that means you use the exact same tactics all the time is a bit of a mistake imo, but overall I still think it's a good game.

In the end I just used the duct-tape mod - it gave you a much smaller spotlight attached to your shotgun & SMG only - small enough so you still regularly got jumped by monsters & it still felt very claustrophobic, but enough so that you could actually see where you were going - a perfect mix imo, and one that I appreciated in Quake 4.


Ps: Agreed about the lighting in UE2 - the problem in UE2 is that everything "illuminated" comes out in total monochrome if you use a projector, but a dynamic spotlight on-screen all the time is a real FPS drain.

I'm currently playing though Bioshock, and I love how the security turrets use coloured spotlights to great effect (plus the illuminated faceplates on the Big Daddies), so I know it'll work really well using portable spotlights in UE3.


Ps2: Nice screenies Mr N!

[Mr N]

Thanks for the comments on the screen shots BIG JIM they are from the old maps I had done using UE2 and were very rushed. Here is a sketch of some possible outside envirnoments for the Dam section of the levels.

[Mr N]

bump

Any comments or crits welcome at this stage, not that there is much to crit on. I think the next stage will be to plan out the initial stages of the maps and then get cracking with some engine tests and start making custom meshes in 3dsmax etc. I just love the BSP of Unreal engine though. Cryengine leaves alot to be desired in this way.

thanks for all the comments I will post more when I have content to show.

[BigJim]

Little I can actually say mate - the concept drawing is very good, and for sure it'll look great if you can build that in-engine.

You could certainly "rough" that out relatively quickly in the UT3 Ed so you've got something to work with - using the terrain editor and blocks of BSP for the buildings, leaving you with a decent mockup for you to fit in your detailed meshes as you build them, and again, there's nothing there that you couldn't do with relative ease with UT3.

Personally, I'd look at that pic, and assume that the big angled building with the 2 huge pipes coming out of it wants to be about 1024 UUs high & 4096 wide (maybe?) so you can get a rough idea of your overall scale from there - remember that if you place your terrain actor down, and start editing it into those hills & valleys, you *can* resize it later by adding or removing new sectors along the edges.

Just bear in mind that the edges *furthest* from the actual terrain icon will have extra sections of pristine, un-touched terrain squares added to them or removed, if you re-size them.

(This info might not mean much to you now, but, once you begin editing your terrain you'll see what I mean, basically I mean that as long as you use some common sense, you can afford to re-size your terrain as you work on it - this will help if all of a sudden you decide the valley needs to be 2x wider, for example.


As to the layout itself, can't fault ya, but then again it all depends on how you implement it.

That's a lot of landscape to build if all you're going to do as the player is walk across it on their way to do something else - personally I'd have the player running about inside the dam and those buildings & pipes, as well as some way of letting them see it all (like a cutscene intro or something - that pic is so nice, I would like to see the player get a similar, birds-eye-view of the location, simply because if the player spends all their time at ground level, all they'll see is their immediate surroundings & that's a waste of good landscaping.