Does Unity make game dev too difficult?

And we are back to game development complexity and how could Unity make it easier to deal with that complexity.

Could Unity just add a long camera designed in engine to deal with the problem of large worlds and save everyone from kludging multiple cameras together, they could probably even make a long camera perform better than two kludged short ones.



PS. It was Star Citizen that boosted Cryengine to 64 bit floating point. Note this is exactly what Kerbal Space Program added over Unity's system to handle spaces vast sizes accurately.

 

This is about the best reason not to blindly go to 64-bit. Wikipedia doesn't have statistics on AMD but NVIDIA's GPUs process single precision numbers 32 times faster than double precision. Switching to 64-bit would be throwing away performance.

Have you tried running Star Citizen? It's practically in the same boat that Crysis was back when it came out. A quick check of Reddit shows that people are not able to hit 60 FPS with Core i7s and GTX 1080s.

 

It's sad to see that a thread with an admittedly odd premise that spawned interested discussion has devolved into yet another Arowx thread about double precision.

 

NO. Because for this to happen, they would need to buy ATI, AMD, Intel, force them to upgrade all hardware to double precision, force massive industry-wide switch to double precision, force every body to upgrade their gpu to double precision supported ones, wait a few years and when the process is finished, finally release the long-range camera.

If you have unique requirements, it is your job to make it happen. Large scale world requires very different data management AND it requires managing cameras together. Quite a lot of games don't need this feature, but at the same time for something like spacesim implementing it yourself isn't that hard.

Speaking of which, I highly doubt that non-custom physics engines will be able to handle tunneling that happens at near light speeds, not to mention relativistic effects.

So, in the end your camera shakes because you didn't do all that was necessary to have a large scale game.

Of course, having an example for it wouldn't hurt, but blaming the engine for not setting up correct smoke and mirrors isn't right.

 

We had a discussion about that already, where I promise to do a test, but then I cheated and did it on blitz3D for convenience. Blitz3D can handle it, it's not a problem for unity.

 

How can you can say that without trying? Blitz3D may be superior in some ways. I always found it to be a very good rapid development language for games. Of course, I know Unity can definitely produce much better graphics simply because B3D is locked at DirectX 7 IIRC. But maybe the actual game dev itself would be just what ArowX is looking for. Not quite sure how though since B3D would likely be using 32-bit for all coords "out of the box" as well. But possibly it would be easier to implement due to less overall architecture involved.

 

DOOM? That is more advanced. I mean it would be fine because a DOOM engine can certainly handle a Wolf3D game as well. Looking forward to seeing your progress on it.

Is this going to be a sort of template for the Asset store of a ready made game or more like a collection of tools for building levels, placing enemies, scripts for interaction and so forth... or both... or something else?

 

I was talking about the space thingy!

Because I use both and did nothing special lol, I use stuff that map one to one from blitz3D to unity. I mean I used everything people told here, double camera for long distance by setting far and near plane accordingly, having objects set to a floating coordinate, etc ... and blitz3D isn't even OOP nor have basic data structure like list, so it should be easier, and ono top of that I did start on unity but move to blitz3D because there is simply less set up, i can do everything in code in a linear fashion instead of having to set up game objects and co in the editor.

Blitz3D is superior for everything simple, like testing features, I heaviliy use the plot, line, rect to test idea, especially pgc stuff. I also have a definitive and stable visual frame (no camera to set up) in 2d mode that allow to test metric quickly.

 

Wow there is actually another person who understands the kind of things I speak about. I am glad I gave you a hard time to find out this background info.

 

That's because I like doom and know it fairly well. Can't say the same about wolf3d. Also because of:

============

Most likely a complete project template for asset store with playable demo + youtube video. Not sure about collection of tools. I wanna get at least identical look, then we'll see how much I'll be able to do before I run out of motivation. Either way we'll see how it goes.

 

You shoudl try raw OpenGL in immediate mode with eigher glut or libsdl. Should be comparable.

 

