All hands on deck

Hi tony,
Thanks for your reply as always your expertise and experience is very much appreciated and will be taken on board. I myself will be working on the characters section, never having worked on a project like this before i wouldnt even think of questioning your judgement so i’ll take your comment on the characters as writ and discuss with john what we can cut and so fourth. I think we have a few ideas on that anyway.

As for the sound the way its written down is very misleading i think the <1 day was menat to specify between 1 minute to an hour or so if that helps any, i can see looking at it its very misleading now…my fault cos i helped write it :oops: Your point about recycling sounds is very well noted too thanks for that im sure there are plaenty of cases where we can take advantage of that.

Guys the art needs to be seriously scaled back. Allow no less than 2 hours for ANY assets, even the simplest – I’m assuming this time includes modelling, unwrapping and texturing (do you also need proxy meshes/LODs for Unreal?)?

I would advise scaling back the number of characters to Browning, Remington and cat and then 2 slightly different “extras” and reuse them as much as possible- use changes of hue in textures and slight variations (eg. moustaches, hair colour, clothing – and thats just for the women!) to make them appear to be different.

Also crank back the locations if possible, and check out this site for free background textures:

http://www.mayang.com/textures/
They have a section on old residential buildings, I’m sure you’ll get some pics from London there

Worth checking out the Total Texture collection too from http://www.3dtotal.com if you can spare $30

Gotta go now, but I’ll be back on over the weekend to continue.

Pete

hi pete,

i have the complete total textures series, which hurt the pocket big time, havent tried mayang yet but i think i got some textures there before which were very good so i’ll give that a look we should be okay for textures after that ive just burned a gig not including the TTextures.

Your Point on the characters in duly noted, (come here my pretty bearded lady)

im sure i’ll run into the odd character problem or two so prepare yourself for some grief over the next 10 weeks.

LOD was not something we had previously planned on using but rather limiting the amount of characters on screen to 7 or 8. However since your post makes more sense in reusing generic npc, a nice LOD setup would, I imagine improve performance and probably the amount of reusable characters we could put on screen at once. What would you suggest?

Also any reference i could find on poly counts suggest between 2.5K to 3k polys. Considering this isn’t a multiplyer FPS what do you think we should aim for per character poly wise?

You can pack a good bit of detail into 2500 polys, if you check out the characters in the screenies here:
http://amd64downloads.filecloud.com/dreadnought.asp
each of the characters here had about 2300 polys, but the normal maps are doing a lot of work. Unreal 2004 doesn’t have per-pixel lighting AFAIK so this will cut down on your texturing work, but your models will have to be a little spicier. I would keep the characters around 3000 give an extra 200 if you need it, save as many polys for the face as you can and remember its easy to go back later and throw on a localised meshsmooth which will round things off and respect your UVs and bone rig than having to go back and strip out polys from a higher detail mesh which won’t keep your UVs and can mess up vert assignment on your rig.

If you’re using LOD, you can’t beat optimisation by hand, but this is time consuming and patience testing so I suggest you look at the Multires modifier in Max. Drop it in the stack on a rigged character and you can specify a percentage of reduction or even enter a number of faces you want and it will reduce polys in your mesh but try to keep your UVs and your vert assignment. You can see how this looks in Max using the LOD tester utility or any one of several user-written maxscripts from http://www.scriptspot.com, just search for LOD.

I would use a good size texture for the head (512×512 or 1024×1024) and use another for the rest of the character (1024×1024) if Unreal will allow you to export like that.

Just to stress again, character work can be a minefield, give yourself as much time as possible to get the main ones done. I’ve been doing all of the character work at Torc for a few years now so givvus a shout if theres anything you want advice on.

Pete

Cheers for the advice Pete, very much appreciated.
underway on two of the characters since last night, probably wont get much time to do them today cos i have to burn all the software were taking over and then basically vacate my premises for the 10 weeks.

(3) there’s no prioritisation of the programming either, but I have excluded that from my feedback as Peter and Steve are more qualified to talk to that than I am. You need this ASAP

<snip>

Tony[/quote:f5b218502d]

