 I Know What You Mean
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.
 Well
#2 posted by DaZ on 2015/03/04 11:24:19
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!
#3 posted by Kinn on 2015/03/04 11:26:29
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!
#4 posted by Kinn on 2015/03/04 12:01:01
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?
 2001 Called And Wants His Next-gen Graphics Rant Back
#5 posted by Spirit on 2015/03/04 12:33:07
#6 posted by JneeraZ on 2015/03/04 12:35:55
"Now fucking make an Unreal sequel using UE4 kthx Epic!"
Hey, we gave you the engine for free. You do it. :P
 Well
#7 posted by Zwiffle on 2015/03/04 13:46:37
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.
 That Community Quake Remake
#8 posted by nitin on 2015/03/04 14:21:39
should be happening in UE4!
 Brushes
#9 posted by Kinn on 2015/03/04 14:26:35
Does UE4 support oldskool brush-based mapping?
 Yes
#10 posted by Zwiffle on 2015/03/04 14:29:28
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.
#11 posted by JneeraZ on 2015/03/04 14:39:40
BSPs days are numbered although it's unclear what that number is at the moment.
 Right
#12 posted by DaZ on 2015/03/04 14:41:37
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
 That's A Shame
#13 posted by Kinn on 2015/03/04 14:48:13
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.
#14 posted by JneeraZ on 2015/03/04 14:52:29
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 ;)
 Yeah
#16 posted by Kinn on 2015/03/04 15:44:29
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.
#17 posted by JneeraZ on 2015/03/04 15:57:47
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.
 Oh Cool
#18 posted by Kinn on 2015/03/04 16:04:05
Sounds like something I'll be using!
#19 posted by gb on 2015/03/04 17:16:33
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.
#20 posted by Kinn on 2015/03/04 18:04:36
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.
#21 posted by Killes on 2015/03/05 13:00:53
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.
#22 posted by JneeraZ on 2015/03/05 15:20:47
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 Might Beg Sleepwalker
:)
 I Wouldn't Mind A Quake UE4 Project
#25 posted by Zwiffle on 2015/03/05 17:32:03
I would find it much more motivating than UT4 by a mile. No offense meant to Warren/Epic.
#26 posted by JneeraZ on 2015/03/05 17:42:03
Well, the engine is free and the source code is available ... have at it! :)
#27 posted by Lunaran on 2015/03/05 18:24:46
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?
 Well...
#29 posted by Bal on 2015/03/05 18:32:25
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.
#30 posted by JneeraZ on 2015/03/05 18:32:37
Kind of. Unless you want large, flat, normal mapped walls and call it "next gen".
 Well
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 ;)
#32 posted by - on 2015/03/05 18:49:36
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.
#33 posted by necros on 2015/03/05 18:57:31
Takes time though.
but you can also leverage the tools that come with those modelling packages which saves time too.
 Erm
#34 posted by Kinn on 2015/03/05 19:32:59
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?
 To Elaborate
#35 posted by Kinn on 2015/03/05 19:59:37
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.
#36 posted by JneeraZ on 2015/03/05 20:04:46
"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
 Absolutely
#38 posted by Kinn on 2015/03/05 20:27:35
that's the sort of stuff
#39 posted by necros on 2015/03/05 20:38:50
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.
#40 posted by JneeraZ on 2015/03/05 20:41:18
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.
#42 posted by Kinn on 2015/03/05 21:00:34
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.
 #28
#43 posted by Spirit on 2015/03/05 21:00:50
 #43
#44 posted by Kinn on 2015/03/05 21:02:12
"How does Quake look in 2013?"
Like shit, apparently.
Yeah that updated look does not lend itself well to quakes low poly everything.
#46 posted by JneeraZ on 2015/03/05 21:21:07
Jesus, my eyes ... that's horrific.
 #43
#47 posted by Shambler on 2015/03/05 21:29:13
I thought this discussion was too 2001 and passe for you, cocksniffer.
#48 posted by gb on 2015/03/06 20:49:24
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?
#49 posted by JneeraZ on 2015/03/06 20:55:24
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...
#50 posted by - on 2015/03/06 21:01:41
 WarrenM
#51 posted by starbuck on 2015/03/06 21:36:28
that's a brilliant idea!
 Prefabs
I could literally knock out a shit load of prefabs. I love making little doo-dads with bsp.
#53 posted by JneeraZ on 2015/03/06 22:01:20
Scampie - I think that's it, yeah!
 Prefabbery
#54 posted by Kinn on 2015/03/06 22:16:49
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.
 Ah
#55 posted by Kinn on 2015/03/06 22:21:50
I see the discussion is about a community resource of prefabs, not just editor "support" for prefabs, my bad.
 Why Not
#56 posted by ijed on 2015/03/09 13:38:28
Just import .map's...
#57 posted by JneeraZ on 2015/03/09 14:03:54
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.
#58 posted by Zwiffle on 2015/03/09 14:45:02
Can't wait for UE4 quake map import plugin.
#59 posted by Lunaran on 2015/03/09 20:26:54
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 :)
#60 posted by ericw on 2015/03/09 21:10:08
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)
 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.
#62 posted by Spike on 2015/03/10 11:00:45
My concern is how you deal with target/targetname/killtarget/mod-defined-target-fields, so that you can include fancy doors or whatever.
#63 posted by JneeraZ on 2015/03/10 11:12:32
"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.
 Ericw
#65 posted by adib on 2015/10/03 00:47:42
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.
|