But is it simple to code? Blitz3D is fairly hi level, last time i checked Open Gl tutorial where very bad, in blitz3D I press f1 to go to an instant documentation with example to refresh stuff or quickly look for options or lack of (much faster than using unity with that great in editor script ide).

 

Resize your ships to what ever size makes sense for your specific game. Don't lock yourself into trying to simulate everything exactly. Depending on the scene, a Star Destroyer might be one Unity unit or thousands. Or it might even be baked into the skybox instead of being on object in the scene. It all depends on your specific game.

You need to shift your mindset. Think in terms of user experience instead of realistic simulation. That is the key to making cool games that push the limits.

 

Well, perhaps I'm wrong - I haven't worked with blitz3d. However, glut + raw opengl combination is surprisingly elegant, if you want to draw some grids, etc. The reason why I mentioned it is because it is quite close to "draw line", etc. glBegin/glEnd syntax was quite clear.

Also.. instant documentation on f1 is used to be a feature of at least some ides.

 

I know I did a table top space game for Ludum Dare...



The theme of 'One Room' broke me out of the 1 Unit = 1m, then entire game space fits on a 2m3 space.
https://arowx.itch.io/hello-i-am-orb

Even at this sort of scale say 10,000:1 scale (is that right a Star destroyer would be 14 cm). The Earth would have a 647.1m radius and the moon would still be 38,440m or 38km away in game space.

 

Look up "Recursive dollhouse" and "non-euclidian room" in ludumdare 37
http://ludumdare.com/compo/2016/12/23/non-euclidean-room-postmortem/

The problem in your case is that you're trying to work within confines of abstractions provided by editor and want in-game space to correspond to real space. You need to break out of the box and instead switch visual representations - at multiple scales - when necessary.

 

So - Thoughts on Unity making game development too hard.

I would say yeah it is harder than most engines to make games with unity opposed to another engine such as Xenko, Lumberyard, or Unreal. This is just from a level design point of view though.

Why I say this -

1. The level design tools are bare bones
2. The Current grid snapping system sucks.

You need to spend money on the asset store to fix both these things or do it your self.

 

What about the lacking generic built in Pool manager. I know a pool manger is just a list and a few extra lines of code but the recycled lifecycle of pooled objects could also be built into the API, so OnPool() and OnSpawn() events could be added.

Ideally Automagically resetting Unity component settings e.g. Rigidbody/2D/Particles/Animation States.

 

Who cares? A pool manager is trivial to implement on your own.

Stop asking Unity to do everything for you.

 

Unity uses a GC so everyone should be using a Pool manager, I'm amazed the Unity API does not have one built in!

It's like Unity are not even taking on board their own best practice guides!

 

That is another example of something that you really want to customize to be perfect for your specific game instead of relying on a one-size-fits-all style solution. Even if Unity did offer a generic pooling solution, I would still use my own custom pooling solution.

 

It makes sense to ask Unity to do stuff for you if it's universally applicable, regardless of how trivial it is. A pool manager is too game-specific to make that feasible though.

--Eric

 

A good tool or system is one that should make things easy for you, if you start a project in Unity IMHO the API and Unity should provide a very good core of basic and commonly used features.

If for every project you have to repeat a process or task then that should alert you to a flaw in the system.

If when you have to do something a few times and it's not so intuitive that after the first couple of times it's easy to remember the small number of step needed, instead you find yourself digging into the API docs and searching for the same solutions. Then again the system has an aspect that could be simplified and improved.

Personally I find RectTransform and anything pixel related in Unity to be a pain in the rear.

Now if you are a super smart game developer you will have your own Library of solutions you build up catalogue and reuse and improve every time you use a game engine. And as the Library will be in a database you will automagically start a project with all the code and hacks you need to get things working fast from the get go.

I can Imagine that Super Unity Coder with their own personal Asset Store Library as well as the one they publish to us plebs. However in reality I put one shoe on at a time and don't wear a cape. Also I'm a minimalist, I work within the constraints of the system I use and expect a system to provide an easy to use feature set.

