Modding Questions

[WildcatPhoenix]

Some of you may remember the Man in Black mod I've been running on-and-off now for several years. I won't take up space here with the sad and sordid tales of our production history. Let's just say it's been...unsuccessful.

The problems I'm facing are as follows:

-I worship Deus Ex as my all-time favorite game. No other game since then has been able to give me the same satisfaction, the same level of immersion, the same "wow" jaw-on-the-floor experience that I first felt in 2000. I feel like a junkie trying to recapture that first great high. And nothing else quite measures up. That feeling is what drew me in to Deus Ex modding in the first place, the idea that there is more story, more gameplay, more excellence to be created and experienced in the Deus Ex universe.

-I am 27 years old, working a full time job, getting married in January, and looking at going to graduate school in the fall. Obviously, between work, relationship, and school, I don't have a ton of free time available to learn the ropes of the SDK and editing software. Being aware of these limitations, I immediately sought out to build a team of talented mappers, coders, skinners, musicians, animators, etc to make our mod ideas a reality. On several occasions I was able to put together some great people who did some really impressive work, but mod teams have always been fragile entities at best. Because no one is getting paid, an administrator really has very little leverage over his/her team members. And because the pool of skilled modders for the Unreal Engine shrinks every day, that leverage gets weaker and weaker because team members are much harder to replace if they don't meet deadlines, are insolent, confrontational, etc.


Long story short, I am absolutely bound and determined to get this mod released in some form or fashion. I have over 400+ pages of dialogue, script, and text sitting in a massive file on my computer, and there is a lot more to be written. I can't just abandon it, not after almost 6 years. So I have some questions:

1. Given my free time limitations, what is a reasonable amount of time it would take to become skilled with level editing in the SDK? I've fooled around for years and created some extremely basic maps, but nothing near what we're looking to produce. I've tooled down our expectations for the mod quite a bit, so I'll most likely be working with basic DX textures and skins. But learning the level scaling, lighting, movers, etc is bound to take a couple of years, isn't it?

2. Are there any community resources out there that I'm unaware of? I've memorized Steve Tack's tutorials at Universal Constructor and also read Wolf's Unreal Tutorials, but I'm mainly interested in finding a chart of basic scaling. In other words, what are good dimensions for different types of buildings, rooms, doorframes, tables, etc? But any info I can get would be greatly appreciated.

3. If this mod takes another couple of years to release, is there still going to be an audience to play it?

[DDL]

Hrmm..well, that comes across as far more depressing than it needs to, really. Positive mental attitude, maaan!

Alright, as a counterpoint, I shall attempt to describe my current state of fail, in the hope that..uh..the fact I'm still "optimistic and raring to mod" will inspire you. Just to be clear, I am in no way trying to go "LOL U TINK U HAS TEH PROBLEMZ0RZ! HAH LEMMEEE TELL YA....", because that wouldn't be true, and would also be a really dumb thing to do...but you know, I'm not always the most eloquent of speakers, so it's best to pre-establish that just in case. Plus I swear a lot. A whole lot. Well, a fuckton, really.

Anyway. I first played DX probably back in maybe..2004, shortly after finishing my PhD (yeah, I like to game waaay behind the curve, coz: GOTY editions for like a fiver, dude!). I loved it. Still do. After playing through twice (and starting a postdoc), I got interested in the PDX forums, and from there I got the idea to try modding (hilariously, because it looked like the editor was -don't laugh- fairly straightforward), and became a regular lurker of DXE too. My initial plan was literally like a three map single mission style affair: drop the player in, have em fight/sneak/bribe their way from X to Y, conclude with Z, done.
As I began mapping (horribly), and experimenting with implementing ideas I had, I became increasingly frustrated with what I could and couldn't do (though I did become quite insanely adept at chaining triggers together in truly mindfucking combinations: I've looked back at them recently and I have no fucking idea how I managed it...specially since now I could simply code up one trigger that does the same thing..but anyway)...so I started asking questions on DXE. A lot of questions. Christ, were some of them stupid. "Is a bool the same as a boolean?" -_-

(luckily for me the DXE forums got gibbed, I guess?)

