The engine is scalable thus low quality settings work on ancient PCs while high settings only work on the best computers. You shouldn't expect to run any current game at the best graphics if you don't have some of the best hardware.
Unreal Engine 4 Wishlist
- Thread starter Fuzz
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
hey ... it's a wish-list
Why do you think that ?
MS is allowing .Net to go multi-platform already.
The equivalent of the code-behind and XAML-scripts for GUI-design.
I was thinking more along the lines of neural networks, genetic algorithms and similar stuff, because as is the "AI" is more a simple finite state machine with path-finding capability.
I'd be nice if we could actually have enemies that could learn without reverting to a blank state at the start of a level.
And lets not forget about AI that doesn't automagically know the location of the (enemy) flag carrier.
hey ... it's a wish-list
Why do you think that ?
MS is allowing .Net to go multi-platform already.
Allowing?! heh.
Anyway, why not to use .NET:
- dependency on a 3rd party module tightly coupled to an OS for which you have no control.
- MS .NET is not multi platform, Mono sort of is. MS can not stop the Mono project.
- bad/no sandbox control (unless you use Mono), you can not isolate the VM instance
- binding difficulties, you have the same issue with Lua or Python, but it's less of a problem
.NET is seriously heavy weight compared to the other options. You're even better of using Java.
What good would that do? You want designers to create the UI, not programmers. I think Epic is making a good choice with the UIScene stuff. Sure, they could save the created scenes in XML rather than the binary format.
Also, why not go the XUL or GladeXML way rather than the XAML way?
Neural networks and genetic algorithms are nice, but way to complex and slow for an average game. Also, a neural network is also a finite state machine. All software is a finite state machine. It's better to adapt the AI to events, which is still a state machine, but a larger one. It's not a neural network. But a neural network that needs to cope with the information produced in a single session in UT3 is quite large.
Warp Zones that work properly! And allowing the player to flip upside down! :tup:
It's probably impossible but it'd add a completely new element to the game without actually changing what's there (what UT needs IMO). Imagine if it worked with vehicles, too.
And allowing the player to flip upside down! :tup:It's probably impossible but it'd add a completely new element to the game without actually changing what's there (what UT needs IMO). Imagine if it worked with vehicles, too.
Last edited:
What do you want from Epic? Honestly.
UT3's minimum requirements equal that of Battlefield 2... a game from 2 and a half years earlier.
Seriously -- bitching about scalability is COMPLETELY wrong for UT3. There's nothing more you can do...
Warp Zones that work properly!
It's probably impossible but it'd add a completely new element to the game without actually changing what's there (what UT needs IMO). Imagine if it worked with vehicles, too.
Sure it would be cool but putting a feature in that they will never use themselves likely isn't going to happen as its money wasted.
Editor with:
* PROPER undo,
* BSP triangulation on request (not aggressive like now), or proper way how to join two faces, or create more than triangular faces.
Other:
* Reflections like in first Unreal. Water in Witcher was so nice - I don't know how I'd make it in UT3.
* PROPER undo,
* BSP triangulation on request (not aggressive like now), or proper way how to join two faces, or create more than triangular faces.
Other:
* Reflections like in first Unreal. Water in Witcher was so nice - I don't know how I'd make it in UT3.
You mean, kinda like this?
Myself, I'd love many of the things that have been said already.
* Better dynamic shadows
* Mesh painting (both for textures and geometry, preferrably)
* Bézier curves for meshes (NURBs would go too far, way too resource-intensive for realtime)
* Parallax occlusion (aka offset) maps
I disagree with quite a few things put forth in this thread too though:
* Fractal textures would be nice, but this requires either a large library shipped for mappers or mappers with good math skills, which would alienate many I think.
* BSP are a thing of the past, meshes are where it's at now
* .net ... you can't be serious, right? I'm coding business applications with .net right now, but nobody in their right mind would use that for realtime-critical game programming
And then there's things like demo playback and all, that (while very nice) are really game features and not engine features
Everyone knows that minimum requirements are to be taken with a good pinch of salt.
the game is already tightly coupled to an OS/hardware-combo for which they have no control.
So ?
The only platforms that matter are Microsoft Windows PC, Microsoft Xbox, Sony PS3 and Nintendo.
Never mind that it all depends on your definition of multi-platform when given that Silverlight 2.0 (which also is .Net) is browser-independent already.
Considering that there's a mobile .Net variant for mobile phones I wouldn't call .Net 'heavy weight'.
Heck ... even Epic admits that Unreal-script is not exactly 'fast' and they still manage to do some pretty fancy stuff.
I've only used XAML as an example of what could be done.
It's pretty nice to have the GUI-design in a format that can be edited without having to rely on a propriety-format wysiwyg-editor.
The current versions of those things may be too large/resource-hungry, but IMHO that's more likely the result of no one even trying to use it in a setting like UT. OTOH Black&White supposedly did use neural-net for its creature.
*ahem* I'd suggest you research XNA ... MS showed a demo-game that was running on a pc (Windows), Xbox 360 and a Zune-player (the MS iPod-clone).
Another example is the 'Dishwasher'-game that won the XNA-contest : http://www.youtube.com/watch?v=xVeap_8wIY8
http://www.youtube.com/watch?v=lscKqMsnpJY
And there's JellyCar :
http://www.youtube.com/watch?v=ZbZoxzl8cXk
(I realise I'm starting to sound like a .Net evangelist ... I just happen to have seen lots of cool stuff for that environment).
No it's not. Nothing of the core engine depends on an uncontrollable system library. UE3 is not tightly bound to directx, if you would replace unrealscript with the .net CLR you would create a tight coupling of the core engine.
Really? as far as I know Sliverlight 2 only works on Windows. The Mono implementation of Silverlight is not yet up to version 2. Besides that, there i no Silverlight support for MacOSX, it doesn't work on the PS2, PS3, Wii, etc.
Have you ever looked at the "mobile .net"? It's even worse than J2ME.
I wasn't talking about execution speed, I was talking about the weight it introduces to the simple object system. UnrealScript is very lightweight because of the way the whole Object system within UE works. Introducing bindings for UE(3) in .NET produces an enormous overhead. That's why I suggested to use stackless python on lua, they have been made for the same purpose as unrealscript: to serve as an embedded language for a program that already provides a VM (the UnrealEngine provides a VM in which you can create real time 3D simulations/games).
And that's why I opted for redesign of unrealscript (and it's byte code) but more importantly: a JIT.
That's true. But it doesn't weight up to be able to use the resource pipeline you already have in place for all other graphic elements of a game. After all, you want artist your create a nice mutli media experience user interface.
afaik black & white didn't use a neural network.
But still I don't think using a neural network for game AI is the correct choice, there are really a lot of variables and performance is very important in games like UT3. You might get away with a decision making algorithm that takes a couple of seconds in a game like Black or White.
Last edited:
Sure
Sorry, I should've made my statement a bit clearer: The trouble with .net is that it's slow-ish, not that it's really really slow. There's the DarkGDK too, and you can make some really cool stuff with it. The trouble is that the Unreal Engine traditionally makes cutting-edge graphics, and those are way more resource-intensive than things like the jelly car (which I like a lot) and that samurai game (which I've just seen for the first time). That's not to say I want to put them down, but for cutting-edge realtime graphics like UT3 has, it's really slow. And taking along the entire .net burden when all you want is a bit of scripting on top of the highly optimized C++ engine, that's just over the top - don't forget we're not talking about creating the entire engine in .net (as that'd be just silly with all the overhead a large framework always brings along), but just about the scripting, and bringing in the overhead anyway when you don't need it in the core engine would be ... a mess, and slow.Those games that are being made with .net then are sprite games, or have 2D or simple 3D graphics, nothing remotely with the graphical complexity of what the Unreal Engine can produce. They're not at the performance border of what a computer can bring.
JIT compilation makes not much sense when you can have a real compiler (since the maps need compiling anyway, why shouldn't the scripts?) and don't want too much reflection-type stuff or uncontrolled platform independency (which you can't have due to high driver compatibility requirements anyway). So compiled UnrealScript would probably be the way to go
Neural networks are great for limited tasks like (after ample training) pattern recognition and (after ample training) expert system tasks, which is basically another form of pattern recognition. I'm not saying they'd be useless in this context, but specialized and narrowed-down approaches are both better-performing and producing more adequate results. Basically, what the AI of a shooter has to do is simply knowing how to get from A to B, and what places and paths are better than others (which it currently does by adding weight to nodes based on how often bots die there).
Not with UT3, I was running the game on minimum requirements and doing so quite well. The game is optimized.
JIT compilation makes not much sense when you can have a real compiler (since the maps need compiling anyway, why shouldn't the scripts?) and don't want too much reflection-type stuff or uncontrolled platform independency (which you can't have due to high driver compatibility requirements anyway). So compiled UnrealScript would probably be the way to go
wtf is a real compiler? The idea of a JIT is to compile the byte code even further to machine code. Of course when you have a JIT you can simply bake the byte code to machine code and use that when you ship the product.
A JIT doesn't mean that the source code is compiled to byte code on the fly. The input of a JIT is byte code.
You don't need neural networks for that. A basic A* implementation is sufficient.
And statistisc like how often a bot dies at some place is not sufficient to give a route a larger weight.
In TerrainEdit is an option to add displacement maps.
And Engine offers theoretically deformable terrain.
But why are this features all unused in UT3
Have you ever seen Crysis terrain with "r_UsePOM=1"? Yum yum!
However some sort of Parallax Occlusion Mapping on terrain should work with Unreal Engine 3 too.
Ever seen in UT3 retail?
So my wish for Unreal Engine 4 (aka UT4) is:
More in game features and less Engine only features.
Cheers
"F' yeah!!!"
Also, parallax mapping sucks, as when you move to the edge of the texture, it no longer occludes, and is flat. Normal mapping is more subtle, but also doesn't screw up when the perspective moves.
Last edited: