but I think what Epic are doing with releasing this for free along with the community built UT is straightforward. Everyone is going to get lots of first hand experience with arguably the best engine in the industry at an entry level price that everyone can afford.
This means every college and university in the country will be focusing on this engine for its lessons. Every amateur develop now has access to the best tools.
It also means there will be a more skilled U-engine developers hanging around, we should see an increase in the quality of low budget games and this may have the effect of big budget studios reconsider their pricing structure.
Games are, understandably, very expensive to make and need to be expensive to return a profit. The market needs homogenisation in a way that levels the playing field entirely. Most other creative endeavours work this way (except for film, which is also expensive) and the benefit is a low price point.

Also, yeah UT looks beautiful and you're not likely to stand around admiring its beauty in DM but those developers can eventually concentrate on their own projects which may yield a game worthy of this graphical power. I expect with VR on the near horizon that we'll see a lot of games that truly take advantage of this tech. 

Another way of looking at it is that there is a very level playing field now in terms of the graphical fidelity that any developer can achieve, as game engines have moved into a commodity market that everyone has access to.

The real trick now is creating something compelling with that engine! It's all about design now.

I've had a run around that UT map in the video and fuck me it is beautiful. The nice thing is that even when moving at high speed the map reads very well thanks to the primarily white environment with AO picking out the details. It is surprisingly easy to see where to go. In contrast I found some maps in UT3 to be more difficult to navigate when going at full pelt.

Another thing is tools. UE4 blueprints are a godsend for people like me who can't code for shit and find coding extremely boring. So now in UE4 I can build levels, create enemies, weapons, ai, level scripting, cinematics and everything else I could possibly want without touching a line of C++. I am sure other engines have something similar as well.

So I think you will probably start seeing *more* interesting stuff coming down the line, purely because everyone has access to the these amazing tools that make creating games easier for everyone.

Now fucking make an Unreal sequel using UE4 kthx Epic! 

I'm just gonna go ahead and make a prediction that we are not suddenly going to get a big Unreal 1-style exploration-FPS with the art fidelity shown in that video. Single-player FPS games that look like that are still all gonna be tightly linear, 5-hour "experiences", with mo-capped celebrities reading cliched script. Sorry chaps! 

Another way of looking at it is that there is a very level playing field now in terms of the graphical fidelity that any developer can achieve, as game engines have moved into a commodity market that everyone has access to.

The real trick now is creating something compelling with that engine! It's all about design now.

Not to rain on anyone's parade, but you've still got to make all that art somewhere. How is the art creation pipeline different to what it's been for the last few years? 

 

"Now fucking make an Unreal sequel using UE4 kthx Epic!"

Hey, we gave you the engine for free. You do it. :P 

Not to rain on anyone's parade, but you've still got to make all that art somewhere.

The UE4 marketplace has a bunch of asset packs for purchase. Not ideal, but a quick way to get decent looking assets you may need to start futzing around. 

should be happening in UE4! 

Does UE4 support oldskool brush-based mapping? 

Sort of. But they suck shit. It IS better than UE3 imho since they auto-update when you move a brush, and seem more responsive than UE3, but yyyyyyeah. They are strictly meant for block outs. 

BSPs days are numbered although it's unclear what that number is at the moment. 

Not to rain on anyone's parade, but you've still got to make all that art somewhere. How is the art creation pipeline different to what it's been for the last few years?

Correct. I simply meant that in the past if you wanted a good looking game you had to either pay out the arse for an engine license or create your own game engine from scratch. Now you can just dl UE4 and problem solved.

I'd like to think that the quicker iteration time and the fact that designers don't need programmers in order to create new gameplay interactions will hopefully allow even AAA to create some interesting stuff as the risk will be lower. We will see :P 

I'd only be interested at making a quakey game if I could slap it together in-editor with good old chunky brushverk.

Having to model and uv-map everything in something like maya would be a big turn-off. 

Kinn

Well, newer engines aren't likely to focus on older tech like BSP. It's just not productive.

It might be possible to do something interesting with blueprints and have them generate some sort of brushwork on the fly ... if someone were more skilled than myself ... hrm... 

I plan on making a quake or heretic style game at some point. I just need to level up my 3d model skills ;) 

It's not about BSP specifically, it's more that I think it is always attractive for non-artists to be able to quickly slap out and texture simple level geometry in-editor - whether that be brushes, or some other structure.

There's a whole host of retro-type games where this "look" is perfectly good. 

Yep, agreed! We have ideas for a BSP replacement ... just not ready to talk about anything yet.

But quick geo creation is definitely the key. Fast prototyping is always a win and, as you said, some games are fine with simple geo. 

Sounds like something I'll be using! 

I think there is some brush-layouting addon for Blender.

Anyway, free engine notwithstanding, you still need a team of people who have the skills to make a game looking that good. They cost money. Awesome-looking assets don't exactly make themselves.

As for multiplayer games, it depends. They aren't all equal. For a Quake 3 type game, sure, gameplay is literally everything and that used to be the same for UT. I guess all the graphics power is a sales argument (don't forget, there's still that 5% royalties, and graphics basically sell better than no graphics.) It still matters how the game looks in screenshots and youtube videos.

I predict indie games will largely stay with pixel art and whatever else is easy to make, thus user friendliness of a game engine will be the deciding factor there. I think Unity gobbled up all the easy-to-use reputation so far.

I wonder how long general-purpose game engines will stay free AND provide this feature level. I could imagine big publishers going with inhouse engines and indies using some cheaper downgraded general purpose engine in the future. It will be interesting to see if Epic makes enough money this way.

Nonetheless, I'm planning to use UE4, and that large pot of money Epic want to dole out to worthy projects also looks kinda tempting. 

