Quake3World

Silver and Rust.


I'm gonna stop cluttering this thread now, until I'm done with all of them.

What are you using to model those?

It's amazing how much things have progressed since the first post!
How fast can a few people put things into motion. I really am amazed.
Why did it take so much time a few years ago with some people committed to make "this amazing mod" (happened a few times I think)...

They did have the source back then, is it because it's open source right now, and people can simply contribute and improve/implement little pieces of/to it?
They used to have "project leaders" I think, and tasks would dribble down from the top.
I'd like to know how the main contributors look at this...


No real ideas from me, but 2 things I think are important:

All the func_ entities are CPU intensive (IIRC), stacking them on top of eachother can have a major impact on fps. Is someone keeping an eye on this (mod wise), or is it up to the mapper to keep things real?

With all the rapid development, is there a timeline where the first "beta" will be released (or rather 1.0)? I think a lot of mappers are holding out because every week there are new cool features to be had, and mappers are keen on those features

indeed, waiting for a bit more progress before committing to a sp campaign.

might start planning all the same.

@ Obsidian, Max 2009.

spookmineer wrote:It's amazing how much things have progressed since the first post!
How fast can a few people put things into motion. I really am amazed.
Why did it take so much time a few years ago with some people committed to make "this amazing mod" (happened a few times I think)...

They did have the source back then, is it because it's open source right now, and people can simply contribute and improve/implement little pieces of/to it?
They used to have "project leaders" I think, and tasks would dribble down from the top.
I'd like to know how the main contributors look at this...

I really don't know. I have no idea how these sorts of things used to be picked up, but I'm trying to make sure to keep this as open as possible. If anyone has a great idea, asset or piece of code to contribute I'll try to make sure it goes in. I think that with Q3's current state of life, it actually helps that people don't have to commit themselves to something. You know, if you sign up as "the" modeler for this mod, everyone expects you to produce a gazillion models for the mod. But if you're allowed to go "hey, here's some cool models" then people are probably more inclined to just go ahead and create a little something.

spookmineer wrote: No real ideas from me, but 2 things I think are important:

All the func_ entities are CPU intensive (IIRC), stacking them on top of eachother can have a major impact on fps. Is someone keeping an eye on this (mod wise), or is it up to the mapper to keep things real?

I dunno, is it really a problem with todays powerful PC's? It's all up to the mapper to make sure things run smoothly. Always has been this way. Q3 doesn't warn you if your tris is too high either, does it?

spookmineer wrote: With all the rapid development, is there a timeline where the first "beta" will be released (or rather 1.0)? I think a lot of mappers are holding out because every week there are new cool features to be had, and mappers are keen on those features

Not really no, not yet. I've been going at this pretty casually, doing stuff whenever I feel like it. I guess that won't change. Right now I've got some ideas for increasing the flexibility of spawning bots into the game, making it easier to create a more SP-like game (I hope). I've also had some suggestions from TiggerOn in regards to respawning after death which seem interesting to explore.

Once that stuff is in I should take a look at what needs to be done before it can be called a 1.0 beta version or something. The problem is that to determine how far it needs to go, some people need to actually work with it and tell me what's missing. What I'm thinking of right now is that I'll maybe do one or two more alpha releases and then freeze the feature set and only work on fixing bugs and streamlining things. Then any feedback from mappers can be applied on the beta.

I may want in on this. If you need any misc models doing, give me a shout, would be up for a few small things for a larf.

