A different perspective on Unity development.!

GetLocalCorners()/GetWorldCorners()?

But yeah, getting position relative to a grandparent was a bit tricky... then again, you can just write a function for that. Once.

 

Evolve and adapt. Nothing is perfect. A rock can be used like a hammer. A butterknife a slot screwdriver. It makes more sense to use the right tool for the job. Unity is one tool system, Unreal is another, and so on. No matter what tools you will ever use, there are drawbacks and compromises, trading size for power, trading universality for specialization, trading ease of use for flexibility... but only a loser blames his tools when he F***s up the job.

 

Sorry about that operation mate. I didn't mean to take your balls off but I only had a shovel to work with.

 

Or my variation on that...

"What you want a hole and we can use Unity shovels, they are great for gardening but an olympic swimming pool?"

Don't blame your tools.

"But if the Unity shovel worked with the SIMD parallel multi-threaded digging system out of the box it would take a fraction of the time?"

No.

"What about the Gardening Professionals Universal Autobots system or GPU'a for short if the Unity shovel could plug into their toolchain you would have the job done today?"

No.

No just a Unity Shovel, but I can engineer and build my own add ons if I want!

Yes.

Will you pay for that as well as the pool?

No.

And what about the Garbage collection system, that can really slow down big jobs, can I...?

No.

I get it don't blame your tools, because as a landscape gardener I also need to be a tool system engineer, is the Unity shovel open source?

No.

 

We don't to 2d. All 3D. But yea, we don't have time deal with problems or wait for an engine fix, so we solve it and keep building. For example light maps: Maya/Max, including uv generation. Physics are mix, they need to accurate and cheap, so a bit custom and built in for the trivial stuff. All custom shaders. Stuff like that.

Also, we haven't had source access for about 4 years. We had an SLA for an ill fated unity/flash project, but that was the last time. Honestly, as I recall, it was a bit of a pain.

 

Q: Team size?
Q: Any Physicists/Engineers?

 

...It's not the shovels fault you selected it for a task it was clearly not intended for. And furthermore, for every "it can't be done" combination of tools and tasks you can think of, there's some smarmy old dude puttering around someplace who used to do ball surgeries with shovels every day.

We didn't evolve these magnificent hands so that people would have something to throw in the air when they run into something challenging.

 

As noted in the previous ~50 per game team.
Plenty of engineers of different varieties, no physicists (well, one a while ago, but he was a shader guy). But a folks who are experts in game physics.

 

Now... writing to those values reliably regardless of parent, pivot, or anchors without changing those values.
Now... writing to those values relative to world space, local space, etc...

It can all be done, yes, but it's way more of a pain in the ass than it should be. Which is why the layout managers just override all the settings and supply consistent values to all the crap they manage.

 

So what have you done with the tool you've chosen? The whole "blame the artist not the tools" thing is fine if you've got an eternity to work with. In reality its a S*** analogy that never, ever works outside of hobbyists.

Fact is the AAA games of today can't be done without *good* tools. You'd need to raise costs, hire far more staff and so on. They would cost at least 10 times more with basic tools. Can be done - technically? yes. Can be done realistically? no.

Basically there is a tool for each job, even if you have to make the tool. Need a hole? use 10 men OR one guy with pneumatic drill.

There's a lot of fun sayings that sort of seem wise and so on but the truth is better tools allow much faster work - regardless of talent. Last I checked there's a lot of small teams around here, and the majority are probably running solo.

 

So @zombiegorilla what are all of these people doing? I know in game dev teams seem to go up to 100 or more (based on all the names showing on game credits) but ya know 50 people... it just seems like a huge amount of people. Especially working on projects that take years. For example there is a crew of 7 guys around here who build an entire (big & fancy) house from scratch (leveling the ground, laying foundation, finished basement and all) easily within 5 months if weather cooperates.

Obviously different industries and all but I often think something is very strange that game dev takes so many people and years on top of that. And even then we often see games coming out unfinished and riddled with bugs. Just going by my own work I think geesh just having 1 to 2 more people doing the same stuff every day (well more like divided up into subject areas) would be a huge boost.

Are these people all actually working hard every day or do they sort of swap in and out of active work? Or does the project just change continually throughout development and this is what causes so much work to be required?

 