I was recently employed (like last year) with a developer that had just made about 270 layoffs to go from a 300-man company to a 30-man one. I joined after all that went down.

One of the first things that happened was the in-house engine got the chop and was replaced with Unity. 

I'm imagining UE4 being easy access it might also inspire a host of 3rd party tools to import / export levels and other assets no ? Eg as to the BSP or other old school mapping. 

The full source code is available on github so it's perfectly possible to write a Quake MAP importer or whatever. 

I smell a bounty coming... 

:) 

I would find it much more motivating than UT4 by a mile. No offense meant to Warren/Epic. 

Well, the engine is free and the source code is available ... have at it! :) 

You guys understand that "we want next-gen levels of detail" and "we still want to make everything out of gigantic brushes" are fundamentally incompatible, right? 

Next-gen levels of lighting, model detail, texture detail, etc. are incompatible with brushes? 

They are somewhat incompatible, if you have super-hi-res textures on more simplistic brushwork it often doesn't look so great, it creates a weird a weird contrast that is not easy to get around.
If you want complexe shapes, you're better off modeling instead of using brushes, and their goes your production times.

It's probably doable, but you need strong art-direction to know exactly how to get it right I think. 

Kind of. Unless you want large, flat, normal mapped walls and call it "next gen". 

It does kind of depend on the environment you're making. I can easily picture a RMHoney in UE4, for example.

Willem, you can always stick a couple meshes on those large flat walls ;) 

Just use lots of parallax mapping!...

If you wanna do really neat complex things like you see in highly detailed things, 3d modelling tools are the tools for the job. All those chamfered edges and greebles and pipes... it's just easier not messing with brushes. Takes time though. 

Takes time though.

but you can also leverage the tools that come with those modelling packages which saves time too. 

I don't want next-gen levels of detail.

Just thought it'd be nice to make a quakey game with a quakey level of detail in a cool-arse modern engine like UE4, because then it's manageable art-wise for a lone bloke in his bedroom (i.e. me), and you can still goon around with all the other UE4 features that don't take up all your time.

Really, does anyone here really want to spend all their time masturbating over a super-detailed made-in-zbrush wall-panel texture when they could be slapping vast, but low-poly, quake-esque levels together? 

I once spent 6 months trying to make a load of Doom3 stuff that was visually at least as rich as the stock Doom3 stuff.

Fuck that for a game of soldiers. 

"Really, does anyone here really want to spend all their time masturbating over a super-detailed made-in-zbrush wall-panel texture when they could be slapping vast, but low-poly, quake-esque levels together?"

Well, yeah ... that's what I do these days. At work and for fun. So ... whatever, man! You're not my real Dad. 

I think what sock did with Quake for Darkplaces with his tweaks is about the level of detail I would go for (with some shiny features) if I was to do a retro style FPS game. Having access to features like particle effects and not having to worry about certain limits would be lovely.

Pic for reference -

http://www.simonoc.com/images/design/sp/its62l.jpg

http://media.moddb.com/cache/images/mods/1/21/20892/thumb_620x2000/its71l.jpg


http://media.moddb.com/cache/images/mods/1/21/20892/thumb_620x2000/its70l.jpg 

that's the sort of stuff 

well, i'd rather use awesome modelling tools to create even vaster quakey areas. :)

TB2 is getting there, but I still prefer making stuff in 3dsMax. Even if the damn scripting language blows up every other version. Friggen autodesk. 

I think to really start going faster in Quake editing we'll need to borrow some ideas from current gen games.

Instancing of brush groups would go a LONG way to aiding productivity. Want to change what that pillar looks like? Change one and they all update. Boom, you're moving on to something else in 1 minute instead of 2 hours of replacing all the pillars in the level... 

Quake 1 editing certainly needs lots of forward planning in that regard. Which is why the blocking out method is recommended. I usually make my prefabs inbetween blocking and detailing so that I'm happy with those types of things before I have to redo every single detail in the map.
There's definitely some really great features that I would love, one of them is making a standard prefab and then being able to stretch it out (like a railing) and the engine just makes it extend out properly without any skewing or deformation. I would love the hell out of that. 

well, i'd rather use awesome modelling tools to create even vaster quakey areas. :)

TB2 is getting there, but I still prefer making stuff in 3dsMax. Even if the damn scripting language blows up every other version. Friggen autodesk.

For me it's always been modelling tool for anything rocky or terrain-like, but I've never found a modelling workflow for low-poly architectural stuff that comes close to matching the speed and accuracy of (quake editor of choice). Maybe I just suck at modelling. 

https://www.youtube.com/watch?v=iBgxdZ7x5go 

"How does Quake look in 2013?"

Like shit, apparently. 

Yeah that updated look does not lend itself well to quakes low poly everything. 

Jesus, my eyes ... that's horrific. 

I thought this discussion was too 2001 and passe for you, cocksniffer. 

I think modular can also be done with brushes. It just tends to look less interesting than unique spaces, unless perhaps someone did it really well.

I remember that Vondur map that was all arches, that seemed very modular but it also had the downsides of modular.

Community repo of brush modules? 

THAT could be very interesting. If Trenchbroom or whichever app could hook into a central repository of Quake brush prefabs ... properly textured so you can just drop them in without worrying about it. Slipgates, arches, windows, etc.

All the generic crap you rebuild all the time.

There WAS a website way-back-when that did something like that. Had prefabs you could download. Slipgate Central? Can't remember... 

this one?

https://www.quaddicted.com/webarchive/prefab.planetquake.gamespy.com/index.shtml 

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. 

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" "crazy_arch.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) 

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. 

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.