It's a bit like do you want a leader who leads by example or one who tells you, your wrong it should be done this other way! Without providing a simple and easy to use generic version of the other way!

 

I know double precision enhances physics but can anyone tell me how does it affect camera rendering distance?

 

Or use Zenject, so you can have a memory pool implementation based on a DI container, and it's even an open source

 

Which makes sense for things like an improved terrain system or nested prefabs and the like, but like all of Arowx's requests, this boils down to "I need this thing handed to me and no alternatives will ever possibly do" even when the alternatives have been detailed out the wazoo.

 

Z-fighting artifacts

 

Not if they're game-specific, like a pooling system is. What you're asking for is like wanting the first-person controller from Standard Assets to be integrated into the engine. Surely I don't have to explain why that would be a terrible idea (or do I....), even though it would make things "easier" in very specific circumstances.

--Eric

 

Alright, regarding double precision. Proof of concept:

Spoiler

This is earth and sun to scale using 3 cameras setup (0.0...8000.0, 8000.0... 64000000 and 64000000...512000000000). The tiny gray dot is supposed to be the Moon, but I think I've missed a couple of zeroes somewhere.

The earth is at 0.0, 0.0, 0.0, player at Y = 6500000.0, the moon is at Z=384000000 with radius of 1738000, the sun is at 1514000000 with radius of 695700000.

Basically, the scene manager spawns multiple duplicates of planets at different layers and scales them down.



^^^ I think I've missed couple of more zeroes in some other places as well.

Basically.... due to insane scale double precision support in editor won't be helping and stellar systems would require their own editor. Planetary surface would require separate handling and some sort of terrain patch when you get close to the surface.

Overall, I'd say that smooth travel from earth to the moon should be quite doable. It is possible to go nuts and pretty much render galaxies, but in this case there will be difficulties when handling clipping of distant objects.

-----

Also, I don't see any sane way to turn planetary scale renderer into something a lot of games would benefit from. The code pretty much screams "edge case scenario" at every opportunity.

 

Space is full of empty space that serve as a transition, it should be able to optimize that by only rendering to scale once in "close space" and have tighter resolution within and use proxy scale down space for distant objects, which is something I did once before the test of space travel in blitz3D. I mean the star you see in the sky can be rendered in meter scale but with all local objects on top of their rendering, because the scale they will be in you won't interact nor move in meaningful speed/distance with them.

 

That's pretty much what I did in that earlier test. Cameras start rendering from huge outer layer through smaller layer till they reach the closest one with 1 unit = 1 meter scale. The scene manager spawns proxies in layers, when necessary.

Double precision shouldn't hold past solar system boundaries... and with recursive cameras it should be possible to render pretty much anything.

Stack of seven cameras with the same scaling factor (8000) would cover the whole observable universe.

 

Great questions!

To be honest I'm estimating very little time for any of that because I'm focusing on the speed rather than the quality. I'd be grabbing free/cheap art assets and throwing them in as I go, QA would also be an on-the-fly kind of affair (which I'd feel somewhat confident of given how simple the game is by today's standards - my tools are doing most of the work for me), and I'd be doing minimal playtesting since I can get the vast majority of my design from the fact that I'm making a clone.

If you feel like pointing out that it wouldn't be an exact clone if approached like that, and that it'd look thrown together, you're right and they're both valid points.

 

Unit really makes it easy to create games. Personally I really love the fact that Unity is not a hidden secret and tons of documentation, training videos and books exist for Unity.

 

I think the original question "Does Unity make game dev too difficult?" is odd and it might be more interesting to figure out, what is a good use case for Unity.

I would argue that anyone who finds Unity is complicating the process would not be here. So what is the reason you use Unity?

Spoiler: My reason

In my case I like it because of:
- Great flexibility (so no need to learn different tools for 2D / 3D, etc.)
- It's pricing model
- Ease of multi platform development
- Use of C#
- Learning resources (tutorials, manual, community)
- Asset resources (although I do not really use them much)
- Clear interface

