Unreal Engine 4.8 Released
unrealengine.com
unrealengine.com
But whenever I start one of these programs and start trying to go through their tutorials, they want you to go through some convoluted set of menus and toolbox windows to basically do nothing but edit a scene graph. And they have their own terminology for everything. And then I go cross-eyed.
And it's not even "terminal vs. GUI" talking, I actually like Visual Studio. I just want to model in Blender, export models to game-friendly formats, write code, and import them in the game, like every other project I've ever done, like a normal game project.
But even UE's "Expert-mode, C++ template" involves heavy, heavy use of their GUI, which might be relatively stable today, but it's still a hog on resources and terrible buggy compared to even Visual Studio, which itself is no lithe figure. I tried exiting out of the editor and loading the solution directly from Visual Studio and running a build just seems to... open the UE editor again!
I'm not a beginner, I don't want beginner's tutorials, and I especially hate video tutorials. I want something I can read that isn't just "click this menu, now open this tool window". What the hell ever happened to writing code?
All that said, after getting over the learning curve and embracing the technology somewhat (even Blueprint/Playmaker over code sometimes!), I've found that the power available to me is well, well worth the cost.
Once you get in to the mindset, blueprints really aren't that tricky. They aren't the best way to tackle all problems, but they certainly make doing a lot of things very easy once you accept how they function, their limitations, the workarounds and commit some time to learning/practicing working with them. There's certainly an overhead in discovering how different elements of the engine talk to each other and behave together. Really it's no different to any other programming language.
On a multi-monitor set up, the real time debugging is pretty sweet for seeing what's going on and where it's going wrong.
I prefer UE4 - it seems to have a better technological core and I prefer their approach to many different elements in the engine.
Unity is great as well, don't get me wrong, they've had a lot of money for licences/upgrades out of us over the years.
I personally struggle to see how they will keep up with UE4 long-term unless they address some of their built-up historic technical debt quickly. I think even though they are both to some extent 'free', competition is still healthy and should be actively encouraged.
Unity is an app for making games.
The difference in approach leads to vastly different experiences. It will be far easier to make Unity pretty than for Unreal to start being good at editing, good for small teams, good mobile, .. basically good at the things Unity currently does better than Unreal
This is far from unique to video game tools, sadly. There's this growing perception that people greatly prefer video tutorials. Which makes people who would rather read and think a little bit go crazy.
Every time there's a new release of Illustrator (my main tool), I end up pulling out my hair trying to find text descriptions of the new features rather than slow video overviews. And then there's Astute Graphics, who makes great AI plugins that they ONLY documented as videos for a while. Now they grudgingly have blog posts that sort of tell you how they work. Sort of.
Back when I was in games on a 70 person team we might only have 10 or 12 developers so the majority of the focus was making sure that your content builders were effective(and they cost less than getting developers to build content).
I know C/C++ and OpenGL, DirectX and can certainly get a simple game running faster with my own code than with Unity or Unreal at this point.
But... I also go to game jams and watch the guys using Unity or Unreal run rings round those coding from scratch. I see many of my favorite games of all types being created with Unity (Threes, Monument Valley, Crossy Roads, Ori and the Blind Forest, Cities Skylines, Besiege)
I also see the amount of time I'd save. I've written 6 game engines, animation systems, exporters, font renderers, image loaders, serialization systems, spooling systems, memory management systems, input systems, localization systems, etc etc etc. I've ported my engine to various systems. I don't want to do that anymore.
> What the hell ever happened to writing code?
If that what you like doing then do that but me I just want to get to the game. I can see very clearly learning one of these engines will get me there quicker. Sure the first time there will be learning curve but after I'm quite sure I'll be much more productive.
My point is, why do I have to use their dopey editor to get at it? Why aren't these things libraries, dependencies that I manage just like any other project I've built since the dawn of time?
For Unity, I can definitely see the appeal of a good "game builder" type application. Game builders have been around forever. Traditionally, game builders were crap, so to see Unity create something that can be used to make games that people are selling, for real money, is pretty cool. Unity was never going to be my cup of tea, but that's fine.
But for UE4, Epic has been a long-time vendor of AAA-quality game engines. I expected a series of libraries for doing the vast majority of things, plus workflow tools for things like baking lighting into textures. That's what I mean about "what ever happened to writing code?" The way you used to wire up a game engine with your models and your gameplay scripts was to write code, not draw boxes in a flowchart editor. Command-line oriented build tools for processing scripts and packing textures and encoding audio and cross compiling could be abstracted through a GUI, but were still available to plunk down on a build server so you weren't wasting cycles on your workstation. I still get the feeling that that is in there somewhere. But where? I just can't imagine a professional game dev house using the UE4 editor.
Why not?
Most AAA games are done by designers, with developers just providing the engine tools for them to create the game content.
https://www.flickr.com/photos/vasiljevich/17906407432/
https://www.flickr.com/photos/vasiljevich/17921228474/
https://www.flickr.com/photos/vasiljevich/17344409903/
https://www.flickr.com/photos/marcelus_sk/17506176714/
https://www.flickr.com/photos/71866538@N04/17890196732/
https://www.flickr.com/photos/100603905@N03/18175649019/
https://www.flickr.com/photos/wakeupmrfreeman/18058537158/
https://www.flickr.com/photos/71866538@N04/18032189865/
http://www.gamersyde.com/hqstream_the_witcher_3_wild_hunt_la...
Screenshots and videos don't do it justice, you have to see it in motion, with sound effects, real-time uncompressed, with things moving in the wind, full of animals, changing daylight and weather.
Search for "$GAME lets play". Filter for "playlist". Watch.
Divinity: https://www.youtube.com/playlist?list=PLKUZkQKe2mplbFbec0rFz...
Witcher: https://www.youtube.com/watch?v=yuQirEnvqkU&list=PLj_Goi54wf...
This is madness!
A tech workers' union means not only the mandatory imposition of dues (don't need any more little cuts out of my paycheck), fixed hiring qualifications that are pretty likely to evolve into full-blown licensing (i.e., the end of the self-taught professional), removal of the right to independently negotiate, and affirmative action, but also a large, opaque body that engages primarily in political activities like lobbying and negotiations with very little oversight or transparency.
The benefits of a union are protection from predatory employment policies. That may be necessary in some fields, but in programming, it isn't. Most devs I know can have a new job within a few weeks if they don't like their employers' policies, and most employers I know appreciate the difficulty in sourcing good software talent so they don't want to do much to piss them off.
Here's some more links about him, if the one above doesn't make the point clearly enough:
- http://www.sourcewatch.org/index.php?title=Rick_Berman
- http://usatoday30.usatoday.com/money/companies/2006-07-31-lo...
- http://www.cbsnews.com/news/meet-rick-berman-aka-dr-evil/
- http://www.nytimes.com/2010/06/18/us/politics/18berman.html?...
You know, just FYI.
The former is an aspect of personal freedom, the latter is evidence of market failure and possible exploitation.
On the bright (?) side, the bonuses are epic (hee hee).
Given the well documented case where certain California based tech companies used their combined leverage to hold wages down (through the non-poaching pact) I would say that your view of the leverage of employees over employers is overly optimistic. (i.e. http://www.macrumors.com/2015/03/03/anti-poaching-lawsuit-41...)
If employers gang up against non-unionized employees I would say it is obvious who has the short end of the stick.
There are areas in tech where your statement may hold true, and superstar performers usually hold more cards at the negotiation table than employers do but for the general software engineering populace it's not as clear cut as that.
There are other ways of reducing turnover, such as finding whatever would convince your key employees to leave and offering it to them to stay before they get that offer from a competitor.
It's certainly true that blanket no-poach agreements can help an employer reduce turnover without making the employees lives any better, but that's part of the reason they artificially restrict wages and are unfair.
My understanding is that the no-poach agreements forbade only unsolicited pursual of employed individuals. Dissatisfied employees were still free to seek employment at the other competitors. All these agreements did was keep others from fomenting discontent by dangling carrots in front of potential employees (which would've been unlikely to be fulfilled). It was a voluntary arrangement entered into by the industry's recruiters. I don't think there's anything wrong with that.
http://www.scribd.com/doc/78818102/TechCrunch-High-Tech-Empl...
> The documents also demonstrate that Defendants did not extend an offer to an employee of another Defendant without prior approval from the candidate's current employer, regardless of whether the candidate applied without being solicited first.
It's also obvious from now public emails that many of the employers knew that these agreements were probably illegal, with Google explicitly saying internally that they didn't want to create a paper trail that they could be sued over, and Palm flat out telling Jobs that his suggestion was probably illegal.
Michael Capps is Epic president, and he ended admitting he joined IGDA board in first place to stop IGDA from forcing studio hands in fighting crunch, when Capps joined, IGDA most high profile work was to try to fix the crunch culture, Epic felt threatened, and pulled that stunt (send Capps to join IGDA and undermine the efforts against crunch)
(Thank god I got out of that industry)
C++ is far from perfect, however: What else? I can't think of any other language this project could realistically operate as efficiently in between suitability, availability, tooling and talent pool.
A big problem has been the C mentality that has prevented the existence of frameworks at the same level of .NET and JVM, although the language is quite capable.
This has been mostly caused by the language support level across compilers/platforms and the need to write portable code.
Now modules are a TS post C++17, :( .
2. Not related to the update, but was wondering what do people who have worked with UI frameworks in C++ (i'm not one of them) think about Unreal's Slate UI Framework. Seems pretty slick to me (Coming from web dev and win forms) and highly customizable, though rather verbose.
good:
- You can debug everything.
- If you dont know how something works, you can step into the source and see right away (unlike unity, where performance issues are a mystery).
- Its really pretty.
- The material editor is powerful and amazing.
bad:
- Everything else.
- Compiling C++ of a small project for a single file change can take 20 seconds.
- C++ should be fast right? This engine is slow as balls on every platform without a brand new graphics card and cpu. The reflection system, GC and blueprint interaction is powerful...but speed was a major disappointment for me. Use on next gen consoles only.
- Poor cross platform support. Hot reload (ie. reload the DLL with your project code in it while the editor is open) works on windows and 'kind of' on other platforms; and not with plugins (that means if you change a C++ file you have to restart the editor). Some features (eg. 2d physics with box2d) are only implemented on windows; there no way of telling what is implemented for what platform short of reading the engine source.
- Integration of 3rd party C++ libs should be the killer feature... but its not. The build toolchain (UBT) requires every header file to have the same first include. Rtti and exceptions are disabled by the build tool. Fork fork fork, edit edit edit. Dynamic linking and runtime DLL loading should work, but it doesnt (everyone just links to .lib files, see point above...).
- There are plenty of other little annoyances, but probably the only really major one is building a 'production' target. The build toolchain is a massive sprawling mess of C# code (yes, all the UE4 build scripts are C#), which often obscure linker and compiler flags dropped in via command line arguments (but only from that platform) or hardcoded. ...but if you change any of the UBT source code to customize your build, or even add some debug logging... you have to rebuild the entire engine from source, which can take 40ish minutes.
To be fair, if all you use is visual blueprints and you never have to do a build, you miss a lot of these pain points. For designers, its great.
There's a lot of love out there for building things using blueprints; but someone has to do the hard work of the low level C++ to support that.
... if you work with this engine as a developer, you have my sympathy.
Hit up #unrealengine on freenode. At least you'll have the rest of us to cry along side with.
However what is you opinion about being able to use C++, eventually C++14, versus the C# 3.5 Unity keeps on using?
Just curious.
The old runtime unity uses, despite using newer class libraries and so on from the open source C# stuff from microsoft... well, its terrible. I mean, its usable, but its like C# lite, with none of the features or optimizations from you know, the past 5 years.
C++11 in UE4 is hands down better. C++14 will be even better.
...but their tooling sucks at the moment. Right now, despite the unity runtime, its still a better system to work with as a developer.
In the future, who knows?
Maybe unity will use a new version of C#? (deeply unlikely)
Maybe the UE4 tooling will improve a lot? (very likely)
My advice is 'watch this space'; the UE4 engine has great potential, but right now, despite the good parts, the bad parts are so bad I couldn't recommend using it professionally.
...but hey. Thats just my oppinion. Its free. Download it and try it for yourself. If nothing else, the code is a facinating read in C++ learning.
I am quite comfortable with both languages, just lack the time to do anything and was curious about the experience from someone about both engines.
I do share your opinion.
Actually they will upgrade Mono when IL2CPP is stable enough.
http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...
Well, yes. Now you can actually build for ios and android, which wasn't possible before with modifying the UBT and sacrificing 3 goats.
However, its still no real improvement in workflow or speed.
Or maybe you mean the tool that lets you rewrite your miserable failure with no kills and make it look like you won the match with no deaths.
Replay is usually as easy as just timestamping packets(or storing input if you're running a lockstep sim) and playing it back when viewing the replay.
I was very wary of Blueprints, but after playing a bit and seeing just how they work, I was sold. Same with using C++ natively; it seems daunting, but you're calling the same methods your Blueprints do, it's almost drop-in easy.
Definitely it's gonna need to make some progress, but the gap is closing.
I imagine this will gradually improve, but for now it's really not an appropriate engine for that class of games. Anything from LÖVE to Unity works much better.
We got some pretty complicated HTML/JS/CSS up and running and nicely integrated (js talking to blueprints and vice-versa) in under 30mins. It's fully backed by Epic now through a grant.
It handles video and audio nicely as well. There's little reason to consider using the inbuilt UI stuff when it's so easy to leverage existing HTML skills to build it out.
A few of us from the Valve development community, EA, and Blizzard wrote this as a side project.
http://www.andrewmcwatters.com/grid/ https://github.com/Planimeter/grid-sdk
Does it support cross-platform releases to consoles, mobile, and PCs?
LÖVE's team moves really slowly though, and we release updates on about a weekly basis. We'd eventually like to move off of them but keep a similar framework API for people to migrate away from.
Some high profile games that haven't shipped yet include Fable Legends, and the new Gears of War from Microsoft, Flood in the Flame, Street Fighter V, Tekken 7 and Eve Valkyrie. Epic is working on at least two games, the open source community driven Unreal Tournament and Fortnite. It's pretty successful for an engine that has only been widely available for a little over a year.
Wikipedia article with full list of notable games (http://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Unr...)
To be fair; if you're not a AAA developer with a good team running a multi-year cycle, I'd be pretty hesitant to recommend UE4 for a project right now.
I use Unigine instead. It's absolutely great. Rough edges but it looks great and is easy to use.