Afaik the dupe checker checks against whatever is currently cached in memory. It does not check dupes against items on disk. Effectively, it is a dupe heuristic. If someone recently accessed the previous submission, the dupe checker detects it.
They mentioned that in some of their twitch streams relatively short after Unreal 4s initial release. I don't remember the number, but it was smaller than what I thought it would be. Plus of course the people not working for epic who contribute to the source code on github.
I believe it was around 70-80 engineers, and the number mentioned in the twitch stream was lower (keep in mind I have no experience when it comes to writing large 3d engines. maybe my expectation was ridiculous to begin with). I actually tried to hunt down the video in which they mentioned that, but Epic is just too productive when it comes to producing videos, and I gave up. :D
I would say 70 is definitely very high for an engine. Most games don't even have that many programmers overall. Although I guess this also comes down to definitions. Like do the IDE/tool builders also go under the engine team? Then 70 isn't too high.
Another great example of positive impact of open sourcing. They open sourced unreal engine some time ago, thanks to that we see 92 changes from community alone in this release.
It's open source with a pay x% once you get big enough to make $y thousand a year. It's proven effective and I hope more open sourcers copy the business model.
Imagine if Mozilla was supported like this instead of being paid for customer data. It would be a game changer.
The principle of the model is make em pay once they can afford it. So having X employees would usually mean the company can afford to pay say $10 per employee per year to use it.
I understand what you are getting at, but that particular example sounds like a great way to convince companies to adopt a 'no OSS software on work machines' policy.
And what else would they use? You have regular paid software, or OSS software that scales with your business at a reasonable price. I know which i'd take.
It's interesting that Unreal releases end up always on the front page, but when Crytek released the source code of Cryengine 5 for free ~3 weeks ago [1] (with DX12, official C# bindings, volumetric clouds, no royalties, even better renderer, VR support for all major VR headsets, Python scriptable editor based on QT, a humble bundle including Ryse assets etc.) it didn't even scratch the front page.
I know most people prefer Unreal for ease of use, documentation etc. but I also read often that they like the technology of Cryengine better (real time GI (SVOTI), better performance, better skin and eye shader for example), so I would have thought that the free source code release would stir things up.
Yes, Unreal released the full source code long ago, so they (Crytek) are late to the party, and the marketing of Crytek is... not the best (to put it kindly), but why is it that the Cryengine 5 release was not really discussed on HN?
I'm guessing it's more an inherit problem of how Hacker News works. Good posts get ignored all the time. Just take a look at https://news.ycombinator.com/newest
And not every Unreal post gets to the front page. The exact same link was submitted way earlier and if the dupe check would have worked this wouldn't be on the front page because nobody would have seen it.
Ok, I should have made that clearer. What I meant was that at least one post on a minor release of Unreal gets to the front page (at least when I'm browsing HN, maybe later or earlier in the day the postings are not on the front page). Out of curiosity I checked my above claim and it was wrong (hehe), but many releases hit the front page:
But it's probably as you say. Not every interesting post (which also depends on the readers interests, of course) get's to the front page. Coupled with the bigger mindshare of Unreal, and the not so interesting Cryengine releases in the past (especially compared to Unreal) we get more Unreal postings on HN.
The best way to affect this is to post more good stories yourself. You can also add a first comment to the thread explaining what you think is good or important about the story.
Tech isn't the only important factor with software, community matters a lot.
I've used Unity, Cryengine and Unreal. Crytek has some great tech but they are very deficient in supporting the community and Epic has invested a huge amount of resources into training, content, tools and even no-strings attached grants for devs working in Unreal. I'm not surprised at all that this has translated to more goodwill for Ue4 on HN than other engines.
Not to mention the focus of the game industry (and game players) has shifted towards mobile in the last few years. UE and Unity both support, and are heavily used, for mobile games, while CryEngine is behind on that front.
Even strictly just on the PC gaming side of things, Unreal's adoption rate among game devs is miles and miles ahead of CryEngine. Is it really that hard to imagine why the community cares more about Unreal Engine than CryEngine?
This has been true for years, idTech, while being arguably technically more impressive, was being written about far less because while it's ostensibly licensable, nobody actually did it.
I just registered at CryEngine because of your comment. Unfortunately, I can't find out how I can get the source after registering for an account. There's only a link to a 'launcher', but it's a .exe and doesn't seem to run on Linux. Googling lands me in their manual that does have a page on compiling for linux, but nowhere does it say how to get the source.
Maybe I'm not a typical game developer, as I don't like to do my actual developing on Windows, but in UE4 I've always felt as a well-loved second class citizen.
Thank you! I hate this massive imbalance in the publicity. UE4 gets almost everything. When a game is in UE4, you can be sure it will be mention in every article about the game, likely even in the title.
But CryEngine? Nothing. CE5 was released and the only thing that's happened was that a few people found out CE(4) existed.
How many games were released on CryEngine? How many on UE 3/4? How many devs are there from the UE 3 days when a lot of AAA titles were some in-house UE 3 variants. I love Crytek products, but I don't see any problems with the upvote distribution. Don't forget that every minor release of UE 4 contains an enormous list of new features and bug fixes which is impressive in its own way considering the release cycle is 3-4 months.
As a Linux user, most other engines, including CryEngine, have nothing to offer me. Unreal was also the first "free" open source release of that class of engine.
No for game developers. A lot of big studios sure but A LOT of indie devs and mobile game devs are mostly developing in Linux or mostly Mac OS X because if you are a mobile dev you have to support iOS. The game dev world is a lot larger than the latest AAA game.
That's why CryEngine is not making news by following in some limited footsteps of Unreal. Unreal's focus on linux is news, as was its initial open sourcing and drastic price drop. Plus, it has a very long, old history that many folks of all ages here are already familiar with.
I personally at least cannot care much about CryEngine as long as its DX only. What is interesting about UE4 is how it is effectively a universal engine for all platforms, including the web.
While I don't particularly care about web support, I agree. Cryengine being chained to DirectX is a problem for me as well. Windows is not my development platform of choice and the possibility of releasing for non-Windows platforms is important - I'm willing to take a cut in graphical capabilities for it.
>It's interesting that Unreal releases end up always on the front page, but when Crytek released the source code of Cryengine 5 for free ~3 weeks ago [1] (with DX12, official C# bindings, volumetric clouds, no royalties, even better renderer, VR support for all major VR headsets, Python scriptable editor based on QT, a humble bundle including Ryse assets etc.) it didn't even scratch the front page.
Maybe the fact that I, a random dev, know Unreal from 100 other sources and sites, but have seldom heard about Cryengine explains that?
In addition to the other responses you got, don't underestimate the power of presentation of content.
Even as someone who is stuck at the "I should really do something with Unreal one of these days" level, there's a ton in this post for me to read and easily grasp about the changes they made. Even smaller features have enough about them I can speculate about the changes that had to be made under the hood to enable them, and what I could do with them if I ever actually followed through on trying Unreal out. The screenshots are particularly nice.
Another great example of this sort of thing is the Dolphin progress reports.
It seems a little silly (it's just extended descriptions and some screenshots), but the effect is real and the effort needed is just often not made because those closest to a project either don't see the need because they're so close, or are exhausted from pushing a major release of the project so just don't have the time or energy to put into a good post about the release.
So, for example, the Cryengine 5 release post is about a major development and there's plenty to discuss there, but there's not a ton of substance to the post, and it's certainly not very engaging for anyone not in the thick of the industry (and maybe not even for them).
Holy crap, the "New Realistic Eye Shading" is insane:
The shading model approximates subsurface scattering
through the sclera, caustics on the iris and specular on
the wet layer. To be used in conjunction with the
provided eye material and eyeball geometry. Together
these additionally model the refraction through the
cornea, darkening of the limbal ring, with controls for
dilating the pupils.
In realtime 3d games. This is pushing up against the limits of what offline renderers could do not so very long ago.
That's pretty great. They should deep link into some of these videos from the notes. I always mean to catch up with some of their livestreams, but they produce a ton of them, so an index to talking about particular features would be great.
Unreal has Unity beat in my mind simply because the Unreal developers are actually building games with their engine (Paragon), which really puts the code through it's paces and makes for a far better testing environment than an artificial demo or two from Unity, that doesn't represent what a full game really uses resource wise per frame.
This can definitely be seen in the usability of the software alone, where Unity suffers some poor interface issues alongside poor performance problems.
By now a lot of high profile games get made with Unity, so i don't think it's really a downside that Unity Technologies don't build their own games. Unity is far less resource heavy and still the king for 2D or mobile games and the latest 3D rendering capabilities are getting close to Unreal as well (see Adam tech demo). I enjoy working with C# and have been using Unity since 2009 in one form or another. I'd like to try Unreal but it feels like it only makes sense for big projects and does not even run remotely well on my macbook.
I'm running a mid 2012 macbook with a Geforce 650M and unreal runs very well, runs even better when I boot into windows. Looking forward to trying the new Metal renderer. For me, Unreal wins on its its extensibility, being able to expose custom functionality to the artist, access to the source even if only for reference.
The last time i tried running the engine it would constantly put load on the GPU (even if the game view is paused) resulting in high temps and noisy fans. I also barely got 10fps in the gameview on a 13" Macbook Pro with Iris 5000 graphics. Did they fix this for OSX ?
It's definitely true that the editor itself is not super lightweight. I believe this has to do with how they are drawing the actual UI. It's a bit unfortunate because the knock-on effect is that running your game in-editor leaves the GPU with even less to work with in terms of resources.
All I can say is the engine runs like rubbish on it, so I'm flat out astonished to hear it runs 'very well' on your 2012 macbook.
This is the compile time for running a 'hello world' project with a few tests:
[2016.03.20-09.44.43:606][ 0]Log file open, 03/20/16 17:44:43
[2016.03.20-09.44.53:841][261]Display: Running Automation: 'NppTests' (Class Name: 'FNppTests')
[2016.03.20-09.44.53:875][263]...Automation Test Succeeded (NppTests)
[2016.03.20-09.44.55:055][264]Log file closed, 03/20/16 17:44:55
real 6m47.566s
user 3m58.869s
sys 0m41.303s
That's not a full rebuild, just running:
./Engine/Build/BatchFiles/Mac/Build.sh TestProjectEditor Mac Development TestProject.uproject
UnrealEngine/Engine/Binaries/Mac/UE4Editor.app/Contents/MacOS/UE4Editor TestProject.uproject -Game -ExecCmds="Automation RunTests TestProject" -unattended -nopause -testexit="Automation Test Queue Empty" -log="TestResults.txt"
ie. It's only compiling the local project files and relinking the engine files. That takes 7 minutes.
With the quality settings dialed back completely, games are... kind of playable.
This doesn't match your experience?
I'm deeply deeply interested to know what you're doing, because it doesn't run like you describe on any apple device I've ever used.
What engine version?
Did you build it yourself? Which branch are you running? Did you change any of the build settings?
What quality settings are you using?
Seriously, I'm not trolling. If there's a magic 'make this actually work' setting some where I'm missing, I want to know about it, because the engine is monstrously slow in my experience, unless you're running it on a windows machine.
My recommendation for people using UE is 'dont use a mac'; I've never once varied from that position in the last year, I'm really interested if you have a different experience.
My experience mirrors yours. I have a high-end Mac laptop, 16 gigs of memory, 1 TB SSD drive. Unreal Engine runs like total garbage on it. Moving around in a simple scene is incredibly slow and painful. Their keyboard controls are also pretty confusing and awful. I'd really like them to support something like the 3Dconnexion mouse[1], which would at least make moving around intuitive and easy, but it doesn't.[2]
yes you would be wrong I have the same model and the hello world example runs WAY faster. I'm not sure how to explain the difference but I do not believe it's an issue with apple.
I have a MacBook Pro mid-2015 2.5 i7 16GB Ram 1tb ssd AMD Radeon R9 M370x. Here are my compile times for a non trivial game set to maximum settings. Literally straight up standard download from Epic version 4.10.4.
Building the game itself:
Total build time: 20.36 seconds
Not quite a exact same test as yours but I've honestly never used the engine in the way you are compiling it there. I understand it's a basic compile and execute tests but I usually run my tests via xcode and build/launch the game from either xcode or the unreal editor both are very fast.
That's the compile time for the game only launching the game editor takes an additional Full Startup: 12.02 seconds (BP compile: 0.17 seconds) according to the unreal engine logs. It feels a little longer than that but not much.
I'm always honestly a little surprised but that Java webapps we have at my day job take a lot longer to compile and launch than Unreal does in my experience.
I will say to be fair in Windows 10 on the same hardware (bootcamp dual boot) Unreal is at least twice as fast. It's kinda crazy and bums me out a bit.
Mostly C++, probably a 80/20 split or so also. Two other things, I've noticed that performance has improved greatly over the last couple of releases and my older MacBook pro (2012 model, 1gb nvidia gpu) wasn't nearly as good. I wonder if it's a case of Epic really only testing on certain Mac Laptops? Not sure I'd still use the engine if I was getting your level of performance on my machine.
Perhaps very well was an overstatment, it runs well enough to use on OSX, I always build from source and I've just done a fresh build of 4.11 on El-Capitan. Build took about an hour. Initial build of the FPS template takes about 90 seconds and runs at an average FPS of 30-35. The Blueprints template runs at about 15fps at Epic setting and about 20-25fps on high. For scenes like this, I set the engine scalability to high or medium and material quality to medium. I often work from within Windows where it all runs better.
I agree this is a big advantage Epic has over Unity. For my current VR project I'm using Unity but as soon as I get the time I'm planning to seriously investigate Unreal. They were showing some really impressive stuff at GDC and a lot of it is driven by the needs of their own games.
Availability of source is another big advantage over Unity I believe. When you run into a problem in Unity you're pretty screwed. At least with Unreal you have the option of diving into the source and figuring out what's going on so you can either fix it or find a workaround.
If anyone told me 10 years ago that Unreal and CryEngine would be, for all practical purposes, free... It's wonderful time to be a gamedev (tech-wise), I presume.
Writing your own graphics engine now seems to be more in line if you really enjoy writing your engine more than the game itself - or if you really want to do something you can't do easily with engines available.
Graphics engines aren't particularly hard to write though once you grep the shader pipeline, as many/all of the latest effects are available for free online (FXAA, HDR, Deferred Lighting etc), though an engine will nicely package them together for you in a ready to use fashion.
The biggest problem with this pre-packaged software is when something ultimately goes wrong, which it always does. Then you find yourself digging round in internals (assuming you have access, looking at you Unity) to find out what when wrong and why banding is appearing only when you use stencil shadows and apply SSAO factor X.. basically, it's still complicated, and you still have to know your stuff.
Another problem with these engines is they force you into a particular way of working. Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale.
Finally you underestimate how much code is the actual game logic, which is also the hardest part to write. In this case the engines don't help at all, Unity even just throws you into Visual Studio and lets that deal with you. Additionally I've yet to see a good solution for figuring out why my AI are running through walls on their way to a target, without writing a ton of custom visualization stuff myself. Many algorithms take place over time (units moving, animating, etc), so you can't just step though code in a debugger as that's like looking at a landscape through a keyhole.
> Graphics engines aren't particularly hard to write though once you grep the shader pipeline
That's like saying "car's aren't too hard to build once you understand the four stroke cycle". Did you read the changelog? The manpower involved is immense.
(Of course you can write a muchmuch simpler engine yourself, but we aren't talking about those.)
Eh, you cut off the second part of what I said.. What I mean is, if you go down the route of writing your own graphics engine, then everything Unreal has is available in bits and pieces for free online, but you have to have the know how to stitch them together - which isn't particularly hard, and something you should know if you are going into gamedev anyway as it's the basics.
Note I'm only talking about the graphics aka shader side here, not the whole engine.
Writing an 'engine' is just good code reuse - as I build my game I have 2 separate groups of projects: one is for the engine where I put generic game tools such as model loading, input handling etc - and the other group of projects is my game logic which contain specific jobs and tasks my AI perform in-game for example.
When new engine features come out, FXAA for example, it's mainly just a case of finding it online [1] and implementing it as needed. I've done this with many parts of my engine (model loading [2], animation [3] and physics [4] come to mind) where I don't need to re-invent the wheel, but I have full source for when I need to modify it (always the case), and it comes unrestricted by licences which is another plus.
Cross platform? Mono runtime + Monogame already has me covered, and I can use a modern language to write my games for faster iterative development.
I both agree and disagree with you. It's certainly possible to write an engine by jury-rigging stuff you find online/in books around, but that will not lead you far. Modern graphics approach is not even possible anymore with elementary knowledge of trigonometry. You can't do anything complex if you don't have, at least, a basic grasp of calculus. It is just not possible anymore. And, on top of that, you have to be able to parse modern research in graphics in order to understand what is going on and why and then implement that. Most of modern rendering approaches lie on the shoulders of this great paper: https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf but they have since built upon that. You have to keep at it, new stuff is always brought to light, and you have to know both how and why. It's a task that needs special attention, a lot of it, and you still have a game to write - which is a large task in itself. So, my takeaway is that it's great to outsource that large of a task to Unreal/Cryengine/Unity/whatever and concentrate on game design and mechanics itself. Unless, you enjoy writing graphics engines/renderers (I wrote a couple over the years, and used in production. I wouldn't do that again.). Other thing is if you want to do something special, not possible with what's available - streamlining performance for certain cases, some special technique, etc.
One other benefit, apart from outsourcing, is that there's now a large pool of people using the same system. So, you're not working in isolation anymore and you can ask for help when you get stuck - and stuck you will get.
Writing a 3D graphics engine is one of the most complex things you can do in software. It requires so much understanding of data structures, efficiency, close to the metal programming, 3D math, vectors, translations, what have you.
Of course it gets "easier" once you've done it a couple of time and understand the basics, but really doing it for the first time is a hard edge to climb.
Been writing my first 3D C++/OpenGL engine for the last 2 years, one of the most taunting tasks I've taken in my career. And just to cover a very specific use case of graphics rendering, not to do cover an overly generalized case like Unreal Engine is doing.
Unreal engine is also over at least 20 years old, so I think you're overly simplifying the task required.
Graphics engine is so much more than just figuring out the graphics pipeline, ultimately it's about flexible data management in a way that lets you achieve what you want, with performance.
3d Math sucks sure, but you can't just use an engine and expect to not have to deal with it. It's just the reality of the situation. Also I'm not denying the volume of work gone into Unreal, but I am saying that roll-your-own approach is still possible, because many of Unreal's features are available online. It's just it's up to you to integrate it all. Of course writing a C++/OGL renderer from scratch is not nice, I've done the same myself and I promised myself never again :-)
These days C# + Monogame solves all my Language, API and Platform distribution problems and allows for fast iteration during development.
Well, anything can be made look sufficiently complex. But there can be(should be) ways to abstract out or compartmentalize a larger problems to make it easier to focus on small sections in visual programming.
It's true that there has been more questions then there are answers, but I was wondering what attempts have been taken thus far to solve it.
More specifically, I was curious to hear if OP had any story to share dealing with this kind of problem.
Writing your own engine is getting to be a harder to justify decision given the affordable availability of these high quality engine options but there are still situations it can make sense.
All these engines make some efficiency sacrifices for generality and feature set. You can get better performance if you have a specific problem to solve and you design your rendering around it. For many games that's not going to make sense but for certain VR applications it still might.
For my VR projects I've gone down both paths and there are pros and cons to each. For many projects though the biggest advantage of these engines are the editors - writing your own rendering engine for a specific use case is a lot less work than building an editor that can compare to these tools.
It really depends on the game you want to make. There's no 1 right answer, it could be that for the given functionality, writing your own engine from scratch might be the best way to go, just depends on the needs of the project.
The depth of these notes, both in verbosity and sheer number of line items, are of a scale i'd expect from a major OS release. The fact that UE is managing these "minor" releases on a regular (and relatively rapid) cadence leaves me baffled about the process they have in place.
A bit of perspective:
bullet points in patch notes: 2625
weekdays since last "minor" release: 100
bullets per day: 26
I don't know how big their team is, but there are days when i don't code 26 lines. The prospect of releasing that many bug fixes and large features is simply astounding.
Capsule shadows are a huge step toward a broader photorealism in games.
You've probably played a number of games (this is especially true in open-world environments) where direct sunlight looks amazing: Everything casts shadows realistically, giving the scene a very believable sense of illumination and depth. But walk into the shadows, and all that vanishes: Even if the environment has some approximation of global illumination, no shadows are calculated (since there would be far too many secondary light sources versus the single sun).
Screen-space ambient occlusion helps somewhat, but it's a hack that looks good sometimes and weird other times. Capsule shadows, if calculated from the top one or two secondary light sources, can approximate the shadows resulting from that complex network of bouncing light in a much more realistic and believable way.
93 comments
[ 3.3 ms ] story [ 188 ms ] threadEDIT: I'm asking because the dupe check seems to be broken.
When I submit something that is already there the systems gives an upvote and doesn't register it as a second post.
But not this time.
https://hn.algolia.com/?sort=byDate&prefix&page=0&dateRange=...
https://hn.algolia.com/?sort=byDate&prefix&page=0&dateRange=...
https://hn.algolia.com/?sort=byDate&prefix&page=0&dateRange=...
https://news.ycombinator.com/item?id=10223645
https://news.ycombinator.com/newsfaq.html
- Improved GC
- DX 12 support for PC and XBox ONE
- Metal as default render for El Capitan onwards
Imagine if Mozilla was supported like this instead of being paid for customer data. It would be a game changer.
The principle of the model is make em pay once they can afford it. So having X employees would usually mean the company can afford to pay say $10 per employee per year to use it.
Under this scalable model it will be users.
I know most people prefer Unreal for ease of use, documentation etc. but I also read often that they like the technology of Cryengine better (real time GI (SVOTI), better performance, better skin and eye shader for example), so I would have thought that the free source code release would stir things up.
Yes, Unreal released the full source code long ago, so they (Crytek) are late to the party, and the marketing of Crytek is... not the best (to put it kindly), but why is it that the Cryengine 5 release was not really discussed on HN?
[1] https://news.ycombinator.com/item?id=11294763 [1 comment --> I myself]
https://news.ycombinator.com/item?id=11300017 [0 comments]
https://news.ycombinator.com/item?id=11313695 [0 comments]
https://news.ycombinator.com/item?id=11295419 [0 comments]
https://news.ycombinator.com/item?id=11297215 [0 comments]
And not every Unreal post gets to the front page. The exact same link was submitted way earlier and if the dupe check would have worked this wouldn't be on the front page because nobody would have seen it.
4.11 - now
4.10 - https://news.ycombinator.com/item?id=10548139 [75 comments]
4.9 - https://news.ycombinator.com/item?id=10147368 [50 comments]
4.8 - https://news.ycombinator.com/item?id=9694885 [98 comments]
4.7 - https://news.ycombinator.com/item?id=9103050 [88 comments]
??? (when they released UE4 for free) - https://news.ycombinator.com/item?id=9132815 [240 comments]
4.0 - https://news.ycombinator.com/item?id=7429774 [163 comments]
But it's probably as you say. Not every interesting post (which also depends on the readers interests, of course) get's to the front page. Coupled with the bigger mindshare of Unreal, and the not so interesting Cryengine releases in the past (especially compared to Unreal) we get more Unreal postings on HN.
I've used Unity, Cryengine and Unreal. Crytek has some great tech but they are very deficient in supporting the community and Epic has invested a huge amount of resources into training, content, tools and even no-strings attached grants for devs working in Unreal. I'm not surprised at all that this has translated to more goodwill for Ue4 on HN than other engines.
Even strictly just on the PC gaming side of things, Unreal's adoption rate among game devs is miles and miles ahead of CryEngine. Is it really that hard to imagine why the community cares more about Unreal Engine than CryEngine?
This has been true for years, idTech, while being arguably technically more impressive, was being written about far less because while it's ostensibly licensable, nobody actually did it.
Maybe I'm not a typical game developer, as I don't like to do my actual developing on Windows, but in UE4 I've always felt as a well-loved second class citizen.
But CryEngine? Nothing. CE5 was released and the only thing that's happened was that a few people found out CE(4) existed.
Desktop Linux is a tiny niche (measured to below 2%), and Linux gaming even smaller part of that.
Heck, even OS X which got around 10% doesn't get much love, gaming wise...
Not for developers. And both Unreal and Unity have Linux editors and support compiling for Linux.
Yes. But while the iOS casual game dev world is in the millions, the Linux game world is still small.
Maybe the fact that I, a random dev, know Unreal from 100 other sources and sites, but have seldom heard about Cryengine explains that?
Even as someone who is stuck at the "I should really do something with Unreal one of these days" level, there's a ton in this post for me to read and easily grasp about the changes they made. Even smaller features have enough about them I can speculate about the changes that had to be made under the hood to enable them, and what I could do with them if I ever actually followed through on trying Unreal out. The screenshots are particularly nice.
Another great example of this sort of thing is the Dolphin progress reports.
It seems a little silly (it's just extended descriptions and some screenshots), but the effect is real and the effort needed is just often not made because those closest to a project either don't see the need because they're so close, or are exhausted from pushing a major release of the project so just don't have the time or energy to put into a good post about the release.
So, for example, the Cryengine 5 release post is about a major development and there's plenty to discuss there, but there's not a ton of substance to the post, and it's certainly not very engaging for anyone not in the thick of the industry (and maybe not even for them).
I've tried the previous versions and the CPU temperature is rising very quickly.
A 2012 iMac is ancient. Are current systems getting hot as well?
This can definitely be seen in the usability of the software alone, where Unity suffers some poor interface issues alongside poor performance problems.
This is my machine:
All I can say is the engine runs like rubbish on it, so I'm flat out astonished to hear it runs 'very well' on your 2012 macbook.This is the compile time for running a 'hello world' project with a few tests:
That's not a full rebuild, just running: ie. It's only compiling the local project files and relinking the engine files. That takes 7 minutes.With the quality settings dialed back completely, games are... kind of playable.
This doesn't match your experience?
I'm deeply deeply interested to know what you're doing, because it doesn't run like you describe on any apple device I've ever used.
What engine version?
Did you build it yourself? Which branch are you running? Did you change any of the build settings?
What quality settings are you using?
Seriously, I'm not trolling. If there's a magic 'make this actually work' setting some where I'm missing, I want to know about it, because the engine is monstrously slow in my experience, unless you're running it on a windows machine.
My recommendation for people using UE is 'dont use a mac'; I've never once varied from that position in the last year, I'm really interested if you have a different experience.
[1] - http://www.amazon.com/3Dconnexion-3DX-700028-SpaceNavigator-...
[2] - https://answers.unrealengine.com/questions/14140/why-isnt-3d...
Building the game itself: Total build time: 20.36 seconds
Not quite a exact same test as yours but I've honestly never used the engine in the way you are compiling it there. I understand it's a basic compile and execute tests but I usually run my tests via xcode and build/launch the game from either xcode or the unreal editor both are very fast.
(tests obviously are not supported for hot reload)
I'm always honestly a little surprised but that Java webapps we have at my day job take a lot longer to compile and launch than Unreal does in my experience.
I will say to be fair in Windows 10 on the same hardware (bootcamp dual boot) Unreal is at least twice as fast. It's kinda crazy and bums me out a bit.
Out of curiosity, what proportion of your game code is blueprint vs. C++?
Mine would be probably 80/20 in favour of C++; I wonder if using C++ heavily has a disproportional effect on the editor speed somehow.
Certainly sounds like you're having a much better time of it than I am...
Availability of source is another big advantage over Unity I believe. When you run into a problem in Unity you're pretty screwed. At least with Unreal you have the option of diving into the source and figuring out what's going on so you can either fix it or find a workaround.
Writing your own graphics engine now seems to be more in line if you really enjoy writing your engine more than the game itself - or if you really want to do something you can't do easily with engines available.
The biggest problem with this pre-packaged software is when something ultimately goes wrong, which it always does. Then you find yourself digging round in internals (assuming you have access, looking at you Unity) to find out what when wrong and why banding is appearing only when you use stencil shadows and apply SSAO factor X.. basically, it's still complicated, and you still have to know your stuff.
Another problem with these engines is they force you into a particular way of working. Unreal blueprints for example are a nightmare once you add a decent amount of functionality as per the law that visual programming does not scale.
Finally you underestimate how much code is the actual game logic, which is also the hardest part to write. In this case the engines don't help at all, Unity even just throws you into Visual Studio and lets that deal with you. Additionally I've yet to see a good solution for figuring out why my AI are running through walls on their way to a target, without writing a ton of custom visualization stuff myself. Many algorithms take place over time (units moving, animating, etc), so you can't just step though code in a debugger as that's like looking at a landscape through a keyhole.
That's like saying "car's aren't too hard to build once you understand the four stroke cycle". Did you read the changelog? The manpower involved is immense.
(Of course you can write a much much simpler engine yourself, but we aren't talking about those.)
Note I'm only talking about the graphics aka shader side here, not the whole engine.
Implementing a cross platform modern game engine is perhaps a single step below writing an operating system from scratch.
Source- I've written 3 feature rich, but not feature complete, game engines over the last 25 years.
When new engine features come out, FXAA for example, it's mainly just a case of finding it online [1] and implementing it as needed. I've done this with many parts of my engine (model loading [2], animation [3] and physics [4] come to mind) where I don't need to re-invent the wheel, but I have full source for when I need to modify it (always the case), and it comes unrestricted by licences which is another plus.
Cross platform? Mono runtime + Monogame already has me covered, and I can use a modern language to write my games for faster iterative development.
[1] https://github.com/SeriousMaxx/FXAAMonoGame
[2] https://github.com/assimp/assimp
[3] https://xnanimation.codeplex.com
[4] http://community.monogame.net/t/which-physics-engine-is-work...
One other benefit, apart from outsourcing, is that there's now a large pool of people using the same system. So, you're not working in isolation anymore and you can ask for help when you get stuck - and stuck you will get.
Of course it gets "easier" once you've done it a couple of time and understand the basics, but really doing it for the first time is a hard edge to climb.
Been writing my first 3D C++/OpenGL engine for the last 2 years, one of the most taunting tasks I've taken in my career. And just to cover a very specific use case of graphics rendering, not to do cover an overly generalized case like Unreal Engine is doing.
Unreal engine is also over at least 20 years old, so I think you're overly simplifying the task required.
Graphics engine is so much more than just figuring out the graphics pipeline, ultimately it's about flexible data management in a way that lets you achieve what you want, with performance.
These days C# + Monogame solves all my Language, API and Platform distribution problems and allows for fast iteration during development.
Could you please elaborate on this one? Do you have first hand experience?
http://scriptsofanotherdimension.tumblr.com/
It's true that there has been more questions then there are answers, but I was wondering what attempts have been taken thus far to solve it.
More specifically, I was curious to hear if OP had any story to share dealing with this kind of problem.
All these engines make some efficiency sacrifices for generality and feature set. You can get better performance if you have a specific problem to solve and you design your rendering around it. For many games that's not going to make sense but for certain VR applications it still might.
For my VR projects I've gone down both paths and there are pros and cons to each. For many projects though the biggest advantage of these engines are the editors - writing your own rendering engine for a specific use case is a lot less work than building an editor that can compare to these tools.
A bit of perspective:
I don't know how big their team is, but there are days when i don't code 26 lines. The prospect of releasing that many bug fixes and large features is simply astounding.You've probably played a number of games (this is especially true in open-world environments) where direct sunlight looks amazing: Everything casts shadows realistically, giving the scene a very believable sense of illumination and depth. But walk into the shadows, and all that vanishes: Even if the environment has some approximation of global illumination, no shadows are calculated (since there would be far too many secondary light sources versus the single sun).
Screen-space ambient occlusion helps somewhat, but it's a hack that looks good sometimes and weird other times. Capsule shadows, if calculated from the top one or two secondary light sources, can approximate the shadows resulting from that complex network of bouncing light in a much more realistic and believable way.
Does anybody has more information on this or know where I can read up on it?