What I don't like:
- Hard to figure out what best practice is for common use things (i.e. game manager, saving, transitions, etc.)
- Somehow difficult to understand get hold of all the standard settings (i.e. player, project, lighting, etc.) and what they affect
- That extensions (assets) are not clearer separated in say an extensions window / folder

 

So. Here's an attempt to create retro visuals in unity.

Spoiler

 

Ah, I see, thanks for explaining. I guess it confused me that whenever there comes up a thread where people start chiming in with "I could make X in Y hours", not everyone seems to agree on what specifically counts as having "made X". E.g. clone can mean a 1:1 copy with great attention to detail, or "vaguely similar" to some people. For me "make a game" always means "make a game to the best of my abilities", because otherwise what's the point? I remember that around the time of release the main dev of Devil Daggers - a retro inspired shooter with just 1 arena level, for which your highscore is the time you manage to stay alive - had logged ~500 hours on steam. I can only assume there were many hundreds of hours more that he played before the game even was on steam. The whole thing is designed to be challenging even for the best shooter players in the world, and he had to become one of the best players just to be able to playtest lategame content. Here is a run by him. I can't even watch people play that game for long without getting extreme motion sickness, just skip through it to get an idea:

It takes massive time to tweak and balance something like that to this point, and make sure there are no exploits, but everything is still achievable by mortals. Now imagine someone made a thread here asking "how long to make such a game in Unity?". I'd imagine (assuming familiarity with Unity, programing, etc.) most would say something like "100 hours tops", and some few might say something like "1000 hours minimum", because apparently there seems to be such a vastly different understanding of what "make a game" means to people here. And to be honest I don't get where that's coming from, because it's not like steam is filled to the brim with successful 3 - week projects. If they even exist they are rare snowflakes.

 

Definitly missed a couple of zeros as the moon covers the sun nearly exactly, eclipses it even, when viewed from Earth.

Now can you spin the Earth around the Sun, a pivot hierarchy will do, and the moon around the Earth and do a video to show an orbit please?

Ideally with realistic velocities?

Or you could get the Jet from the Vehicle assets, boost it's speed a bit and fly it from Cape Canaveral to the moon and back. It's OK no orbits or Newtonian gravity needed. With a Video of the journey!

Otherwise you might as well have made a scale model and a skybox.

 

Here is a Earth Sun Moon system that should orbit with reasonable precision as it is scaled to fit into the 10k limit.


Note the view from Earth, The Moon Red, Matches and Eclipses the Sun White/Yellow with halo.

At this scale the Earth is scaled to 0.84 Unity Unit's.

And this is 1AU (distance from sun to earth) scaled to 10,000 units in Unity.

So you would definitely need to do what Kerbal did and build a 64 bit floating point Vector and gravity system to model a solar system accurately.

Although I think they still used scale models for distant visual objects.

 

I had a discussion with a person making a fan game (yes, a fan game) in UE4 recently. Well it was a team but they had some strong feelings about Unity.

Things cited were minor but they seemed to think were deal breakers.

They cited:

• Poor UI design
• Lack of automatic prefab imports (drag and drop in to the project foldern, no right click menu to import things/reimport should actually work).
• Lack of support for other asset formats

I can see what the guy means. I've used UE4 a little and TBPH Unity has a funky GUI. I don't mind grayscale, but instead of an "add tag" button under the tags/layers list menu one must click the textbox and type in a number? If you had 18 tags and wanted two more you would enter 20. Everyone here knows what I'm talking about I think. Silly things like that are kind of a pain.

I agree the reimport feature needs to work. I agree support for other formats would be nice, but to this point I've never had any problems with importing from .fbx; though I'm not an artist.

Lastly my own beef is with the GUI system. Sometimes its really difficult to click the object you want. Other times its way too easy to click something and mess up the entire design.

Would it be possible for the Unity team to outsource fixing some of these things? I know they're building a bunch of requested features which is why the terrain system and other things haven't seen changes in years.

 