I think you probably are severely underestimating how much work goes into making a game. Yes it is more work than building a house. A house sounds impressive: It's 3D. It's real! it's there. But... its STILL far less work than building a medium sized game. Don't get physical labour mixed up with time-based effort.

I mean check out how many people finish games around here

And:

The house analogy only holds true if the house is also fully decorated and you had to make all the furniture and kitchen appliances, plumbing, water, electric, heating, carpets, curtains, maybe even the TV (although that would probably come under middleware)

 

Selecting the right tool for the job is the first step of an expert. If Unity is not the right tool for what you're doing, and you're using it, why are you doing that?

Let's not divorce cause and effect here and fire the up the old excuse generator. I have F***ed up. I blew apart a urinal with a power drill... shouldn't have been doing what I was doing. I've seen people cut their hands open because they held a tool wrong that I have used for a decade... and then say, "That tool is unsafe."

Operator error. Selection of tool, operation of tool... it's all on you. Not recognizing this is what keeps people from becoming true craftsmen.

 

Roasted

 

I get that and I am in software development (non-game) professionally. And I personally get a lot done at work as do others. And then you look and see these games out there made by only 1 person. And it seems like if they were able to focus only on the programming and let someone else handle graphics, music and sounds for example imagine how much more they could have accomplished in the same time.

However if the project is constantly changing.... sort of being prototyped for a year just to figure out what exactly the design really is that explains a big part of it. Also I wonder how much time coordination, meetings and so forth takes up with so many folks involved.

 

Gar, you're software engineer, aren't you? You should know how it works.

Building a game is not making a house. It is making a movie backdrop, costumes and props for every single actor.
So, in addition to classic programming issues ("we need to implement a feature that doesn't fit into our object model"), the main source of expenses will be artistic cost.

Take a look at something like GTA5 and think about how someone painted every single advertising in the game. Or, take a look at skyrim, then go read bethesda's article about modular building and realize that all dungeons were built pretty much by 10 people (the whole team is 100).

It is essentially making a worlds full of puppets. Then building a clockwork mechanism to control every single puppet so the whole thing look real.

 

Don't you kind of get the feeling that our opinions (as in mine and your's) are slightly null and void in this context? If we have an issue, we'll throw money at the company for enterprise support and scream at them until they sort their crap out. Or use the experience in the team to completely replace / upgrade a system, if we get delayed six months cause of it **** it.. Doesn't matter there's plenty of money so why should we care?

If no engine actually existed, couldn't care less.. I only need VS and Maya..!

From what I see, for a stereotypical "actually hard working" indie that's not how things work.. They have deadlines from console manufacturers which are funded, they probably don't have the man power or finances to keep hitting issues / developing tools etc. which it's a shame because some small team indie's make damn good games, far better than some of the stuff AAA comes out with. With competition today, they need more robust integral first party features to help them along..

It seems to be a common occurance that people can't handle engine's like Unreal and that's nothing to be ashamed of (Even if they are making it easier all the time). There's been plenty of decent games released (mainly from Unity funnily enough) where it's obvious the dev wasn't quite sure what a "shader" was / is. This is the WHOLE problem, it's all extremely biased to YOUR situation.. Nobody can really say across the board that Unity / Unreal / CE is good or bad, it's either good or bad for THEIR circumstances.

Just as a side note have you ever been actually involved in a complex 3D game? I'm talking more along the lines of Eve Online who used Unity and dumped it like a hot rock.. They aren't N00b's, they have released other great games and the Unreal version they showed was fantastic. I perfectly understand why they moved, the real question is why did they use Unity in the first place? (Yes I know, you already said select the right tool for the job yada yada!)..!

 

@neginfinity yeah I get that too. I guess I just always question whether this stuff can be streamlined. Like is all of this effort really necessary? Again it goes back to seeing what a lone dev can accomplish in their spare time. There just seems to be a massive gap in my mind between what one person working spare time has accomplished and what a team of 50 to 100 people (full-time) are accomplishing. Obviously the latter is bigger and more polished but it just seems like that original lone dev if they had say 3 to 5 people as skilled as they were could match or even blow away the efforts of the 50 to 100 person teams. Well except for raw quantity. That is a challenge the sheer amount of content the AAA games have.

This is what a single person (college student) has been able to accomplish so far part-time while in college: "Hero"






Part-time. College student just learning game dev.

 

I believe it was an in house prototype / proof of concept / playtest, their way to goof off from supporting a massive MMO.

 

You can argue with me, but the truth is not me. Whomping on me != whomping on the truth.

I am just speaking in generalities, because in principle things work a certain way, and that cuts across all barriers.

You can't nullify the validity of what I am preaching because you disqualify me as an expert in whatever particular line of work you're currently involved in. Conversely, by fluffing yourself up to be a pro you increase people's expectations and it leaves the question about why are you having problems if you're supposed to know what you're doing?

In the end, I think it's best to just not complain in general, because the complaining gets contentious and leads to S*** storms. Complaining is sort of a source of bad juju.

All I am saying is don't get mad at Unity if it isn't working out, regardless. Step back and reevaluate why this bad stuff is happening. Try to fix it.

Again, you can mock me all day, and maybe I will get sick and die and never finish a great game or something insane like that. Or maybe I will never make a great game because I suck. But there's no excuses on my part, I am a naked failure, been too lazy and unmotivated and haven't done the work to get the results.

So beat me down all you want. But when I'm just a little pile of mush on the floor, who will the new "devil" be in the new predominate zeitgeist?

Never self. Always someone else.

Edit: I am not hiding anything, not pretending to be somebody whom I am not.

 

It is around 50, (or more accurately, that is the target). The current game I am on, was around that or a little higher for the bulk of production, and into live ops for the first year. After that we had some "quality of life" time that we got to go back and optimize the pipeline and release process. That reduced our team size a lot though automation of common tasks, and less grey areas. But since these are live games, even after being live for two years, we are constantly adding huge features which require full development. (We just released squad wars, which was 8 months in the making.) Launching an live game like the ones me make, is just the start. The real work starts once it is the players hands. These type of games are actually fairly complex, must constantly evolve/grow and have a ton of content and moving parts.

That number reflects engineers(front/back)/artists/ui/ta/fx/animation/product/design/producers and community management. IT/BI/Marketing/techops/audio and other resources like that are separate teams, and shared across teams.

The actual number will fluctuate a bit, for example, our art team was much larger prior to launch, but still about a dozen folks. But yea, everyone is actually working hard every day. Some more than others depending what is actually being done, and depending on role. TAs are always busy (we have 5... for now). UI is always very busy. Some roles like animators, not so much on a live game, but there is always something for them to do, and we try to share people when possible. Often the teams will grow heavily during geo-beta, launch. It becomes sort of all-hands-on-deck mode when a team is in launch mode, and many of us provide assistance to support that team.

Also as a note, typically game credits don't list outsourced work, which a lot use. There are tons of studios that are very successful from doing nothing but outsourcing to other companies. A buddy of mine was the character lead on torchlight, and they had tons of outsourced art, it was a big part of his job to manage that, but you don't see that reflected on the credits. Even we use outsource art teams on occasion as well when there is a time crunch.

 

@zombiegorilla thanks for that detailed reply. Now that is a very different and more reasonable picture. You're saying the actual game up to release point is completed within 8 months to 1 year. Then of course you add more content, new features, bug fixes etc after. But 8 months to 1 year is differrent from the 3, 4 and even 6 or more years I've read for other AAA games with a large number of people and they were saying that was just to get to release point.

 

Looks like a part time college student devving in his spare time with some knowledge of lighting created this and not too much about how that affects vegetation. Objects and structures are not unique. Tree leaves are obviously planes. Grass textures are too bright green especially in the golden image up top where the grass would have picked up the gold amber color. Shadows too dark in lowest image. Tree trunk bark looks smooth with no surface texture.

 

Okay, since apparently this thread isu all about perspectives on Unity, allow me to do what I do best and apply intuition, thoughtful consideration and perception into the situation between Unity and Indie Developers.

They don't need us. They don't want us. We helped them to become what they are, and now they have become something bigger and more powerful than anyone ever anticipated.

For God's sake Blizzard is among their clients.

It is not the goal of unity Technologies to make the most independent developer-friendly tool Suite on the market. Their goal is that you can develop your game in one place and publish to multiple platforms. They are the Undisputed god-king Xerxes of mobile. And you are but the 300 Spartans making your final stand.

In short, you should probably write your own engine rather than complain about Unity because it will be more effective and in the long run better for you anyway.

So there, the pseudo sage has rambled. Ignore my words at your own rotflmao.

 

For a game world I think it looks very nice. But that as from a gamer perspective not an artist of course. I still need to track down the demo. I looked last night and didn't find it. Gonna search on itch.io tonight and it should turn up. I just want to see how much of the actual game he has in there.

 

I am Leonidas mocking Xerxes. I say we build a wall of corspes of the corporate coders and CompSci male member wavers in their 900 strong army and collapse it onto Ricotello.

 

Well, the context of this thread was large teams using Unity... so, yea it is totally on point. Unity is helpful, and on very rare occasion supported us with a custom build, but typically, we face all the same issues that anyone else using unity does. But we do have long and deep experience using it, and building games in general, so we focus on finding long term sustainable solutions if we hit a wall. We can't trust that Unity will fix issues in a timely manner or in a way that works for us. Delays aren't really an option for us anymore, most of our launch dates are set before the game is greenlit, and usually coincide with an external date. (usually a movie).

Yes, several, very complex, here and other places. Only a couple in Unity (prior ones, both here and elsewhere were custom engines). Even the current game I have out, (SWC) is a very complex game. More accurately, it was one of the most complex of its type when built, almost 3 years ago. No one was doing 3d in CoC type game, and for good reason. There were tons of shortcuts and tricks required to get it to run at all on the supported devices of its time. Now, it isn't a problem, and we are slowly giving it an HD refresh to leverage the quality improvements. Our current development titles are easily console quality, and have much more room to breath.

 

Look, I can spot prefab placements at a glance and see repeated patterns, immediately.
Also, I think some of saurbraten maps were prettier: http://sauerbraten.sourceforge.net/screenshots.html

If you want nice games made by small teams, check out Dear Esther and Miasmata.

 

1-2 years or more is more accurate. SWC was fast at 1.5 years from production to launch, but there was still several months before that going through greenlight and exploration. My upcoming game spent well over a year in exploration and greenlight phase, and is still a couple of years out. Usually the GDD contains the complete game over several years.

Many features are pushed to later releases for a few reasons. The first release is somewhat of a MVP in terms of core game play. Basically, other features are pointless if the core game doesn't fly. By having a plan, even if we aren't currently launching with a feature, it is kept in mind while building the game so the code and pipeline are friendly to it. But that lets us nail down and refine core gameplay. It also means if the game tanks, we didn't have to eat the costs of those features. But the big part of it is retention and player expectation. Live games like ours (mobile midcore), are expected to have constant updates by players, our competition does it, if we don't, we quickly lose interest of the players. And, even a massive feature update is much cheaper than new game. Especially on a successful game. We know that work is going directly in front of several million daily players (again, more effective than marketing a new game).

A console title, (though this is changing as well), needs to be pretty full featured at launch, they have to bring the big game to get the initial sales, that is where their revenue comes from. Similar to our market, their competition is always releasing more and more content at launch, they have to keep pace. In our space, there is no initial sale, we have to make the core game as enjoyable and as engaging as possible right out of the gate. Tons of content/features at launch means nothing if the main game is no fun. Assuming the game does well, we go into constant release of new content, usually 1 or 2 week cycles with larger releases in the background. This is also means that we can actually interact with players, see how they are playing and what interests them, so new is content is based on what the player actually want. When we do build something directly suggested by a player, we make sure they know it. It creates a really strong and active player base, and a better game.

Also, the platform lifecycle is much shorter (and not in sync) on devices. A console game can spend many years building toward a relatively known target. In mobile, about 3 years seems to be tipping point. If a game is in development that long, it may run the risk of being out of date at launch. Plus delays come more often, having to deal with hardware/software changes. As a large team, that is one of the biggest benefits for us using Unity, they handle (mostly) all that platform crap. When we had internal engines, so much effort was put into keep them deployable on our target platforms, that actual engine features were really slow.

One last note, for us specifically, we have an incredibly high bar in terms of visual quality and story. Those parts must meet the standards set by the folks responsible for the IP. So there is often a fair amount of iterative time related to that (both internally and externally). LucasFilm is pretty easy to work with, they are usually very clear. Marvel, a little more... challenging. But those exchanges, discussions and approvals, take more time than where the IP is part of the studio itself. (crystal for example, though a big IP, wasn't as much of a challenge because that IP was internal to the game studio).

 

I don't think that is true. (or more accurately, I hope it isn't) Unity certainly became what it is today because of it being available for hobbyist and small teams. Many years back, we weren't even considering using it, but more of us (individual developers) were become excited about using it, and started really pitching it internally... because we had access and interest in it outside the studio. But beyond that, there are several larger studios doing well today that were from that indy/hobbyist base that Unity built up. Unity's success is from that market, though it may make more from enterprise (or not, dunno), it wouldn't have got there without the path that they took. Disengaging from that market would not be a good thing.

 

@zombiegorilla "over a year in exploration" ... aha! So you do spend a lot of time just on prototyping trying out things just to figure out exactly what you want to build for scope, visual direction etc! If I understand what you mean by "exploration".

 

Yes, that is exactly what I mean. We choose the games we build, so we do a lot of prototyping and exploration before we pitch for a greenlight. My upcoming project was over a year in that state, and was around 17 complete game types/styles/genres before it landed on something that was great and had a solid market. We spend a lot of time doing that because when we commit to a game, a lot of resources and support is put behind it, we can't pivot later in production.

 

Second result on Google when searching for his pseudoname. It's $3.99.

https://bakershah.itch.io/hero-

 

Smart@$$! lol Thanks!

 

It happen to us. We use Unity mostly as a big level editor and to manage data. We have a custom renderer because we needed faster way to render multiple lights and shadows in one pass, don't use Physics that much (we are fine with simple collisions, we don't need physics simulations) and got stuck with the legacy animation system because of multiple mecanim issues.
Sadly, I'm not aware of any other library that let us target multiple platforms and gives us a bit of flexibility in the rendering department as Unity. It's hard to get rid of Unity.

 

Well it's funny how valve get 18 lights in forward at faster performance, single pass.

 

Keep an eye on Xenko. We (obviously) have been looking at Unity alternatives since the licensing change and while it is not as full featured at the moment as Unity, its open-source and everything is written in C# except the graphics libraries and some iOS library stuff, and even then for the actual engine its all C#... even when its creating the graphics device, for instance.

 

Depends on what those "multiple platforms" are. Some C++ framework could be a good idea, and something like Qt/libsdl will allow you to target major desktop systems.

IT is also apparently now possible to compile C++ into bytecode (via clang/llvm IR - see "emscripten").

Speaking of which, did anyone mention GC yet? I mean, mobile platforms + GC + no "delete" in the language == fun.

 

Haven't heard of Xenko before. Looks interesting. They even have lightmapping scheduled for September.

 

They used to be a part of Silicon Graphics... for those of us old enough to know who Silicon Graphics was and how important they were.

They have a separate renderer product as well as optical effects middleware - go take a look at those demos and prepare to drool

 

It will be interesting to hear what you discover. Going just from the videos, there isn't much there at all. Just based on the videos, that is about an afternoon's worth of work, tops. Maybe another day to layout the city. But all the content is from asset packs, the "fighting" is pretty simplistic, the UI is barebones and as pointed out it isn't even very well lit, virtually no vfx. It does look decent, but in fairness that all due to the asset creators.

 

Yeah, I just downloaded it and it looks fairly similar to my system. Except we also target mobile devices and stopped at 3 lights with shadows due to instructions limits on such hardware.

 

Same here. The multiple platforms is huge. Maintaining on our own was a slow expensive nightmare. Out of the box, it isn't ideal for large teams, but editor tooling capability allowed us to overcome most of that. It ain't perfect, but not much else comes close if you are supporting many platforms.

 

I just made The Lab (valve renderer) mobile compatible and fixed one small bug they introduced in their shadow collector.
[EDIT]
I'm removing the VR dependencies and Dlls from the renderer. Will probably post a version later on.

 

If you want to know where the double precision comes from it was from the development of a project while I was working at Ubisoft. As the title is still in progress and unannounced, I can't talk much about it. But the world area was large enough that interacting with enemies over the distances involved caused a massive loss of precision which makes accurate weapons fire difficult. Even moving the coordinate system to keep 0,0,0 on the player's location doesn't solve things when you need to handle multiple players - the resolution was just too low. This wasn't an open world game but it was a large world game. And, no, the project didn't start that way. It was a smaller scale affair but the scope shifted as business and marketing forces made new demands.

