Does Unity make game dev too difficult?

UMA handle all of that with ease, at least you can look at how they do if you don't want to use it, it's free and model agnostic (people have been doing plane with it).

 

It is 90..95% creation of art.

Even though unity does have few oversights that can ruin your day, the primary time sink is still art creation.

Try to model fully animated/rigged character, and see how long it takes. In high fidelity projects cost goes up significantly (I recall reading that in witcher 3 one character model could take 2 or 3 weeks), but even if you cut every corner and use ultra low poly graphics, cost remains very very high. Making one character can easily make more time than coding arcanoid clone from scratch.

 

You can barely cut on animation, even bad animation take time.

 

Yeah @neginfinity I know graphics are definitely a time sink. Why do you think I strive to spend as little time on them as possible? lol For 2D games I am basically down to either ultra low res or solid rectangles at this point. For 3D ultra low poly with minimal animation or cubes, etc with just motion / rotation for animation. I can't really decrease it more than that... well for 2D I could use really tiny graphics. Like the entire game world is on screen at one time, not low res but the characters are maybe 4x4 pixels in size with no animation at all.

Of course, could focus on different games... or possibly try something like this look for other kinds of games...


Nevermind, actually that would basically be more work than make entire game world fit on screen and use 4x4 pixel graphics.

Beyond these kind of things the only solution I have found is just hire artists to knock out graphics (in the same manner).

But I thought perhaps for @imaginaryhuman part of the issue might be on the programming side.

You know maybe this is why to me it seems like nothing really has changed in game dev. Why I see no real benefit from using Unity over using AMOS back on the Amiga. I mean of course the obvious change in computer tech much faster now no need to spend time optimizing to make most 2D games. But yeah I never really thought about it. This is almost certainly why to me I see no to very little difference in game dev today over 25 years ago. Graphics. This is still the same time sink (and more for most people because they are striving to make up to date graphics) today as it was long ago.

 

I did have a play around with NaaLaa6 just now and it has a beautiful ray casting engine as well as level editor built in.


See if Unity had something like this built-in it would be sweet. This is rapid development.

Obviously, still need to populate with enemies and collectibles then bring the enemies to life but at this point having the level generation and rendering be automatic is probably 75% of the workload just done with. For me I mean. Because whatever I draw up and stick in will be what is in. Just simple enemies probably monsters with a few anim frames. Draw a simple gun sprite over the display.

I guess when I get into a game dev frame of mind again I will take a closer look at this N6 and build a little Wolf3D style game. Could be a person needs to use maybe 5 to 6 different tools (as in different game engines / programming languages & apis for specific types of games) to really get rapid game development.

@neginfinity maybe take a look at how N6 is doing this. This seems to be a highly streamlined way to get a massive jump start on building a Wolf3D style game. Basically can jump straight into focusing on the gameplay. The collectibles, enemies, guns, perhaps some puzzles, etc. Obviously, one still needs to design all of this and program it all up but still this is what I consider streamlining game dev. Which I guess some people may not want that but the way I see it the more I can get done in less time (1) the more ambitious my games can be and (2) the better job (as in more polished) I can do. Like I might actually spend time making some real graphics.

 

Gar, what is your chief priority, making a game quality or making a game quickly? Ask any professionally minded person (who intends to sell a product) and they will immediately say the former. Keep in mind that Unity is for them. Unity is still a tool for people who want to podium, not take a participation trophy home.

Do you want to make a game that's been made a thousand times over, or one that only you could make? Which of those do you think Unity actually caters to?

 

I see quickly as the way to achieve quality. At least in terms of additional depth. I realize most people won't understand that. For me (and I think it is true of all devs although they might not realize it) the faster I can develop and complete a game the more I can have in it (depth, scope) and the more time I can spend on things such as polish.

Current priority remains development speed. The goal was always to reach the point where games like Atlantic Crisis and Treasures of Ali-Gar could be completed in 10 hours or less start to finish.

Instead of such games taking 30 hours or more. And then when I reached that goal I would feel comfortable focusing on a game of a larger scope. Quality wise I think the games are already good and they seem to be well liked by the people who have played them. Of course the graphics can be hd etc. Mainly I'd like to expand them out but that takes time and so development speed is the key.

 

I'll pass. I have fairly good idea of what to do regarding previously mentioned doom clone, just have something else that needs to be finished right now.

I'll get to that project somewhere aroudn wednesday/thursday, I think.

 

@GarBenjamin

• I think Unity is an overkill for the games you posted above, I am certain that there are more suited game engines for such type of games (i.e. allowing faster development)
• I think that Unity can be a good choice,
  • if you don't know what you want to develop other than general skill, since it allows a good deal of flexibility (game type + target platforms) and hence is a good tool to learn as it keep your options wide
  • i you know what you want to develop and require the flexibility Unity provides
• I think I would enjoy a game design thread from you, where you start putting your time in defining your dream game instead of assessing tools, art assets, benchmark speed, mini-games, etc...
• Once the scope is clear incl. target platforms, it would be an interesting discussion to find a path to get there with the least effort. Including the assessment of which game engine would be best suited.