Did I forget to mention that my example uses double-precision coordinates? I thought it would be obvious.

This can be easily done and I'm honestly not sure which part is supposed to be funny and hilarious there.

The thing is I'm honestly not feeling like working on it further unless someone's paying. Maybe my opinion will change someday though.

In all honesty ... if instead of asking for features you spent that time working on space game, you could've made a lowpoly star citizen clone by now.

 

Wow just shows how it is all a very personal preference thing.

I checked out UE4 and greatly preferred Unity's simply because Unity has much less GUI in general.

Also import//reimport works fine for me and there is a pop up context menu to do so. In fact I often do that. I keep auto refresh off and either hit the refresh/reimport key to pick up changes OR simply right click directly on the asset or folder and do it.

I'm not knocking that team at all. In the end if Unity worked better for them I am sure they would be using it. It's just that simple. Sometimes I think people tend to think others just want to find faults with Unity just for the fun of it. And i don't really think that is the case for game developers. If Unity worked for them they would be using it. Same if UE worked better for someone here they'd be using it. If Gamemaker worked better well those people use that.

I think I am actually an odd one in hat I keep trying to force Unity and I to click. lol And I have made progress on that but it is a kind of stupid thing to do when you really think about it. But I like learning and so I want to "get it" to understand why people here love it so much.

 

Yeah that's what I thought. These guys just have bias. Nothing more obnoxious than people who think they're absolutely right and have some "objective truth". I had to agree that they had a few points, that the UI is kind of odd, but tbh... that's because I avoid conflict like the plague and I'm not confident enough to argue my point in any situation. I'm a bit of a quirk.

I never thought they were serious problems. The only reason I mentioned these was maybe Unity could go for a better version of it. It seems like these people were the kind that wouldn't be swayed even unless God himself came down and publicly endorsed the Unity engine.

That is IMO the worst kind of person. He who won't concede when facts and strong arguments are presented.

Also wanted to mention that when I asked about what UE4's memory management was like they were all "oh it doesn't matter because UE4 has blueprints".

Like that even matters. They barely code. I was so freaking close to saying "You can't even code. GOML." but this is a project I wanted to help with.

 

Well like I was saying (actually I extended my reply after you read it probably lol)... I completely understand that Unity may not work for them. It is not a this engine is better thing it is a this engine is better for you and that engine is better for them and another is better for someone else.

It's like with me. People.may not think so but I try very hard to click with Unity to understand it and how it is supposed to be used. Yes I also spent a lot of effort stripping it down to basically being like using C# and XNA to a degree. But that also helps to understand it all. I want to click with it. I want to be able to view it as this is saving me a ton of time but I am not there yet. I am getting there tiny bit by bit. But I also think there is a lot of work in Unity. More work than I am used to having to do mainly all of the Editor set up stuff. Doesn't mean Unity is bad just means I need to learn what spending all of that time is actually gaining me. How it is benefiting me. It probably pays off down the road at some point.

 

You are still asking the wrong question. User might say that want a perfectly realistic simulation, but that is seldom what people actually enjoy playing. Building a perfectly realistic simulation of the solar system is different than building a game. Try to think in terms of game design instead of simulator building.

The better question to ask would be what tricks could you use to generate the visuals simulated in a close enough way that would be fun for the player. Realistic velocities and realistic orbits do not really apply during the time frame of player interaction. During the minutes or hours a player interacts with a game, the relative movements of the Earth and moon are nearly zero. And most players will actually feel a bit disoriented if a game moves planets and moons around. Gamers generally expect large objects to be relatively locked into a location.

 

That is pretty scary that a team would think like that. UE4 is pretty powerful if at least somebody on the team is very confident with C++. If the team thinks they can handle everything with Blueprint and none of them can code, they will probably run into a wall at some point with the project.

 

1) That's a matter of opinion, and I don't agree. 2) Unity already does this? I don't understand the complaint. 3) Are there other engines which support more asset formats? I doubt it.