for enemies, surely some of the cool models that used to be up on Polycount (I'm looking at the q4gladiator, Magdalena and others by the Brothers Grimm) can be used as enemies with tweaked bot ai?

If this gets up, could open a lot of possibilities.

EDIT: Apparently this was posted earlier... maybe worth a second look though might be some new stuff.

You should check out this thread for new entities being added to the next release of Defrag:
http://www.q3df.org/board/viewtopic.php ... 27&start=0

It's quite long now but there's plenty of ideas there that I think would be suitable for your mod. There's a few videos posted as well showing off how some of them work but you'll have to sort through it to find them. Berserker might be willing to share some of the entity code if you ask nicely. No promises though

Also a long-term dream of mine has been to recreate the entire world from Zelda 64: Ocarina of Time for the Quake 3 engine. So my suggestion is to make all of the mapping elements within that game possible

Here's a sneak peek list of the features that will be there in the upcoming 0.4 release of the mod:

• It's possible to create ladders
• target_debrisemitter emitter spits out DaEngineer's debris models
• Holdable keys. The player can pick up all four keys and the HUD will display which keys you are holding.
• The target_botspawn entity just got a whole lot cooler. The bot is now actually spawned at the location of the botspawn itself. You can also specify the amount of health the bot will have. This can be 1 health but can also be 10000 health. It's also possible to define which weapons the bot will spawn with. So this will allow you to spawn a bunch of weak (20 health) visors in there with shotguns or spawn in a really strong Tank Jr with a BFG. Also, bots can't pick up any items or damage each other when in single player mode.
• The target_logic entity can now be targeted by up to 10 entities. So you can create situations where a bunch of buttons have to be pressed to open a door. Or, for example, have the player find four keycards which need to be inserted into computers or something and when all four are inserted, a door will open.

There's a lot more, including some fixes (joining the spectators in 0.3 causes the game to crash for instance) but these are some of the most important changes. I'm expecting to release 0.4 somewhere around the weekend.

Oh my this is so ace... Only the health meter for enemies is missing, then we could build up a Diablo 3D xD (Or Commander Keen 8 =))

@add: Seeing Hipshot's keys in the screenshot thread: Would it be possible to add some key riddles? Or well, that some gold keys are not fitting the gold lock with the three-typed key bit but with the two one? (hopefully I described it enough...)

Fucking sweet, thanks eraser.
Think I'm going to have some fun with this in the easter weekend.

Ok, dying just got a lot more interesting.

When in single player gametype, when you die, you drop a "Backpack" item. This item holds all the weapons, ammo and holdables you had at the moment you died. You respawn again with the default weapon loadout, presumably at the start of the level (but mappers can do some smart things with progressive spawning). Now you'll have to run to the point where you died to pick up your backpack. Of course the level will be in the state like it was when you died, meaning any defeated enemies are still dead and previously unlocked doors are still unlocked. As a level designer, you have to take this into account though, that a player might pass through an area twice, once in fact barely armed at all, so set up your triggers wisely.

The previously mentioned "progressive spawning" is basically where you use multiple info_player_start or info_player_deathmatch (doesn't matter, they're identical entities) and use triggers and target_disable to disable/enable certain spawnpoints based on the player's progress. I'm looking into smoothing out such a system a bit more, but it's possible to have a player spawn at a certain point deeper into the level if he dies after that point.

One problem though, currently the backpack uses the blue CTF flag as a stand-in model. So I need someone that could create a cool looking backpack model. Anyone interested in doing this?

Eraser wrote:Anyone interested in doing this?

I'll try. Practice is a good thing. But I guess when it comes to texturing Obsidian will overrun me. But that's okay, all of us had to learn all this stuff first

Oh, just a general announcement: if anyone feels like making models, effects and shaders and all that comes with it for new weapons, I'll be glad to implement them. In fact, if anyone can create non-EULA breaking assets for any of the Team Arena weapons, I could include those by simply removing some #ifdef lines in the code

Another change in regards to respawning. The info_player_deathmatch entity has received some additional functionality that might prove crucial in "checkpointing" a player through the map. What I mean with that is that players, when they die, don't have to replay the entire map to get back to where they were but respawn at a checkpoint of sorts.

Each info_player_deathmatch entity can now be enabled or disabled by pointing at it with a triggering entity. When the trigger is fired, the spawnpoint is toggled on or off. When it's off (disabled) no one can respawn there. I've also added a complementary spawnflag named DISABLED so you can make spawnpoints that start off as disabled.

The last change is (and this is only true for the single player gametype) that players are respawned at the nearest enabled spawn point instead of the furthest like vanilla Quake 3 does.


Also: ending the game?
One thing I've been thinking about is how to end a game. I mean, a single player map needs a proper end-game state, right? What ideas do you guys have for this? A very simple and quick solution would be to have an intermission camera set up with some text appearing in the screen (customizable by the map author) but there's probably more interesting ways to do this.

I guess statistics are always a good thing. What about these:

• shots fired
• shots hit
• secrets found (there really needs to be a triggerable entity that counts secrets the player has found)
• enemies killed (like: X of Y or X/Y)
• time needed
• deaths

Also, a loading screen (jpg or tga files) before and after levels would be nice. You could skip the screen with the fire button. On these screens the player could be informed about the story, his objectives and so on.

Right, objectives. A SP Mod without objectives is a bit dull. The score board you usually use to look up who leads the game and who's the bottom feeder could be replaced by objectives. The possibility to cross out completed tasks and add new ones while the player progresses would be nice.

Another topic: damage done to the player. In SP games, the player is usually much stronger than the foes he has to fight. This is not yet the case. Can the damage done by enemies be scaled? Maybe depending on the difficulty level? Otherwise the levels had to be stuffed with health over and over, and that's not very singleplayer-esque.

I'm making progress with the backpack by the way. Maybe I'll upload a picture this evening.

DaEngineer wrote:I guess statistics are always a good thing. What about these:

~snip~

Also, a loading screen (jpg or tga files) before and after levels would be nice. You could skip the screen with the fire button. On these screens the player could be informed about the story, his objectives and so on.

Right, objectives. A SP Mod without objectives is a bit dull. The score board you usually use to look up who leads the game and who's the bottom feeder could be replaced by objectives. The possibility to cross out completed tasks and add new ones while the player progresses would be nice.

Yeah, these are good ideas. I had already written up an issue on the Google Code project page for replacing the scoreboard with an objectives screen.

DaEngineer wrote:Another topic: damage done to the player. In SP games, the player is usually much stronger than the foes he has to fight. This is not yet the case. Can the damage done by enemies be scaled? Maybe depending on the difficulty level? Otherwise the levels had to be stuffed with health over and over, and that's not very singleplayer-esque.

You're on to something here. I hadn't thought about that yet. Very good point.

DaEngineer wrote:I'm making progress with the backpack by the way. Maybe I'll upload a picture this evening.

Great. Can't wait to see it

It's backpack time. The dimensions are 32x24x27 which looks very natural in-game. I've made no UV map so far - where can I get copyright free textures from? Making them by myself is one solution, but I don't have my camera at hand until next wednesday.
The backpack has 870 triangles; that's quite a lot, but I can't reduce them even more. But that shouldn't be too much of a problem nowadays.

Holy cow, it's starts to be really amazing . Can't wait to get new release into my hands, with bots spawn control, and "checkpoints" we can make sp map and missions now! Wow, after all those years it seems like we will have at last Quake III sp mod.

Looks good. Let me know if you need help reducing tris and with the texturing (I can take a picture of my genuine WWII bag).

Eraser wrote:Oh, just a general announcement: if anyone feels like making models, effects and shaders and all that comes with it for new weapons, I'll be glad to implement them. In fact, if anyone can create non-EULA breaking assets for any of the Team Arena weapons, I could include those by simply removing some #ifdef lines in the code

iirc OpenArena`s game assets are under the GPL license, you could ask them if you could use their TA weapon models. Up to you though, thought it would save some time though.

obsidian wrote:Looks good. Let me know if you need help reducing tris and with the texturing (I can take a picture of my genuine WWII bag).

I just took a look at the model again. I think I can chop off some tris I didn't notice before. After that you can of course try to reduce them even more. Pictures of this bag of yours are highly appreciated! And some uv mapping help maybe too... I have to get used to this first.

You could probably get rid of the strap geometry on the front of the pack and just draw that in to the diffuse.

Silicone_Milk wrote:You could probably get rid of the strap geometry on the front of the pack and just draw that in to the diffuse.

Would be a solution if I create a LOD for this model. Eraser, if you already want to try out the model, grab it here. It has no real texture yet so I baked rendered ambient occlusion shadows into it until I can texture it.

But there's a strange effect I get on this model (I replaced the MG ammo with it to see it in-game). When you're very close to it, everything looks just fine. Walk some steps back, and a grey line appears where I've mirrored the model. There are no overlapping vertices or gaps. What's causing this? This grey seam appears also if I use the backpack as a static model, and it's independent of AA or AF.

Left: Seams, Right: No seams