My issue with Unity is my own time. I appreciate that it is a game engine that possibly unfolds it full potential only to those fully dedicated. I somehow enjoy it though as I can toy around with many different things (procedural, meshes, shaders, etc.)....

 

Unity make it really easy different kind of people
1)C# coding
2)Visual coding with NodeCanvas, FlowCanvas, Playmaker etc ...
3)Game template plugins
For example Ultimate Survival plugin is a complete game template working out of the box and
you can change anything.

You could use those plugins :

1) Spriteman 3D plugin to manage your 2D characters with animations

2) Probuilder to build your level if it's doom like structure (you're lucky it is on sale)
If your levels are only squarry you could use Tiled plugin or Pro Tilemap plugin for example

3) To quickly place characters , props and prefabs you can use Gena or Octave 3D or a cheaper placement tool.

What's left ?
Coding Menu, player and weapons gameplay , HUD, items interaction , doors interactions and logic, and some basic ennemy AI interacting with the player .
These are the fundamentals game logic anyone should know when you do game development whatever is 2D or 3D engine and whatever you code or use some Visual scripting tools.
There is thousand of video tutorials covering the basics if you are ready to learn.

Perhaps you prefer a 3D engine with less tools or some game engine with game templates you will only mod

Or modding Cube 2 engine
www.youtube.com/watch?v=fX7o-1OH-WM
Or modding Unity game templates
www.youtube.com/watch?v=kdwXlolTuF0

 

Hey thanks this is some good information. The No Mans Land looks like a very solid foundation. I think the tool used to create it is probably locked in though. Basically I am just striving to hit that sweet spot between maximum development speed and maximum flexibility.

I'll check out those suggested assets.

 

I do like mini / tiny games. At least for the core. I think if a person can make a very solid tiny game that is just a tremendous foundation on which to build. Like Atlantic Crisis could be expanded into horizontal scrolling stages and possibly some vertical scrolling as well with some "real" level design maybe little caves to explore and so forth. Maybe add a couple power ups. Such a game would be fine for Steam and I think would be received quite well. Again if implemented solidly and fun.

My "dream" game would be something along these lines... the player begins with maybe just a single screen Atlantic Crisis type of experience... then after some time it opens up into scrolling levels as mentioned above. However, there are passages that take you other places. Such as into Treasures of Ali-Gar. Of course not a little wizard dude in this new context but anyway give that mini game same upgrade treatment... some slightly larger levels perhaps with some floor traps and power ups / gear to collect as well. In this case be searching these areas for certain items then returning to the sub.

Something like that would be a step toward the kind of game I'd like to make. Just have an unfolding story that takes the player through an in air above ground shmup, a platformer, a top down cave/dungeon explorer, an underwater shmup, a wolf3d exploration style phase and so forth. A very light cinematic thingy (maybe just a single screen image) between these that updates on the story and provides context for the new area.

It's more about overall scope and variety for me basically. And having it all mean something so when the player gets through it all they are like "damn that was a hell of an adventure! Had me doing all kinds of things in all kinds of different places. Never boring. Always fresh" and when they die "I wonder what's next?!" of course in this age people could YT it.

I firmly believe in simpler is better. And can make a pretty epic game with simplicity basically by stringing together a series of simple mini games connected by a story.

 

But you'll accept whatever quality you can get if it means getting it done before you're bored of it. You aren't in it for the long haul.

 

I suppose @ShadowK and I are not all that different at the core. In that we both have always been a quest to experiment and find the best way forward. To find the best possible way to do things... the best tools and so forth. And many projects are started and (some are completed games) during this investigation.

But at this point we could both actually make our games... it is just a matter of doing it. So I could then take the same challenge myself to "just do it". But damn I really hate being locked in to wasting my summer inside on the computer. lol

Hence the focus on development speed. I might be able to force myself to put in a few hours per month on such a project. Something to think about anyway.

 

I think that sounds pretty accurate. Although long haul is vague. I imagine 10 years from now I will have completed more games and at some point be working on yet another.

But what is the point you're making? To say that I am not a highly dedicated game developer? Heck I could have told you that from the start. I do this for fun. It is not my job.

And in all of your posts regarding my views and my work... I don't know what your goals are. You never seem to share about yourself. What are your goals? What are you working on? What games have you completed?

 

If you are trying to focus on games that only take 10 hours or less to create, then Unity is probably overkill for you. There are easier tools out there that cater to simple 2D games that can be built quickly.

 

I've uploaded earlier flight test demo to github.

https://github.com/NegInfinity/spaceflight-unity-demo

The code is under zlib license. Have fun.

 

I've been checking out other tools and tend to agree some alternatives would provide a slightly faster development experience. The end goal is not to make a bunch of 10 hour or less games. That was just a target I set to strive to reach for a certain scope of game. Which may not even be possible but a person needs to set a target so I went with that. In reality it may be impossible to decrease it below 20 or even 24 hours.

That is just a step. A stepping stone in a sense. On the path to making a bigger and hopefully better overall game. Because such a game would require multiple game engines and consist of multiple such mini games (and each enhanced somewhat as well). So currently it might be a 1,000+ hour project. I'd like to see that reduced to maybe 500 hours. But again it might not be possible. All I know is even 500 hours to me is a lot of game dev time. Ideally spend maybe 5 hours per week so that would be about a 2-year project.

 

@GarBenjamin

That sounds indeed like a complex game, basically a blend of genres. I think this really needs a lot of upfront focus on the storyline and the mechanics as well as target audience. This might actually require something like Unity.

hope you develop this concept further...sounds quite complex

 

You could use game template plugins , you can just mod as you want without needing to know coding and game basics. The only requirement is to be able to use Unity Editor lol (import animations, use mecanim , make new particle effects ...)

There is game templates for all you described already, you can load game levels from each template to achieve you game mix.

Find a mate to team up with or several, perhaps one to make simple retro 3D art, and another coder lol

 

Unity isn't for you then. This is why most of the replies to this thread outright reject the premise. It's one thing to have someone say your game is good, but it's another thing entirely if they say it's good after they put money into it. At that point, people would care that your game does more than just run.

My problem is I have pride. I could make a game in the time it takes to take a dump, and while I'm sure you might like it, I would rather flush it.

 

For me I like some things about Unity and dislike others. Unity has saved tremendous time where it's provided a leap from a lower level of programming to a higher level. Examples would be all the effort it used to take to do graphics programming, physics, shaders, that sort of stuff. It's now much more editable and visual and automatic. Compared to what it was like before, it's a big leap forward.

What I've found trying to work on 2D mostly, which has improved over time, is that the workflow just isn't as simple as it should be. There's too many steps and not enough automation. There hasn't been a quantum leap like there was for the other systems. There isn't a whole lot of time saved now compared to older methods. Level design and building takes a tremendous amount of time, before you even mention artwork which is not so much a Unity problem as such.

Because Unity is big and generic, that kind of means it does not know what's relevant to you or your project. Flipping a "2D" switch hardly helps at all. Inevitably you end up having to develop logic at some point, which most likely means some kind of visual scripting or writing code. Coding is crap. C# is sophisticated and a real programmer's language, which makes it picky about syntax and you have to do everything very exactly. The Unity API is so big and feature-filled that I almost always have to go hunting in documentation or forums or unity answers trying to figure out how to do something or what particular bit of data to access etc. Programming is painful, to even achieve very basic stuff.

Then if you try to ditch written programs you find that visual scripting is not a whole lot better. You end up needing to use variables and do some math and all the clicking-around and wiring-up needed to accomplish it is like 5x slower than typing it. So now it's added more pain in the name of saving pain. And those diagrams become hard to read and manage very quickly.

One of the issues I think is that Unity is appealing to a wide audience so is very wide in terms of its scope, and that means that it does not really sense or adapt to the individual. There are many features or workflows that are just not relevant to me. But I can understand that if they were to create a highly adaptive user interface it would be so different for each person and project that it would be quite difficult to provide a single consistent model of support and editor layout etc for everyone. One size fits all, means that one size generally does not fit anyone exactly. This is what I feel about the Unity experience in general. It never quite fits.

I always end up having to go to scripts, which is a nightmare, and then I start looking for third-party assets to try to help. That's another can of worms. In some ways assets can specialize somewhat closer to the realm that you're working in, but then you find there's 1000 different user interface designs, strange feature implementations, some stuff that doesn't work how you want it to, missing features, bugs, etc... then you end up once again going back to code to try to figure it out (huge learning curve) and to try to fix the problem or add something. Almost never does the asset really 'fit' entirely either. Some do better than others, but it's all over the place. I end up trying to customize most assets which takes a lot of extra time just to get it up to speed with the workflow I desire, and then I use up most of my motivation to even do anything with it, realizing all the things that I still have to figure out how to make work.

Far too much I'm having to go into scripts. Don't get me wrong, I can program quite well. But it's not enjoyable, and as soon as stupid bugs or strange issues rear up, it really puts me of wanting to do any development. It's ungodly how much scripting is required just to make basic stuff happen. The whole idea of using scripts for logic I think has to be totally thrown out the window.

What I think I'd replace it with would be some kind of very very high-level set of tools, maybe adaptive to the genre or basic template of game types. These provide huge amounts of automation and tons of assumptions and simultaneously saves a ton of time and just leaves you with some basic options to tweak. Almost like a pre-made game. Then from there, you get to decide which parts of the system you want to break down to a lower level of detail, and I don't mean just jumping straight to hard-core advanced, I mean, like, beginner, intermediate, experienced, then advanced. At each level you can 'customize' that portion of the system by exposing more detailed configuration options, which still provide automation as much as possible. If you want to drill down and get really specific with your choices you can, and hopefully at the lowest level you still won't have to get into scripting at all.

So let's say I want to make a 2d shootemup. Maybe I choose a 2d template, flip a switch to choose scroll method, flip a switch to set the number of levels or the sequence of levels. Grab a pre-made player character which in this case provides a spaceship, complete with a control system already hooked up and working with animation and everything, in like 5 seconds flat. It gives me some pre-made procedurally generated computed level to fly around in and sets up some procedural enemy waves, bullets etc. Within 1 minute it's playable. Then if I want to, I say ok, break down this level to more refinement... a bunch of new configuration options appear, I edit the level content, maybe adusting waves, enemy types, or something... ending up with something a bit more customized. I do that for a few levels and set up some procedural options to vary things and put it in a loop. Now I have 100 hours of gameplay.

Then I say ok, I want to modify what the player ship looks like and how it moves, so I edit the default and i see some more breakdown of configuration options, lets me plug in off-the-shelf player control systems modeled after popular games, I can select a different ship design etc, change some basics, choose some weapons systems etc... just simple user interface adjustments. Then break it down again if I want to really customize the bullets, maybe getting closer to a graphics editor or library of pre-made animations. etc... just gradually you get deeper into the bits you want to get deeper into, and maintain the higher-level automations where acceptable. Basically a highly configurable 'game template' that isn't locked into just a narrow range of configuration, but can be transformed into something very unique very easily. For me I think this would be much less hassle than the workflow that I have to endure right now to pull of the same end result.

To do this right now entails so much fiddling around with files, importing and messing with sprites (which should be 100% automatic - why are we playing with sprite sheets manually ever?). Then getting this stuff into the scene and to even get it to animate takes several steps. Then you want some kind of control system? hmmmm..... scripting anyone? How about taking several days to get it working right? Now you want to add some bullets.. hmm... more scripting anyone? Setting up collisions... let's see, well, we've got to go add all these special components and set up all these little checkboxes to make them behave properly, because heavens forbid you set up a level using unrealistic easy-peasy fake physics - it has to be this advanced physics simulation for goodness sake. Then you find all kinds of weird side effects with the physics that takes a week to debug. Then you want to add some enemies so... back to scripts again? what if you want them to follow some easily-drawn-with-the-mouse movement paths? Or, like make flight formations or something. Try to hunt down someone's premade nightmare or come back after another week of coding, when it could've taken minutes if it was built in. And you want the enemies to have some basic AI? well... no. Script it or else. This is just not fun!

But then you go look at what 'game templates' there are, as a suggestion. And you find that they have limitated configurability, they lock you into the 'high level' of editing, you can't easily customize beyond a certain point so it's kind of like you have to live with what you get. Or go do some scripting. Again. *yawn*

 

Ha ha. If you could make a good game in that time you're right I'd probably like it. I highly doubt that would be the case though. "Having pride", "perfectionist" and so forth I find are often just other ways of saying "I haven't completed anything yet and most likely will not".

Maybe that is not the case with you but in general that is how it goes and all too often used as an excuse.

 

Those are contradictory requirements. "Something that's not unique but can be made unique". You have to pick one, you can't have both. Any template by definition has boundaries.

--Eric

 

A lot of good stuff in here especially the multiple levels of refinement for such a kit based approach is very interesting.

Also agree on the tools in general. It's odd but I remember back in AMOS making a shmup and just like you mentioned I just knocked out a simple utility that allowed me to draw flight paths on screen with the mouse then saved those out as vectors. It made it super easy to define even complex patterns. I guess a person could do the same thing in Unity although it seems completely different to me. I know that a lot of people love Unity to be able to easily make development tools but this is one area where I find no logic in it. Maybe in reality it is not as different as I think and I just need to take the time to try it out.

 

Because that way you can make anything and are not limited to pre-defined templates. Being able to make custom editor tools is 100% absolutely a deliberate and very powerful feature and not a limitation. It's utterly bizarre that anyone would ever want to make Unity into a template-tweaking machine. (But hey, you can do that if you want and there's obviously some audience for that sort of thing, but it's precisely the kind of thing best left up to asset store sellers and not Unity themselves.)

--Eric

 

@imaginaryhuman

It really sounds like Unity is not for you, as developing anything more than a visual novel or point/click adventure will more than likely require scripting.

Have you tried something like Stencyl before?

 

Very bad wording on my part. I completely get the logic in creating tools. That's what I was saying with the example of the mouse motion recorder. I meant for me there has been kind of a disconnect with doing that kind of thing inside Unity. I think I need to just try such a project in Unity sometime. A mouse motion recorder or actually I think I ended up going with a point path laying tool that had a smoothing option when saving... would be a good project to do. Might be helpful in learning to see Unity closer to what I am used to.

 

When I make tools in Unity, they're usually just single functions that do something repetitive automatically so that someone doesn't have to spend time to do it by hand.

For example, a few weeks ago we made a change to a game design that required a bunch of things scattered throughout our world to have unique "designation" names. We could have sat down and selected them each by hand, typed in a unique name, and then saved the scene, but that's a) really time consuming and b) ridiculously error prone. It took ~2 minutes to write an Editor script to do the same, and because we made the computer do it we know the results are correct and consistent.

