Search the Community

Thanks! Too bad you don't own a game company and pay your employees bucketloads of dough. I need work in a big way.

And I forgot to add. This option would probably be of high interest to ghosters. They tend to come up with all kind of crutches to get around the engine limitations because it does NOT support putting stuff back. Especially when playing on higher difficulty levesl this could be interesting. And I think if we are able to put an item back, we should make use of that for the game as well.

I'm also quite opposed to loot glint. If items are made easily recognizable as loot without going overboard, which T1/T2 pulled off well, then there shouldn't really be a need for loot glint like T3. By having loot glint, you never have those moments of discovery like in T2 where you thought you found all the loot in a room, only to revisit and see a little gold coin sitting off in a shadowy corner, or on the 1.5"-wide top edge of some wall paneling. Loot glint also takes away one of the uses our flares would provide. I love NH's attempt at showing a valuable item. That sort of coloring, also combined with having valuable objects be slightly more brilliant (bump shadowy) -- I don't know how to describe -- would be cool. You know how when you look at a brushed steel surface in a game and you move back and forth you can see how the light reacts to it within its surface? This is what I mean by more brilliant. Valuable objects would catch the surrounding light better and have a brighter brilliance to them than regular objects so they're more visible when you move around. Brilliance maybe isn't a good word to describe, but maybe you know what I mean? Basically, valuable objects would have a higher tendency to be caught by your eye as you walk around. In addition to this, maybe have it so if you walk by an item at just the right angle, it will reflect a single bright flash of light to your eye (unless there's no light source nearby whatsoever). Experiencing this light flash would be a somewhat rare occurrence (since how often would a glint of light hit your eye from loot in real life) and would NOT be a flashing beacon like in T3. This would make hunting for loot funner, imo. Loot glint coupled with loot percentages kind've killed the thieving experience in T3 for me. I disliked loot percentages. I much preferred T1/T2's accumulation of loot value. In T1/T2, you didn't know how much loot you had compared to the total available for the level. So, when you had amassed 1250 loot, you had no clue if there was only 150 loot left, or 2000 left. Part of the mystery of it all.

I think there is a problem with putting something back. It is the physics engine. My guess why this doesn't really work in any game (none that I remember at least) is that it requires special coding to provide for it. If some object is standing in a i.e board, the character can not reach it really. So this means he he blocked by the bounding box of the board. To take the object the code simply looks if the player is near enough and then removes it from the world into the inventory (or players hands). If you would have to put it back, this would mean that the player would have to be near enough. But the bounding box prevents this. It would require a high precision to place the object back. But I think we can do this by either providing a seperate button OR by assuming that the player wants to put it back if the view vector and the distance is in a position near enough of the original position. We cimply must store the original location of the object and replace it in the case that one of the above is true. The nice thing is, that, if we allow this, we could even programm the AI to recognize moved objects. It could work like this. The player takes an object (i.e. a book). When he wants to put it back the object is placed randomly within the original region. If the player holds the button down for a longer time, the object will be adjusted and shift to it's original place. After a certain time it will reach the original place but that takes time. If the object is carelessly placed then the AI could recognize it. If the player takes the time the AI won't recognize it afterwards. What do you say?

Hmm, I'll see if I can photoshop a pic of what I mean. With the kind of glow I'm envisioning it would be so integrated into the game world that you really wouldn't register is as a glow...it would just make things stand out. I'll post a pic if I can work something up.

I agree. Actually when I saw the model alone I had my doubts about it, but seeing it in-game it really looks great.

Hey, all I had to do was shrink it! It's a very nice looking gem/compass. Good work. Can't wait to see it in game.

Since its a model, it can be whatever size you guys want. It may also change relative to the scene depending on game resolution. I took a guess at 800x600 in the link above. I've not yet put nicks and scratches on the surface of the gem, but Ii plan to do so in addition tomaking the points a little more detailed.

Here's a work in progress image of what I have for the Lightgem. Since it differs fairly significantly from the mockup by Pakmannen, I thought I'd post the image to get opinions so I can rework it if nobody likes it I chose to go with a mold-forged iron look with the ring itself which is a look I ended up liking Shrink to about 33% to see the size it would appear in the game, I believe.

You know, I should probably get around to learning Radiant, so I can get actual, working models to you guys. Plus, I have a couple of fragment shader ideas - will have to see if I can't figure out how to get falloff self-illumination glow working. But - it's a model! In game! Awww yeeeah!