Anyway, people were patient and lovely and with steady coaching from many, the sheep and smoke39 in particular, I began to play with missionscripting (and BOY can I play with missionscripting), and from there onto DX coding 'proper'. Or at least, proper by 'someone with no formal computer training experience' standards -I'm a biochemist, after all. I also got modelling advice from phasmatis, mapping advice from zeropresence, and game design + regular abuse from Jonas. It was a lovely place. I even ended up buying at least two years of DXE hosting, in the end, coz I never wanted it to end.

Somewhere along the way the three-level single mission became a story, and the story needed a plot, and the plot involved more maps, and the maps got bigger and stupider and more and more scripted. I think I was about done with my first postdoc by this point. Onto postdoc number two, which for reasons of brevity I shall simply summarise as 'a clusterfuck'. Still, before that became 80 hour weeks and overnight lab stays, I managed to find time to further code stuff, map stuff, write some conversations..hell, writing convos is a blast, even if ConEdit is basically the lovechild of matlab and scattergories. Also I think I got involved in TNM sometime around then. That took up a reasonable amount of time, even if my major contributions were playtesting and failcode.

At this point I realised I had 'chapter one' of a four chapter story, and that'd taken me like..5 years. And the maps were shit. No really, SHIT. Like "I'll just put a giant stone lion over this BSP killzone coz I can't fix it"-style shit.

So I've started reworking the maps to be ...less horrible, given I'm marginally better at mapping now, and I recoded everything I'd written (improved weapon behaviour, bullet penetration, new ammos, new weapons, improved augs, a fully working suite of NPC augs for mechs and nanoaugs etc) to work in vanilla DX. I also did this in a really really retarded fashion: none of this 'I'll just tweak deusex.u' stuff for me, oh no. My code now searches through every fucking actor on a map, finds anything i've recoded, spawns my new version, copies properties across, then deletes the original (incredibly, this works).

And recently, I've actually gotten around to PLAYING vanilla DX again, using all the changes I've coded. And I'll be honest, it's been fucking great. Seeing stuff that I'd even forgotten I added "hah! I shall sneak up on this turret by hiding behind this flimsy cardboard box! Wait, is that a bullet hole that just appeared on my side of the box? Wait, where are my legs? CURSE YOU, TURRET!" *dies*

I would say that personally I don't regret the 8+ years I've spent learning how to do all this shit.

A) It was fun just learning how to do shit. I am now..well, reasonable at general programming (mostly biochemical modelling simulations, admittedly), based entirely on shit I learned from DX coding.

B) I'm having so much fun playing, I already feel the time was justified.

So how does this all relate to you? Well. Firstly, don't become reliant on other people. Accept help when it's offered, but never become dependent upon it. You sound like you've learned how to do a fuckton of stuff already, so just carry on learning. Will you work slower on your own? Hell yes. But you also spend less time online arguing with team members who just DON'T. FUCKING. UNDERSTAND., so it's not as bad as you might think. You also don't have to share your creative vision with anyone elses. Small point, maybe, but if you're trying to make a serious mod and your lead coder insists that you have to have flying karkians, and refuses to code anything until you approve it, then you have problems. As in, problems above and beyond fucking flying karkians. So, bad problems, basically.

Next: don't be overly ambitious. Or, if you are overly ambitious (and who isn't?), be realistic about it. Plan for a short mod that will probably see the light of day, or a lengthy mod that probably won't. Don't be afraid to admit that to yourself, either. Make sure that everything you have planned is doable by you working by yourself, even if it results in a less effective result. "We must have a new pistol model" becomes "A new pistol model would be nice, but fuck it: worst case scenario we settle for a reskin of the glock" and so on. Specially since modelling for DX is fucking 'orrible.

As for time: take what you can get. An hour here, an hour there: it all adds up. Provided you can keep it in your head, there's no reason why a map can't be built in hundreds of one hour installments. It all adds up. Coding? Get WOTgreal: not only does it do syntax highlighting and function assists, it remembers what you were working on when you restart it. Perfect for jumping in and out.