But that's not all! Moving forward, we never have to worry about naming those things while we're assembling levels. Once we've assembled a level we just select the same menu item and it does the job for us. The whole thing is done in less time than it'd have taken to name a single item manually and, again, this gives us consistency and reliability.

Furthermore, imagine that at some point in the future we decide to change the designator naming convention. Since we already have a tool that applies the names it's a small task to apply an update across the whole game.

We have too little time and too much to do to ignore the benefits of automation.

 

You see contradiction where there is none because you are fixed into a traditional development mindset. Typically developing software follows the same pattern. You either make things very generic and lose a whole lot of flexibility, or you make it really flexible but highly complex. But there is another way. Decouple the level of sophistication from the decision to be generic or not. Start out looking like it's generic when in fact it's highly dynamic, and the generic interface is just one of many many possibilities. Appearing generic on the surface doesn't have to mean your hands are tied and you can only drill down a shallow level of configurability.

That's the old mindset of "either or", i.e. either I'm going all-out generic and high-level or all-out complex and low-level. Why not have multiple levels within the same system, on a per sub-system basis? Why not let people start out with what is extremely high end and easy and automated, and then let them drill down to change the bits they want to change, and keep all the rest of it running effortlessly and premade? To me that'd be a huge time saver and much less painful.

Typically we have to start at the bottom and work our way up, gradually building up bits of code and collections of data or objects and trying to gradually shape it into something that even works cohesively yet alone looks any good. Building a foundation and building on it. Instead of.. take something that has done a S***load of the work for you, and just go to town changing the parts you want or need to change and let the system take over doing all the other parts you don't really want to do. If I'm happy with the fact that my spaceship shoots bullets at a given rate and color and intensity, and maybe have chosen a bullet shape from a library of options, I'm already DONE, I don't need to think about how to make the bullets move or how they collide or whether there's a frickin' object pool to deal with memory issues, or whether the sprites are all nicely lined up on a texture. Nobody really should have to care about that stuff, it's just a big longwinded pain.

And I also do not mean, well.. you know... if you go high-level that means you end up making clones of every game and there's just not enough variation or freedom or customization options. THAT is because developers don't build in enough flexibility or levels to drill down their options. They always commit fully to either "always high level" or "always low level". Instead of making the "template" be just one of many many possibilities, they lock in too many design decisions and don't see how they can provide extra flexibility without being "always complex". It doesn't have to be always complex, only when you want it.

With unity, the system in general has some high level parts but getting it to do anything sophisticated is always... go straight to the lowest level. You have to write complicated program code, which is horrible for less experienced developers and not a whole lot more friendly when you know what to type.

If I could narrow down what I really want to be custom, in a given game, and only work on that, and not have to do ANY of the other glue to patch it all together and make it function, that would be heavenly. Such a huge time-saver. And that wouldn't mean I'd be stuck with... only 5 different shooting patterns or only 6 types of spaceships, or only 3 ways for bullets to move. Because THOSE levels of predetermination would also be able to be broken down and customized IF I wanted to, exposing another whole level of configurability, and maybe even another one after that, before I ever have to get NEAR any scripting. Programming should in my opinion be a last-ditch resort (which it is all too frequently now), and not a first line of defense.

For example, why can't I just drag an image file off my desktop into the scene and immediately it's turned into an animated sprite, immediately followed by a popup with initial options as to how it should move or what kind of AI to give it etc? Why am I forced to have to go through the rigmarole of setting up a sprite sheet, setting import settings, faffing around with compression options and slicing and drawing little boxes around things, and only then being able to actually put the thing into the scene. Let me drag and drop the thing into the scene FIRST, and THEN ask me if I want to customize what's happening. Just one tiny example.

 

I also think the assets on the asset store, tool-wise, are far too diverse in terms of workflow and user interface design and so on. Unity should set up some kind of standard or style guide which goes above and beyond just how it looks or is laid out etc, so that qualifying developers can produce tools that actually work together or complement each other or build upon a standard way of functioning, beyond just "its a custom inspector" or "i built it with standard widgets". There's so much additional learning curve required, and then when the tools fall short in some way every single of one of them is a custom job to try to get it modified. There are no standards at all. This should all be managed at a higher level and all tools should somehow work together much better.

 

Objectively, if you have a template, you cannot make an actual unique game. You're 100% limited by the template, that's just basic logic. If you make it sooooo amazing and flexible that you can do basically anything, then guess what, you're back at square 1 (where you complain about it being too complex). It should be obvious what the flaws are, and why that sort of thing doesn't actually work for a game engine: You may think you're removing complexity, but in reality you're adding to it. Instead of one system for doing the stuff you want, instead you have a complicated high-end system you have to learn, but then you have to learn the lower-end system anyway if you want to do anything off-template. Kind of a nightmare to actually work with for a real project.

Sure there are workflow improvements to Unity's tools that could be made. To be fair, they generally do, eventually.

--Eric

 

The real issue is Unity doesn't offer a healthy(ish) dev's dinner takeout / delivery service.. Imagine how much more you could get done if you didn't have to cook?

You'd feel guilty eating bad food as well, they have analytics on everything.!

 

This is a very interesting idea and honestly I am surprised that we don't see game engines using such an approach. It is possible there is one or more out there doing so.

Sounds like the obstacle for you is different from mine. Which makes sense. Different people.

I don't mind programming at all. I just had a play around with Unity messing around with designing a Wolf3D style level. And what a pain in the ass. Such a tedious process. I think this is really what the main issue is. The lack of any reasonable tools for building. In just about anything I have ever used to develop games there are tools readily available to quickly handle these kind of tasks.

I think this is why I cannot understand how people can find building inside the editor to be efficient. I don't know if they simply have never used anything else so have nothing to compare it to or what.

I imagine it would not be efficient but I think if I approached it in Unity it might make more sense to just define a 2d map in code and then generate it all out there with prefabs. Although now that I think about it I probably could have done it simpler so maybe I will try just making single chunk floors, and various single chunk walls and using tiling of the textures. Although that would require numerous materials based on the tiling needed for the different sized wall sections. But probably not a huge deal.

I've often thought it would be cool if this thing just had a 3D tile editor in it. I've bought a few of them to test out. One worked pretty good but overall most assets I have purchased are pretty clunky prone to errors, etc. And I think this is really the difference. It's like we don't have any professional tools here. We just have a bunch of tools created by amateur game devs for the most part. I mean obviously we couldn't have every single tool but damn some basic stuff would be nice, ya know? lol

I might try it by making a model in blender but then of course that still means going in and manually placing doors and decorative objects and so forth. Yeah that wouldn't be efficient either.

See, I don't know how others view this stuff but to me this is a very very basic task. It should literally take like 5 minutes to knock out a wolf3d level complete with doors, some potted plants, etc. I mean assuming you have all of the graphics ready to go.

I guess I might try it by defining cube blocks and just making a 2d array in code and manually generate the level. A bit of up front code time but once the engine is done it will be super easy to adjust levels.

It just boggles my mind that something like this isn't already built in. But anyway enough bitching about it. lol

 

Nonsense! It makes me feel great!

Spoiler

 

Okay, unfortunately this won't help you out @imaginaryhuman but I did another test of creating the map in an array in code and other than having to refer to the documentation about how to create a GO from a prefab (I stopped using prefabs about a year and half or so ago... ah yeah instantiate) it was very quick & easy and works great.

But then I found looking at the map in code was pretty damn confusing when I increased the size so I converted it to read the level data from an image... this image in fact...

And that works much better. Of course, it just loops and at every cell (pixel) creates a floor and ceiling and then checks the image to see if a wall is needed or not. Obviously, I will need to update it to allow for adding decorative objects and doors but that should be easy enough. Just use brightness levels of grayscale or better yet color coding.


I have some texture issues which I'll need to fix by creating models of the cube and texturing outside of Unity. At least as far as I know there is no way of UV mapping inside Unity. Anyway, that is a simple thing.

So over all... again going outside of the Editor and it's very easy and now completely based on building a level in an image which is quite flexible.

 

I don't want to be a jerk but what are your coding skills like?

I've not run in to many issues with anything in Unit that wasn't my own fault. Of course I haven't used the animation or terrain systems yet.

 

You were either very lucky or need to tinker with unity more.

For example, after some of the updates, I've encountered issues such as:

1. Animation system behavior suddenly changing and animation events firing during transitions (practical result: double fireballs).
2. Default canvas scaling values suddenly changing ( result - HUGE or blurry text)
3. Post processing effects not working in scene view (fixed in 5.6.1, present in 5.6.0f3)
4. Physics.OverlapBox crashing android build (workaround: custom collision system for android)
5. Unity editor suddenly breaking after alt tab - red text/unresponsive controls everywhere. (Introudced in either 5.4 or 5.5, not sure if fixed)
6. Breakpoints not working in Monodevelop (present in 5.5..5.6 currently testing if it is fixed in 5.6.1).

Mecanim has oversights such as:
1. No IK target bones.
2. No weapon bones.
3. No handling inverted knee creatures with non-standard posture (if you plug in a werewolf into a game, mecanim will break its neck)

There are plenty of issues you can run into which "aren't your fault".

 

It's cool, I've been coding for about 15 years? Used multiple engines / frameworks from torque / QT / LWJGL / Cryengine and I'm currently coding in C++ w/ Unreal engine.

Also not trying to be a jerk here either (more of an assumption only), but if you've not used the animation or terrain system.. I'm guessing here you'v'e never tried to make a 3D game of any real scale? Also you might of missed the bugs list?

P.S there generally is always is a workaround, it's mostly a matter of time.. When you're working on a challenging project, time is important..

 

There is tons of mobile games using 3D tiles made with Unity without any issues.I really don't understand your struggle with such easy to use plugins ?

I think you are wrong about making levels, it asks lot of time to make them well balanced and interesting level and play test it enought until you decrease your expectation.
Anyway, there is already plugins like 3D tile level editor and quick object placement like Octave 3D or Gena or complete levels generators like Deadlus or Dungeon Architect (you seem to try to find escuses to not make it lol )

Why not making a new version in some outdoor open environment ?

With Probuilder to make levels and picking up a game plugin it should not be so hard
Shooting RPG Kit : www.assetstore.unity3d.com/en/#!/content/42204
Action Game Kit : https://www.assetstore.unity3d.com/en/#!/content/12359
Top Down Shooter Pack : https://www.assetstore.unity3d.com/en/#!/content/70918
Coop Shooter Game Kit : https://www.assetstore.unity3d.com/en/#!/content/46744
On Rails Shooter is perfect for you if you want to go it easy : https://www.assetstore.unity3d.com/en/#!/content/73628

If you don't know how Unity fundamentals to mod those game tamplate plugins , Unity is not the tool for what you want to do.

 

@zenGarden I'll check out all of that when I get off work.

On the level design being a very basic task that should take 5 minutes... I meant it should take maybe 2 minutes or less on average and 5 minutes max (if a person is really going all out with multiple wall chunks, several different decorative items, doors, large level, etc). But that's for just doing it period as in just build a level any level for testing. Was talking about the technical side of the building... the actual building process itself with no worries on design at this point.

I'll have it that way next time I work on it. I'll add support to define decorative objects, doors, etc in the map image.

 

For my skillset and abilities, Unity is the engine that most works with me for the games that I would like to complete in a timeframe that I would like to complete them at the level of quality that I expect of myself. Before Unity, I had written a half-baked crappy OpenGL engine from the ground up, tried Torque, played around with other engines/libraries like libgdx and XNA, then spent a lot of time with the C4 Engine (now called Tombstone). C4 is a C++ engine that I really loved using, but the more I slaved away at my game(s), the more I realized how far I was from completing them. I dabbled around with Unity 4.x, and brushed it off, because it doesn't expose its source. The dev workflow was very cumbersome, and I couldn't be sure if I would ever overcome that feeling.

But I finally put my foot down. I needed to FINISH games, not write tool after tool to fill in gaps here and there. I would never be able to reach the top of Mt. Everest. Unity provides a gondola at the base of the mountain, and the Asset Store makes that gondola travel even further, potentially getting me halfway up the mountain.
The Asset store was the difference maker. C4 did not have an extensive amount of supporting tools, and at the very best, gave me a good set of hiking gear.

Over time, I've realized that most functionality of Unity that can be done in the Editor can also be done in script, and I have the luxury of choosing which option is best for my dev needs. So, I can import or create assets in the editor, or in code. I can create components and gameobjects in the editor, or in code. I can assign textures in the editor, or in code. I can create scripts and data without having to attach them to GameObjects (again, in the editor, or in code). I can create game logic in the editor (though I never would) or in code. I can create animation state machines in the editor, or in code. I can even promote script to native code if I really need more performance. This flexibility has eased my misgivings about using Unity.

The Unity Editor, to me, is not an editor as much as it is an Advanced Debugger. You can inspect your game's objects and properties while it's running, or use the traditional method of breaking in the IDE debugger. I find that both forms of visibility ease the dev process.

For me, I don't see Unity as an obstacle at all. It's not the bottleneck. I would say about 90% of my time is working in Visual Studio, Blender, Photoshop, or a Python IDE, and Unity is just required glue to build and launch the game. I would benefit more from improvements in those other tools instead.

I don't find building inside the Unity Editor to be efficient at all, but that doesn't matter to me because, as I mentioned above, most of my Unity development happens outside of Unity. I always thought that building levels in the Editor was more for the beginners that don't really know where to start, and eventually, you build up to more traditional development techniques, using the editor only as a launching pad for testing/debugging your game.

Which leads me to this other section that I drafted up while reading this thread 3-4 pages ago:

@GarBenjamin
Gar, I mean no disrespect. It seems that you keep going back on believing that Unity is all about the Editor, and that game development with Unity is centered about the Editor. And to me, it gets tired. It's as if you are trying to "channel" some sort of mentality that you're supposed to do things in one way over the other. Why do you feel that the "visual way" of doing things in Unity is the "intended" way?

When really, it's all about being a game developer first, and "commanding the tools to do your bidding", rather than having the tool drive you.

Whether you develop through the editor or the IDE should largely depend on the type of game that you are making. If I were making a visual novel, or point/click adventure, I could see myself being in the editor more than the IDE. But as far as my current game, a turn-based strategy, I'm in VS a lot more than the editor.

True, you do have to launch the editor, but at that point, the editor should be relegated to asset/resource management and running the game. Everything else in your game, the actual game development part, should be done in your IDE (that works with Unity) of choice, and your art/music tools of choice.

I just don't understand. After all these years, have you not set up Unity to work with your development style or are you just playing devil's advocate?

Don't get me wrong. I think it does suck to have to launch the editor to run my game. But if that's the price of gaining the many features that Unity provides, like multiplatform support, and the numerous extensions from the Asset Store, I think it's a significantly small tradeoff.

