Am I the only one who finds massive friction trying to learn the heavy GUI editors of both Unity and UE? I've been a hobbiest game programmer for 15 years, I studied computer graphics in college, I could probably write a software rasterizer in my sleep. I've been using Blender for quite some time, even in some semi-professional work. I've lead numerous projects from start to finish in all kinds of industries, including a few in raw, physical simulation. I've even built my own video game controllers.
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?
I make games for a living and for a hobby and the switch to Unity in both contexts has been painful for all the reasons you mention. A foreign and often confusing UI, arcane and undocumented interfaces (at least UE4 has source), and tutorials that assume you don't know how to read. The last point has been especially frustrating because what takes 45 minutes to learn from a video tutorial I could accomplish through reading in five.
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.
> tutorials that assume you don't know how to read. The last point has been especially frustrating because what takes 45 minutes to learn from a video tutorial I could accomplish through reading in five.
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.
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.
I feel the technical debt is in UE's court. They're an engine designed for 100+ person teams where they assume you're a AAA developer and have lots of programmers to support your artists/designers.
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
I'm old school like you? I've been programming since TRS-80/Apple II,Atari 800 days.
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.
No, I'm not really talking about not-implemented-here-syndrome. Yes, you are right, all of those things can be fun to write for fun's sake, but I agree that it's stupid to try to write all of that yourself if your goal is to be productive and complete a game.
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.
... and those designers are beginners who A) can't read, and B) don't have years of practice in industry-grade tools and techniques? If anything, replacing something like 3DS-Max or Maya in the workflow is probably harder than replacing a code editor. And there are several other disciplines than 3D modeling involved.
That's because these tools are targeted at content builders not developers.
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'm happy to see an emphasis on grass and foliage systems for open worlds. I have a soft spot for open worlds after discovering Morrowind in my teens. I don't think I completed more than a couple main quest items; just snuck and thieved my way to god status /nostalgia
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.
The best way to look into such games imho is to watch a Youtube Lets Play and jump a few episodes in. Official gameplay videos by the producer usually show Best Of scenes, which does hide the boring parts.
Search for "$GAME lets play". Filter for "playlist". Watch.
What is the size of their team? How do they operate to produce so many features / fix every release? Larger team usually have tons of issues in terms of individual efficiency. This is clearly not the case. And this is all C++??
We don't need unions. There are plenty of non-evil employers in the tech space. If an employee doesn't like the way his employer is run, he is free and generally very able to go find another employer. Unions are a nightmare that we don't want or need in an in-demand field like software.
"Unions are a nightmare that we don't want or need in an in-demand field like software."
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.
I've actually defended Catmull et al for that "cartel" so unfortunately it's not very convincing to me. I see the no-poach agreements as a) not universally applicable in either terms or employers, so not seriously limiting employee mobility, and b) critical to minimizing turnover and successfully managing a long-term project like a CGI movie. The prosecution of the companies involved in this "cartel" is politically motivated.
> critical to minimizing turnover and successfully managing a long-term project like a CGI movie
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.
The employees' lives are made better by consistent and stable employment, which can't be achieved if the company has turnover so disruptive that it can't successfully release a product. Even if companies were be able to thrive by constantly outbidding each other and taking one anothers' employees, the employees would be unhappy (most people desire a reasonable degree of continuity in their employment).
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.
> 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.
> 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.
You're conflating the tech industry with the video game industry. Not all unions are a nightmare, they're there for employee protection. If you specifically are in a privileged enough position to not need a union, you have still benefited from the existence of them.
That is certainly one perspective, and this may come as a shock to you, but there are those that argue unions are not a universal good. [0]
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.
The "Center for Union Facts," to which you linked, is one of a large number of sites operated by Richard Berman (https://en.wikipedia.org/wiki/Richard_Berman), a P.R. guy who has made a very lucrative business hiring his firm out to corporations and industry interest groups to set up astroturf "citizens' groups" opposing anything and everything that would cost them money. This includes not just unions, but minimum wage increases (on behalf of the restaurant industry), restrictions on indoor smoking (on behalf of the tobacco industry), drunk driving laws (on behalf of the alcohol industry), programs to reduce childhood obesity (on behalf of the soda industry), and lots more.
Here's some more links about him, if the one above doesn't make the point clearly enough:
There is a salient difference between working in long hours in tough conditions with appropriate compensation (e.g. offshore oil and gas), and working long hours in tough conditions without appropriate compensation (the video game industry).
The former is an aspect of personal freedom, the latter is evidence of market failure and possible exploitation.
I think to everybody in IT it's pretty clear that video game industry is full of exploitation and it's rather rule than exception. That's why very few stay in industry for long, the disappointment from daily reality is a bit too much. Especially when other variants of same work can be (almost) as much fun, and they treat you like human being actually, with perks and more time to actually live your life.
If you live in Raleigh and want to work in games, you really don't have many options. Hate the hours imposed? Well, pack up the house, say goodbye to family&friends, take the kids out of school and move across the country. Sounds like a good option, right?
On the bright (?) side, the bonuses are epic (hee hee).
Games are always going to be that way. There is too much glamor associated with the industry. Whenever someone graduates from a bad games company into a "boring" business job, there are 10 more new grads begging to take his place. A union cannot change the underlying market fundamentals. Desperation guarantees an atmosphere of exploitation; the only thing that would change is that the union directors would get their cut of the proceeds from the exploitative labor practices they'd help enshrine.
I would imagine the crunch is significantly lower on a game engine as opposed to a game where you are usually contractually obligated with your publisher to release a final product on a specific date.
Dunno if what he said is true or not, but when I was a member of IGDA, I left after the board refused to kick out Tim Langdell (that is a trademark troll) and Michael Capps.
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)
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.
C++ without C copy-paste compatibility warts can be quite good.
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.
Same here. Tribes 1 was one the best games I've played, to date. It was extremely fast paced, had an amazing team dynamic, and the character movement (skiing and flying) was beautiful. I haven't found anything comparable since.
Projectile physics were one of my favorite points (besides the open environment). You had to be aware of your own motion vector if you wanted to accurately place a shot with most weapons. Sadly, later installments (T:V, I'm looking at you) never quite had that same feeling. That was probably part of what made it relatively unfriendly to newbies from other shooters, but I felt it made the game a bit more intense and required a bit more focus rather than strictly mindless button-mashing.
Didn't they have a weird compromise in terms of projectile physics and the player's motion? I remember reading about it and thinking that doing so would make it harder to use than doing it physically accurately but I forget the details.
Tribes 2 was pretty crap when it came out but the Classic mod gave it much the same feel as Tribes 1. I lost several years to the competitive scene. There were organized competitions as recent as a year or 2 back, and there is still a public server with enough of a population to play at most times.
I can see it happening, I've even given it some thought. I have a feeling as more and more resources start appearing that are UE4 specific, we'll start seeing some really cool revivals like that. Right now, a huge portion of the community is still in Unity, we're only just now starting to see documentation and videos really coming out strong (probably fueled by UE4 dropping the subscription fee).
The skiing physics are hard to get right. No Tribes sequel has replicated it out of the box - it took several iterations of mods to get it right in Tribes 2, and Vengeance/Ascend were pretty garbage imo
T:A is the game which is being left to rot. Devlopment has been abandoned, the community ignored, and the game heavily incomplete. Management, when it existed, was incompetent.
Amen to that. And hopefully in a traditional standalone, non-free-to-play/non-MMO format. Just take my money and give me the ability to set up my own servers and mod the game.
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.
I've spent a fair amount of time with UE4 now, and there is good... and bad.
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.
Modern C# is a powerful and compelling language; C# vs. C++ on that front is an open debate... one the internet has a great number of easily found topics on.
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.
Is their story on mobile deployment any better yet? I switched off of Unreal Engine because it required overly beefy phones, outrageous download sizes, and slurped down huge amounts of battery, even for something trivial like Tappy Chicken. Is this situation getting better yet? Is Unreal Engine a good choice yet for someone focused on mobile deployments?
Scrolling back and forth through time, rather than a spatial axis, and sometimes also with the ability to pause at arbitrary places. I usually see that usage in the context of video editing.
The time bar and "current location" elements of a video player are commonly called the "scrubber". Thus, when you record multiplayer video, you have full control over playback.
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.
I don't think that's quite true yet. While I vastly prefer UE4 to Unity (and would recommend UE4 in most cases), it would be a mistake to underestimate the value of the huge amount of paid and free content that exists for Unity. Furthermore, UE4 gives the option of Blueprints (which many find insufficient or clumsy) or C++ (which can be very intimidating). UnityScript/C#/Boo sit between the two, making it preferable for those who want to write actual code, but don't want to deal with C. Furthermore, UE4 is still very developing expected features. Until 4.8, you couldn't do SSR on translucents, couldn't do graphics profiling on OS X, and couldn't switch splinesmeshes from being open to closed without corrupting your maps, etc. I love UE4, but it's still got a lot of ground to cover.
You're absolutely right about the content and tutorials available for Unity, that's a humongous boon. But that's a gap that will rapidly close, especially after UE4 dropped the subscriptions.
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.
If you're just doing 2D, it's really bloated and clunky. The UI stuff isn't great either.
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.
For UI you really should check out BLUi. It's free and beats the commercial offering from Coherent in our experience.
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.
Grid is suppose to be a lightweight engine solution on top of LÖVE as it's framework. I feel that Unity is comparable to UE4 as far as 2D games go: overkill. LÖVE doesn't solve any boilerplate issues for you, and you end up reinventing the wheel.
A few of us from the Valve development community, EA, and Blizzard wrote this as a side project.
Yes to Macs. Cross-platform is something we'd like to work out, but we end up pestering the LÖVE team to implement underlying framework changes.
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.
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.
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?