And finally, since it's almost pub o'clock and I've written enough already: don't worry about scaling too much. DX happily uses doors ranging from 96 uunits up to 160, and from 32 to 64 wide. If you're worried, just make a map, stick a pawn in it and use that for scale. Or..uh..steal brushes shamelessly from DX. Use prefab packs. I have a ton of .t3d packs I could probably send you, if you haven't already got them. Scaling is really, really not an issue.

Lighting, movers etc you can learn as you go. Lighting really isn't that complicated anyway unless you want it to look fantastic: looking 'ok' is a piece of piss, and you can refine it later if necessary. Or leave it looking shit (my favoured approach). Movers are largely self-explanatory, but again, start simple, get more complex as you go.

Plus: play. Don't know what a setting does? Fuck with it, see what happens! (a lot don't actually do anything, anyway)

And lastly, ask questions HERE. There is no DXE any more, but the legacy lives on. I may not be online a LOT, but I am not going anywhere anytime soon.
Plus I've kinda got a mod on the go, too.

Never give up, and remember, there will always be people willing to play. Shit, it's like 12 years post-dx and new players still turn up.

[WildcatPhoenix]

Hahahaha!

Let me start off by saying "thanks, Doc!" for the most entertaining post I've read in a long time...

So how does this all relate to you? Well. Firstly, don't become reliant on other people. Accept help when it's offered, but never become dependent upon it. You sound like you've learned how to do a fuckton of stuff already, so just carry on learning. Will you work slower on your own? Hell yes. But you also spend less time online arguing with team members who just DON'T. FUCKING. UNDERSTAND., so it's not as bad as you might think. You also don't have to share your creative vision with anyone elses. Small point, maybe, but if you're trying to make a serious mod and your lead coder insists that you have to have flying karkians, and refuses to code anything until you approve it, then you have problems. As in, problems above and beyond fucking flying karkians. So, bad problems, basically.

Amen to that. After 6 years and two severely embarrassing mod team failures, I've adopted the good ole' "If you want something done right, do it yourself" philosophy. I know in my head what I want the maps to look like. I know the tone, the atmosphere, the little details that have to be done correctly. And yep, I'm quite exhausted with explaining why our mod doesn't need zombies in it, or a laser rifle, or...as you said, a karkian launcher.

Next: don't be overly ambitious. Or, if you are overly ambitious (and who isn't?), be realistic about it. Plan for a short mod that will probably see the light of day, or a lengthy mod that probably won't. Don't be afraid to admit that to yourself, either. Make sure that everything you have planned is doable by you working by yourself, even if it results in a less effective result. "We must have a new pistol model" becomes "A new pistol model would be nice, but fuck it: worst case scenario we settle for a reskin of the glock" and so on. Specially since modelling for DX is fucking 'orrible.

This was a tough lesson to learn, but I do agree that it's better to release a less ambitious project than to set ridiculous, unreasonable goals which will never see the light of day. Our original design docs called for new skins, new weapons, new menus, new augs, all sorts of insane ridiculous shit that would have been awesome but never, ever, ever would've actually been implemented. There were going to be at least 20 missions (more than likely twice the length of the original game, lol).

Obviously, I am planning on scaling that back quite a bit.

And lastly, ask questions HERE. There is no DXE any more, but the legacy lives on. I may not be online a LOT, but I am not going anywhere anytime soon.
Plus I've kinda got a mod on the go, too.

Never give up, and remember, there will always be people willing to play. Shit, it's like 12 years post-dx and new players still turn up.

Alrighty then. I'll stick to it. Here's hoping both our mods make it through to Release Day!

[Jonas]

Not much to add that DDL didn't already say, but I will add that... well I'm not very good at mapping, but I'm a lot better than when I started working on DX (before TNM). It's okay to learn by doing, you'll just end up going back over your old work and making it better, that's what I did with mapping as well as conversation writing. Most of what I learned came from working on other people's maps, which may or may not be something you can do? I always find it infinitely easier to expand on and finish something someone else has made than it is to make something from scratch.

