News | Forum | People | FAQ | Links | Search | Register | Log in
Next-gen And The Future Of Shooters.
I thought this was worth kicking of a specific topic for as this video highlights a potential debate quite well:

UT2015 map run-around:

By far the most impressive and beautiful game engine I've ever seen in proper normal game action. Usually you get this stuff shown off with fancy polished limited-perspective tightly-controlled highly-edited "gameplay" video snippets, but this looks like the real deal. Some goon running ineptly round a DM map with graphics that look definitely "next-gen" to me.

On the other hand, and this is NOT just a comment directed at UT2015, a fast-paced MP game does seem like the largest waste of a fancy graphical engine. Even in this video, when the guy is just dicking around looking at things, it looks great. As soon as he moves at normal DM speed, it's all a blur and you can hardly notice any of the fanciness. 90% of the time in MP you won't get the chance to notice how nice it is, unless you want to be REKT whilst you're standing gawping. SP and other genres allow you much more time to appreciate the quality - but I suspect this might be snapped up by a lot of big online games? On the other hand, with the prevelance of E-sports, tourneys, and casting, maybe the fancy graphics are more useful for the spectators.

Also this once again raises the issue: With graphics potentially becoming this good, what will happen to gameplay? Will this encourage the industry to keep being GFX whores for their homogenous interactive movies, or will anyone try either innovative or more open, exploratory, player controlled gameplay in such fancy environments?
First | Previous | Next | Last
that's a brilliant idea! 
I could literally knock out a shit load of prefabs. I love making little doo-dads with bsp. 
Scampie - I think that's it, yeah! 
I always maintained a .map that was just a big archive of commonly used brush structures and other bits and bobs.

When I mapped, I just kept 2 instances of radiant open, with my proper .map in one and my prefabs .map in the other, and just copied/pasted as required. 
I see the discussion is about a community resource of prefabs, not just editor "support" for prefabs, my bad. 
Why Not 
Just import .map's... 
Because the idea of a prefab is that if you change the source prefab, all copies of it update automatically.

If you mean have the editor reference external MAP files then, yeah, that's an implementation that could work. Valve does that with Hammer. L4D was built on referencing external MAP files.

That also has the advantage of being able to work on an axis aligned piece of geometry in the source MAP file but when you reference it in your level, you can rotate it to lay at a 30 degree angle or whatever.

So it's easy to work on AND interesting to look at in the final level. 
Can't wait for UE4 quake map import plugin. 
If you mean have the editor reference external MAP files then, yeah, that's an implementation that could work.

Infinity Ward had been doing that since at least CoD 3 and possibly earlier. You've described exactly the implementation I'd love to have, but it does require editor support.

The non-90-degree rotations scare me though :) 
Man, that would be a sweet feature for Trenchbroom.

Just think of having:
{"classname" "func_detail"
"_map" ""
"angles" "0 30 0"
with a preview of the referenced map, and a command to open the other map file in a new window.

qbsp would need to support it, but I'd think it would be a trivial preprocessing step (load the referenced maps, translate/rotate/scale (?) them as needed, add the brushes to the original map file in memory, continue normal processing) 
Groups And Instancing In TB2 
TB2 has builtin support for layers and groups. Both layers and groups can contain groups, entities, and brushes, and both concepts are mapped to the map file format using func_groups with special properties. By default, func_groups can only contain brushes and not other entities, but TB2 works around this by adding a reference property to entities. So a group would look like this in the map file:

"classname" "func_group"
"_tb_type" "_tb_group"
"_tb_name" "asdf"
"_tb_id" "2"
// some brushes

And an entity belonging to that group would look like this:

"classname" "light"
"_tb_group" "2"

At some point in the future, TB2 will also support instancing by adding two new concepts: A master group and slave groups. Slave groups will additionally contain a transformation matrix that is applied to the objects from the master group. Editing any slave group will modify the master group and therefore change all other slave groups.

These will be written to the map files as func_groups again, so that no special compiler support is necessary. On map load, all objects that belong to a slave group will be discarded and replaced with the objects from the master group. The consequence is that TB2 map files can be edited in other editors and compiled by all compilers without modification. Of course, if you use other editors to edit a TB2 map file, it might result in groups getting out of whack (missing ids, or modified slave groups). This can be detected at load time, though, so it won't be too much of a problem.

A similar system could be used to support external .map prefabs. I would include these external prefabs when saving the map, and when loading it back again, the included stuff will be discarded and replaced by the actual stuff from the referenced map file. 
My concern is how you deal with target/targetname/killtarget/mod-defined-target-fields, so that you can include fancy doors or whatever. 
"targetname" "ArchDoor_I$"

The instance gets "_I$" replaced with some unique identifier unique to each instance (TB2 would generate these behind the scenes and assign them)? Something like that would work.

If you don't want the auto generated name just leave off the "_I$" at the end. 
Good Point Spike 
I hadn't thought about that yet. I suppose I have to do some replacing or auto generating of keys for this. I'll add that to my issue ticket. 
You didn't even have to change qbsp. That preprocessing would be done in a very simple tool, placed before qbsp in the toolchain. Then you could use any qbsp you like. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.