I'm not saying that you should just stop discussing these issues, but I think a large part of the community would love to see GarBenjamin progress forward rather than question himself, and command Unity to do what he wants, rather than always reading "am I doing things the Unity way, because I prefer to do things this other way", when I bet you CAN do things your way while still using Unity.

 

Excellent post and points. Well... the reason I think the Editor is the way Unity dev is supposed to be approached is because I keep seeing so many posts talking about it and how powerful it is, how much it helps with game dev. So I am just trying to understand that and wish I could get to that same point myself. However, like you I always find it much better to go to code. But it could be I (or people like us in general) are missing something.

I mean I can definitely stop posting about the Editor. lol It's more about me wrestling with trying to get to the mindset so many other people have about it and my frustration in doing so. But yeah I can not talk about these things or certainly just say screw the editor again and go back to code oriented.

 

Sorry if I missed the main highlight, but what is it exactly about the editor that gets you? Are you wanting more of an LWJGL layout? Where you do nothing but code stuff and see on a render screen what happens?

Because as far as I see it, Unity can still be used in an entirely data driven event system.. It's just cool that you can expose features to the editor for playtesting (like pub vars).. But holistically I'm not sure how it's different to any other framework / engine that's released.

 

ha ha yeah I took this to "the editor" I guess without meaning to. Where the editor comes into play is from what I understand most people (based on posts) build their stuff in the editor. With the example Wolf3D I wondered how people would go about it. Thinking there is an efficient way of doing it (building a level with doors, decorative objects etc).

When I try it in the editor it was a pretty cumbersome slow process. Starts out fast of course but gets old quick. So yes you are right. I can use Unity as just an api and that is where I had ended up a year or so ago. And last night i wrote a script to parse data contained in an array in code and build the level and also to parse the data from an image and build the level.

This way is of course a bit of time up front but super fast from here on. Literally a level can be knocked out in 5 minutes (not a masterfully designed level but "a level") and I just wondered... wanted to know how people would do it. Like how do they build the levels in the editor without spending 15 mins, 30 mins even an hour or more just to make a prototyping level. OR maybe nobody really cares and is fine with even spending hours on a prototyping level I dunno.

 

That's it. That's exactly it. It's tedious to place tiles directly into the Editor as-is. So, building game-specific productivity tools like you have is definitely still a good way to go, and I don't see this as "working against the Unity way". Other options are to read/write XML or JSON data files, which is less convenient than looking up a bitmap image. Yet another way, is to augment the Unity editor by writing custom extensions specific to map building, like snapping, unit object prefabs, etc. This goes down the path of the ProBuilder asset, which affords you the choice of whether you should spend time rolling your own solution or using an already-built asset. Yet, I'm pretty sure there are other assets that have different techniques for placing tiles in the editor. And yet, another option is to leverage the very popular Tiled Map Editor, implement a conversion between the Tiled format, and something Unity can understand; only to discover that there are already some Unity assets that already do this!

Ultimately, your way is a solution, and one that works for you to make you as efficient as you can be. It may be different for other developers.

Now, I have to step back a bit and talk about tools dev. @ShadowK and I mentioned independently that it sucks writing tools, and this definitely would be a tool, but there are low-level tools and high-level tools, and I'd consider this high-level, basically a gameplay tool rather than something like an animation editor, or shader editor, etc. So while you still have to write tools to improve on efficiency for larger/longer projects, it's not nearly as much as if you start from a barebones API or library.

Pretty sure you know some or all of this already, but maybe it's good to read from time to time.

 

Not only is it not working against, it's actively working with...as I mentioned before, the editor is extensible for a reason. It's futile to think that it's possible to make some kind of ultimate built-in level editor that would magically work for all games.

Nah, I don't mind it. If you look at the credits for games, they always list people who wrote tools.

--Eric

 

Also the editor is meant for artist and game designer who don't like pesky sequential text instruction they find impossible to read, so it's more of a sugar that catch more bee on top of the usual coding stuff.

It's still a bit slower than blitz for code when you aren't using pesky component and oop prototype and just want to set up and call everything in a neat sequential text instruction but let's be frank blitz3D is just a bit more "hi level" than c#

 

The editor is powerful because it is easy to extend. Not because it is good by default.

Basically, you could put any data in there, visualize it, add all the tools you could possibly think of and then use them.

It is a good blank state.

By itself, however, the editor is nod good. Object positioning tools are not as good (inferior, to, blender, for example), as, say, those in blender, and there's plenty of awkwardness everywhere.

Basically, the main interesting point is inspector and component architecture. Not the scene view.

 

Ah thanks guys. Now see that makes a world of difference. So in reality people see working in the Editor actually building directly in there "as is" as tedious and frustrating as I do. What you all enjoy about it are the other bits like easily tweaking parameters, extending inspectors etc.

Well yeah I agree on that stuff. That IS useful. I thought people were actually loving building everything out in the Editor scene and that is what I couldn't understand what there was to love about that.

Building little tools like this right in code I enjoy. It is quick and easy. I wouldn't get into trying to do it in the Editor because it just adds a layer of complexity and overhead I think. I'd be more inclined to build GUI-based dev tools in C# windows applications and have it spit out a file.