When you have to make stuff from scratch, it helps to find pictures and try to recreate it (typically in a simplified shape) in the editor. I've been adding some apartments to the first map in TNM lately, and... there's only so many ways to make a table before you run out of ideas - then you google "dinner table" or something and pick one that looks like it won't need too fancy shapes to make. If all else fails you load up a DX map or a TNM map in the editor and copy/paste some furniture or whatever you need, nobody's going to call you out on that, we stole loads of shit from DX for TNM, it's not theft it's a prefab!

While I'm at it, here's a couple of simple rules for making good lighting in DX, some of it I figured out on my own and a few things I picked up from ZeroPresence: first off, if there's light, there should be a light source - DX has a decent selection of textures for light fixtures - add a light source to the room to begin with. Second, you add a very bright light source with a fairly small radius near the light - just a pointlight. Give it a little colour, doesn't have to be a lot but fully white light looks dull as hell, so unless you're going for dull, I suggest making it a little yellow or a little blue, pick a colour that matches your texture. Finally, remember that Unreal 1.5 doesn't do light bounce, it does direct light only - you can simulate light bounce by having a really dim light with a larger radius somewhere in the middle of the room - give this a more pronounced colour than the bright one, and pick one that fits the colour of the walls - a white light bouncing off red walls will produce red light.

Oh and on the topic of BSP errors, there are articles on the Internet about how to fix or avoid BSP errors in the old engine, but a general rule of thumb: if a brush doesn't intersect with any other brush, make it semisolid - you can't subtract from semisolids and semisolids may never intersect, but using semisolids wherever possible simplifies the BSP tree a lot by avoiding unnecessary cuts, which also reduces the risk of BSP errors.

And when in doubt - load up one of ZeroPresence's maps and steal his tricks. Steal all of his tricks. He won't mind

[Neveos]

If you use Veronika's Ued2 hack, you will have a really easy time learning how to build maps. Building maps are the easy thing, I think. The hardest thing is the scripting, which for me consists of not using the mission script, but using DDL's extra triggers to pull off the desired effect. I had zero experience, and I think I built my first map, in like, a couple months, which I showed in this video: http://www.youtube.com/watch?v=2YWBTcP2 ... ideo_title

I'll admit I was lucky enough to had watched a bunch of tutorial videos before hand for the new UDK editor that my friend gave me, and the mechanics were still the same.

Basically, when starting, keep the grid at 16 units:

16 grid units is like a Ued "foot" in the english system.

3 Ued feet (3 grid spaces on the 16 grid setting) is like a guard rail that you can jump over.

4 spaces is like a counter that you can't.

1 space is acceptable for wall thickness, but it is pretty large for shacks etc.

A door is 4 wide, 8 high. A double door is 8 wide 8 high.

10 spaces high is a low cieling. 16 spaces high (standard cube size) is like a lobby.

Hallways need to be like 6 or more wide.

Vents are like, 3 x 3

Glass needs to be at least 4 units, or under, thick.

Use scaling. I wrote a bunch of tips for that here: http://wiki.beyondunreal.com/Legacy:Brush_Scaling

Find the pros and cons thread on using Ued2 so you can understand the bonuses and limitations there. And ask me if you need any tips, because I'm getting pretty quick at this stuff, but I heard ZeroPresence is the guy to go to for mapping. Jonas is the ConEdit guy, and DDL is the coder god.

[Jonas]

The only general advice I have for ConEdit is this: write your stuff directly in the editor. If you're writing in a word document, I think you end up making it more linear, like a movie script. Writing it in ConEdit is a much better environment for the type of conversations that Deus Ex is about - if you've ever used another conversation editor you'll know to just what an extent ConEdit is designed for precisely the type of conversations DX uses, which is to say dialogue that has fairly long linear exchanges but does branch every time it matters. Compare and contrast to Neverwinter Nights' dialogue editor where every single dialogue node for the player is a branch point. What I'm saying is use ConEdit for your drafts as well as your final dialogue, use it for your writing from start to finish.

If nothing else, it saves you doing everything twice - copy/pasting stuff from Word to ConEdit is a huge waste of time.