The nested prefabs issue really came about during the Werewolves Within VR project. There is something on the order of 100 UI screens that needed to be shown in various configurations - solo, stack, stack with multiple children for. And UI designers really like to see how things look in the editor. Having to run the game and get to the correct point to see it before being able to tweak it is a horrible workflow. Sure, it wasn't impossible to work around it. Yeah, write a dynamic prefab instantiator that gives you options in editor and handles as expected during gameplay. Fine. But I shouldn't have to do that. Nested prefabs should just work out of the box. Its not a difficult thing to tackle. If I was sitting on source, I would have fixed it.

That projects was admittedly odd. It was basically a sandbox of games that had been tweaked and prototyped for greenlight over a few years. Eventually doing a version of the WW game became a thing. And then a VR version. So it was an evolution. The original code base was a Unity 3.5.x and done by a different group. I had done some previous Unity 4.X work with EA so after I wrapped Far Cry 4 (custom cryengine, c++) I started working on this as we were upgrading to Unity.

Workflow is an issue. Even with teams in the 10s or 20s, you still want to be able to interleave work. I want the UX person to be handling the UI flow while the 2D artists are generating and updating the art. Being able to nest prefabs really helps with this.

There are more issue - because I was doing a lot of VR work, I was dealing with world space UI. Unity has some issues with world space UI. It required lots of testing and work arounds to get to the quality bar that was acceptable to everyone. That is part of the reality of being at a AAA studio - non-technical people make demands that you'd probably skip if it was just you. You make compromises when you can - go for 90% quality if it saves you weeks of work.

Your experience will differ. Odds are you won't work on a codebase that is 3-4 yrs old and has 5-10 other engineer's trash into it before you start on it. You might not have to a 3x to 4x or a 4x to 5x conversion. Maybe you aren't doing lots of networking - because packet level debugging is a little less fun in Unity compared to Unreal, Frostbite and Cry.

My experience in game for the last 15 yrs is that the designs rapidly evolve. Projects can completely change in 6 months and the engine needs the flexibility to handle that. Unity is great for somethings but it still doesn't have that level of flexibility.

 

Hah. I suppose you're original poster then, summoned through the power of social networks?

The reason why I said it is strange is because GPUs are geared towards floats. So at one point you will have to convert things to float precision. On other hand, IIRC it is possible to avoid good portion of trouble in this situation by not using "world transform matrix" anywhere in a shader, and using world*view matrix instead.

Speaking of nested prefabs, there's prefab evolution on asset store.

However, there's an interesting issue. Let's say you have a instance of prefab "A (with prefab B attached)". You make instance of this, then modify attached B and hit apply. To which prefab is the change applied and why?

Already had such experience, thanks.

 

I figured it must have something to it that he did that someone found impressive because I found it on the Made With Unity pages. Unless they just accepted it because he is a lone college student tackling a simple RPG. Yeah he says he is just one person focusing on the design and programming and using the asset store for art as well as some "programming systems to save time".

I'm finally off to check it out now. Was delayed researching laptops for my step son. He's been wanting to get into game dev for a while now always asking what I am working on now (for years). Graduated HS last month so I figure since he still has a strong interest and will need a laptop for college anyway it's time to get him a good gaming laptop so he can get into Unity or Gamemaker. He's gonna love it I am sure. Maybe I will end up with a junior game dev I can assign tasks to. Hmm... should have done this sooner.

 

Had an Indigo (with Alias) as my workstation for a year or so way back when, and it was a dream come true.

 

Magically how that works.

Great. How do you calculate weapons fire to a point when the distance is ~ 100,000 meters or so? Its not a shader issue - it is the actual resolution of the line trace.

I usually implement it so that saved changes stop at the prefab line with a flag (on each prefab) to allow you to take the instance changes.

Wonderful. Want a cookie? Most people don't have to deal with that. Most people haven't dealt with a game that has had 500+ engineers over a 12 yr code base. Most. If you are the special snowflake exception then great. That will probably color how you want your engine to behave and what pitfalls you are looking to avoid.

 

Did you pop up on another forum just because someone quoted your post, though? Assuming that you are the original poster, of course.

Doesn't look like you would be interested in unity development, cross-forum flamewars are boring, and good portion of people here already know engine limitations. So, why bother?