em. the Programming features is prioritised (categories 1 to 4) and then really rough estimates of time requried for implementation of category 1 and 2 features is given.

getting a better idea of this asap would be very nice.
-Cian.

em. the Programming features is prioritised (categories 1 to 4) and then really rough estimates of time requried for implementation of category 1 and 2 features is given[/quote:db45371cb3]so it is, Cian – apologies. All of the mentors said they were happy to be contacted directly (off the forum) so I’ll fire on their email addresses to John

looking at your priortisation on the programming side of things. i think this needs to be fleshed out alot more. [/quote:68705914b1]

I second this. Sorry, haven’t had too many opportunities to check out the progress.

Currently the way it’s outlined it’s impossible to determine whether what’s listed for programming is achievable. How much of this is to be implemented in Unreal Script, how much in C++. Have you identified source examples, do you have a clear design for each piece, or are you starting with a blank paper. Have you done any of this type of work before.

A huge proviso for me is that I’ve never worked with Unreal Enginer directly myself, so any feedback will be in terms of general API / Middleware / Engine use.

One major issue with your current approach to planning is the idea that you can just list all the prgramming tasks as one monolithic to-do list and just start cranking away in some order of priority. Forgive the emphasis but this never works.

You need to think in terms of iterations. These will be a series of functioning prototypes, where each prototype represents some functional / feature improvement over the previous.

* Always have code that runs – and try to break the dependency with the content folks by coming up with a process for “checking in” a new version of the engine which ideally does not break old content.
* Never go for more than a couple of days on development without ensuring that you can get back to a working prototype.
* A good approach is to force yourselved to “checkin” a new build at the end of each week, and to ensure your development branch compiles every evening.
* You don’t necessarily need to use versioning systems etc. (though if you’ve used them before then I’d definitely encourage you to use them now).

Each week, choose the most important features with input from the other team members and work on those during that week. Don’t get distracted with other stuff – let the art/sound content creation happen in parallel. Use .ini files wherever possible to break the link between code and art/design (ideally use XML with a Schema so file parsing will not break when you add to the format – but regular text will be fine for this scope of project, just remember that ini files become “content” too and should be treated just like an art asset i.e. with care).

Your #1 issue will be having to redo content later because the code hasn’t ben locked down, or your polycount wasn’t clear, or you didn’t realise that all objects had to have convex collision volumes or whatever. So get to the point where you have a level running, with a single blob/character whatever moving around banging into stuff. Then iterate from there.

I would be inclined to take the list of features you have for the prohramming effort and recast them as a series of “development stages”. At each stage describe what the prototype will be able to do, what features will be ready etc., and this will allow you to start syncing with the planning for the art side of things.

Above all, assume the game will end up looking quite different from what you’re thinking now. You’ll drop loads of features, add others, change things that didn’t work etc. So where possible embrace change in how you organise yourselves.

Steve

thanks steve.

we’re a bit further down developement now.
We have functioning builds.

of this Category 1 tasks :

Detective reasoning ~ I am working on at the moment
Ghost movement ~ I did most of week one.we’re still having some issues.
Paths finding ~ Unreal has several things built-in. We haven’t done much on this.
3rd person camera ~ Unreal has some nice default camera modes. we decided to bump this task out of Category 1.
Emotional data ~ Leo did during week 2.
Emotional effect ~ Leo did week 2.
Ghost Vision ~ we haven’t worked on yet.
Control system + Menu ~ we haven’t looked at yet.
Map Travel R ~ not essential to show off to the Judges so this is being bumped out of category 1 also.
Conversation ~ Leo is working on currently.

We aren’t able to modify the engine directly, so hopefully poylcounts and things wouldn’t be an issue, However i am still enthusiastic to get the artistic content and the programming work together. We should have a build this friday with most of the content together.

I’ll go over the prioritisation of the programming tasks with John and Leo later today. I know the unreal engine does most things in unreal script, however that said about 85% of processing time is calling c++ code. (which is ~20 times faster)

We can’t currently compile our code into c++ dll’s which unreal script will call, but i haven’t spent much time working on that.