Oh, and set up some test maps early on, so you can actually test your conversations in-game. Your logic will fuck up. It will fuck up all the time. You will call the wrong flags, forget to hook jumps up correctly, use the wrong bindnames - even after 10 fucking years of using ConEdit I still make stupid mistakes like that, it's inevitable when the dialogue, the code, and the levels all have to reference each other without any sort of common place to store information, it's an awful system to be honest

[terthos]

@DDL: You almost have me wanting to make improvements to Mutations. Only almost, though! I hope one day to gaze upon the mod I have heard so much about. It should be fun.

@WildcatPhoenix: Good luck with your endeavors! It can be done.

[ggrotz]

Great post indeed here. Some of my thoughts added below as a primary general coder (professionally in some ways, not in others, relating more the "not in others" part):

So how does this all relate to you? Well. Firstly, don't become reliant on other people. Accept help when it's offered, but never become dependent upon it.

This is exactly true. People don't tend to go for anything in terms of effort unless they are personally interested or if they are getting paid for it. As for personal interest, theirs generally have to match up with yours. Remember though, if it is something that enough people see as viable or interesting, AND it's too big for you to do, you'll need help, as it is there's only so much that you can do by yourself. Sometimes you can farm it out on something like SourceForge or Google Code, but again there is always a question of vision. I've found even just getting a person to test something and give some quick thoughts (something that would take maybe 5-10 minutes) can be difficult - and this can be useful for UI concerns.

A lot of times if it's not too complex (that won't be a problem here I've seen), you can ask questions and get good answers on how to do things. Remember any project you undertake will always have a learning curve of some kind to it, and you'll learn much in doing it.

Next: don't be overly ambitious. Or, if you are overly ambitious (and who isn't?), be realistic about it.

I've written several posts in the past (here and in PDX) on the issue of project management and computer/IT projects. There are books to study the dos and don'ts of it, and many of them apply even to something like modding DX. Make sure what you want to do is clear and set before you take off and code, and can have some idea of how much time you are willing to take to see a finished product. Some people are okay with seeing the same thing for months on end and others are not. Some people are more hopeful in terms of working months without seeing a finished or progressing product. Some have different motivations that are required compared to others to work on something. It's easy to underestimate the amount of time something will take, too. Both books and experience say that.

The important thing to remember is to be realistic about what you can do as one person given all the other stuff in your life and how much time you're willing to spend behind a computer on a project, as well as knowing what your temperament is and basically knowing yourself. When I did the schooling thing, I found many in the program that just didn't have the right kind of mind and temperament to code, and were better off just installing OSes or something like that. There's others that can handle graphic design better, or the like. For example, I know I'm bad with graphics and have proven that to myself several times. I'm passable when it comes to things like icons, but probably would need help if I were doing a DX mod in that area simply because I'm not that good. What I do want to do when I finish up what I'm working on now is mainly some new items that will require (hopefully) no more than 200-300 lines and can be figured out hopefully from the other functions - key will be to figure out how DX works to do those things.

Speaking of what I'm working on, it's a good example. It's about done, save deleting threads on closure (maybe I ought to call that routine delthreads.exe ). What it does is goes out on Windows Update, runs a check, and then returns URLs to download user installable things, and does the downloading of what the user selects. Now the whole thing was a learning process that took much more time and code than I thought it would. Right now, it's setting at 12000 lines of code and 18 modules and roughly about 10 months of clock time. Once I do what I mentioned, I can do a "release", but there are still 2 or 3 modules that could be cleaned up for reuse, at minimum. But the reward is coming up with something useful and learning much in the process of doing it. But when I began, I never thought it was going to be almost a year before I put the project down and called it done. That's kind of how it goes.

Of course, there's about 20-30 other things that could be done, too, and that's the problem with any computer project - moreso for a DX map/mod: it's never done, unless you get it to the point of it being "good enough" and then quit. Scope creep and sitting on something can be terrible for a project if it is to ever see the light of day - the bigger the project, the more dangers befall it from being completed. It can become irrelevant given the market, function, and OSes involved. Or it can just become tiring to you to work on. Or you forget it and move on to something else. Or a whole host of other things. Kind of how it goes.

[WildcatPhoenix]

Thanks, comrades! This is fantastic advice, and much appreciated.