Kind of weird objections if you ask me. I mean, Unity definitely has areas that need improvement, which I could see being deal-breakers for some people, but the reasons above aren't really among them.

--Eric

 

If a GUI factors in anywhere near the top of the criticism list they have their priorities seriously backwards, I mean out of all the issues with both these engines they choose a GUI.???

Back on topic, does Unity make games hard to make? Well it depends completely on the project, I agree with @Ryiah there's so much competition out there the level of complexity needed to create something competitive has risen vastly.

I do seem to give Unity a bit of beating often but I like to think it's constructive criticism, so I will focus on some positives. My original goal was a much simpler project along the lines of Pillars of Eternity / Diablo.. For those type of games I've never been so productive, there is no other engine available that would get me there quicker. It's so easy to get the basics together and enhance.

You'd be surprised at how the little things really stack up, like compilation times of various systems and TBH I actually like monodevelop..

Unity doesn't suffer these sort of issues, also there's a huge amount of relevant information to learn from as Unity's core isn't constantly changing. In UE it's outdated sometimes in the space of a month..

Creating something like Pillars of Eternity as an end to end project is a hefty task, so many will say if that's all you can get done in three years is there any need to dial it up 10 levels? Which they are probably right.

But if you do decide to notch it up 10 levels Unity becomes a nightmare..

 

Well I can see what you're saying and at the same time I don't know man... I think the GUI can play a major part in either increasing or reducing productivity. Assuming you need to spend a lot of time working via the GUI such as in an Editor environment certainly connecting well with the GUI should make it a lot more pleasant and productive experience than it would be if you find the GUI confusing and lacking in general.

I am not saying Unity has that in general just mean for some people it might and I can see how that would impact productivity. It's like Blender. Many people dislike the GUI which I also think is understandable because that is probably the wrong way to use it. When I was getting into Blender I found using the keyboard was a far better way to interface with the product than the on-screen mouse based GUI.

I definitely get how the tiny things stack up. That is kind of what this was all about. There are so many things in game dev that yes they are very simple but the cumulative effect of all of those actions / tasks really sucks up a lot of time.

I still wrestle to some degree with the environment. Like in your Diablo style example from a Blitz Basic or AGK or even Unity using SpriteTile or some other tile based method I can see how to approach it. But from a "floating" free form working in the Editor freely approach I feel lost. Like where do I begin. What do I put where. And I think much of this comes down to background.

For me, a tile map makes perfect sense. It is a great data structure that provides not only the visuals displayed but also the underlying interaction information and so forth. I find that highly logical. However just sticking art into the Editor to me seems more like I am just messing around building a scene or something.

Ha ha! I just read what I wrote. And yeah I guess that is the whole point exactly to build a scene. But see I don't really think of games as scenes. I don't think of them much from a visual perspective really. More from the underlying data, how that data changes and the events and processes that cause the changes. The visuals are updated entirely based on the state of the underlying data. But it almost seems like it is completely the opposite approach in Unity... like an art first... graphics first approach... and that governs all else.

Anyway, just another example of different things for different people.

 

It's not like we're talking about a 90's delphi style mod kit here, both engines are functional if you take a small amount of time to learn them. I'd say UE's a bit more cluttered, but that's because it has far more stuff in it..

I get UI's can be a pain, but it ain't the case for these engines.. Hate to say it but art is the biggest challenge of modern games, plenty of re-useable code and UE comes with an entire game framework to build from with many examples, Unity has an endless resource of tutorials which take you to near completion. Coding ain't easy that's for sure, but it's definatley not the most time consuming part either..

@ShilohGames

What's the problem with C++? It's automatically memory managed / GC'd in UE's implementation and to me it's a simple as this, if you can write an RPG in C# you can write an RPG in Unreal w/ C++ (not to say I don't find Unity's component based C# quicker)..

 

What I do in Unity is set up some GameObjects to attach my main scripts to for handling different subsystems in the game. I don't manually lay out scenes in the editor. I set up prefabs and then spawn the prefabs from my code. You could use that layout as a starting point.