ok, its in game... ...sort of. Its not without its problems though DeepO... first of all, its a little on the big side (about 3 zombies high, lol). Scaling is something that happens in Max, not in the Doom3 editor... If it helps you can export objects from Doom3 Radiant and load the into max as a scale reference. Second, its a non Doom standard grid size. Setting up your grid size in Max to match the grid size in doom will make it a hell of a lot easier to attach the lamp accurately to walls Doom uses grids based on 8s, does max default to grids based on 10s? Thirdly, I am having trouble getting textures onto models and ingame generally. (it requires manually hacking the model file and frankly it isn't fun). You're lamp is no exception I'll come back to it in a day or so when I have had a bit more practice.... Forthly, I don't use Max (do I look rich ) otherwise I'd have had a go at fixing this stuff for you. I use blender. It might be possible to share editable copies of the file in .3ds format... Fithly, Radiant has a small moan about defunct triangles. It might be worth checking the model for loose ends...

I'm on it Sparhawk. I noticed the same thing. The concept I'm working on right now fixes that problem, and also gives us a great loading indicator. Gold, I specifically am trying to stay away from the hammer symbol for the overall game. It focuses on the thief, not the builders. Can you think of an appropriate Thief symbol? So far I've been playing with a keyhole or a hooded face, but I haven't found anything I really like yet.

http://fpscentral.ampednews.com/?game=9&site=news&id=7896 Other than the fact that Springheel got lost in the mix (he wasn't there during the interview, I'm trying to get him to fix it), it's a damn good article. The fact that he was able to make us sound so professional speaks well of the guy's editing talents.

Wow, nice! In reality it could be used for either a spy orb or a flashbomb, but we haven't discussed exactly how spy-orbs would work in the game.

Actually, Oofnish, would you be up for modelling the lightgem? We need something to texture so we can start looking at it in game. The thread with the reference material is already created. If you'd rather not let me know and I'll assign it to someone else.

Ah! Now I understand what you mean. We create an AI and a registry bas object which are connected. The Shopkeeper is a special type of AI that can interact with Garrett. This way the mod designer can create the shop design as he want's it and fits his FM style, but he wouldn't need to worry about the coding of the in-game shopkeeper. If you mean this, then yes. Sounds like a good idea. We still would have to create a shop map though, for testing this stuff.

Ahh, but what I'm saying is that it's not meant to unbalance the game. It would be included as a fun immersion adding experience by the fan mission author to allow the character to get the tools he needs to play the mission. It would probably be the top objective of the mission. 1. Stop by the shop to get supplies for the job 2. Make your way to the Builder Cathedral and find a way in. That kind of thing. It wouldn't have to be there for show, but rather as an integral part of the mission...but again, only as an alternate to the pre-mission loading screen that Goldfish submitted. If the mission couldn't believeably use a shop, or the FM designer doesn't want it...use the original style preloading screen.

I'm not sure I understand you correct. If we have the shops ingame (which could be done easily) we need to work out the detailed mechanics of how they can be used. Just putting a shop in there is not really helpfull because it will unbalance the game. What do you mean with "Drop the selling" stuff? It's the point of the shop to supply the player with his initial weapons beyond what the author deemed enough.

The city hb was like this. But we could extract the shop idea and make it into a mini-game which loads before real missions loads. Just like the shop screen would. Or do you mean a shop that will be included into an FM? In this case how should this work? It oculd only work like this that we create a mini mpa for it, and the FM author extends his level around it. Like it was done in The Seventh Crystal (I think).

I was discussing how this could work in the City concept thread. the primary problem I see with this is. It will add an element to EACH map wehre it will be used. How should this work in a cave setting? How will the FM author atioanlize the existance of a shop in the middle of nowhere? If the map is non/linear the player could come back anytime. This means that the balance will be lost because he can buy something in the middle of the game. I don't think that this is a good option. I have to look up the thread where I presented this concept.

Ok, brainstorm away, but we only have sight and sound to work with, and if you rule out sound you're left with sight - i.e, a gem of some sort. ..unless we use Garrett (or whatever he's called) himself as the lightmeter. You look down at yourself, and see how much shadow you're in, I'm sure it would be no more technically difficult than a lightgem icon. Of course in real life it' possible fr the top half of your body to be brightly lit and the bottom half in shadow, but for game purposes, there will only be one amount of shadow for the whole body. You're already going to program body awareness in right? So we may as well put it to good use.

oDDity, I really appreciate your innovation with the sound thing. I to would like to see if we can do it another way. But I can't agree with doing it in sound. Too many times, I have found myself standing dead still in the game, trying, nay, straining to hear even the slightest footsteps or talking, to decide if I should make that mad dash across the foyer in broad light. Hearing them in advance would save my life. When we're talking about sounds that quiet, practically anything can block them out.

I read that you planned to do several bodys and several heads each on seperately to get more variety. I was wondering how this should be executed. Do you mean that just for modelling purposes, or do you mean that will give us coders i.e. six heads with three bodys and we can use them by assigning them randomly on the fly. If the first it doesn't really matter for us, but if the latter then we have to work out if this is possible and we also need the details on how we then can combine and animate the final models in-game.

The overall shape is great, the proportions are perfect, it would be excellent as a low poly game model - but isn't this supposed to be the high res version to source the nomal maps from? You seem to be very tight-fisted with the polys, when you should be writing blank cheques. The main problems as I see it, is the geometric uniform nature of the organic shapes - legs and arms are not perfect cylinders, leather in real life is not flat and perfectly smooth. Eceyting need to be messed up a bt, like it's had a long hard life. And as you say youself, and I pointed out earlier, a lot of the detail still looks injection molded like it's all been beveled out. I have to say, and this is possibly my worst crit - it looks like you're trying to emulate the T3 Garrett model, which I considered risible when I saw in untextured in Lightwave.

It would be more economical to have the heads seperate from the bodies, wouldn't it? It would mean more programming work - we'd have to have a "head type" etc. property for each model, but it would allow for more variety in game. No matter how many unique models you make, if you could swap their heads etc. around, you'd have even more combinations.