Does Unity make game dev too difficult?

I shouldn't have been so quick to paraphrase it as I had. I like writing tools too, but my point was better put by ShadowK:

Or maybe even, heaven forbid, completing it?!?! The answer is a resounding "Yes".

 

Completing stuff is certainly a great thing but in this case I think he means not using Unity. And it would be interesting to see what he could come up with in Unity. But I definitely get his point and can't knock him if he decides to go with UE considering how many other alternatives I've tried and enjoyed the past year or so.

I know it probably seems silly to you guys but I really appreciate you folks sharing that info about the editor. I kept thinking "what in hell am I missing? There has to be some part of working in the scene in Unity editor that I just don't know about!" even watched several random YT videos and all were the same slow tedious process. So was going a bit mad trying to figure it out the "secret" that would make building inside the editor a very different much more efficient working experience.

 

Not sure about "as you do", part, but yes. It is not great. I could even say that for pure level construction blender and unreal provide a significantly more pleasant experience than unity editor. The main attractive point is coding framework and component-based approach.

You'll waste a lot more time by trying to make a native windows application, though.

The approach unity uses for inspector and widget GUI allows you to QUICKLY make massive gui windows and complex controls through code without babysitting individual button objects. If you love code-based approach and messing with blitz3d, I'd expect you to love unity inspector gui code. If you haven't checked it out yet, you should.

Also, Native windows application comes without glue and 3rd party libraries included. You'll have to re-create or re-integrate scene graph, collision routines, physics, audio, enforce compatibility with unity... it is a massive timesink with no gain.

Not to mention that C#/.NET is not the best choice for GUI application. Qt/C++ is better.

 

I meant just tools that generate data, perform processing, etc. When I worked in Blitz and C# & XNA I would often knock out little utility apps in C# Windows forms. Like I wanted a way to easily define hit boxes on sprites so built a system for that, etc.

C#.Net Windows form app development is way faster and easier than Unity IMO. I mean it is just so geared to it. Plus I have been developing apps for my career for a long time now. Desktop apps, web apps etc. For this kind of thing I don't need any Unity specific stuff. Can easily load images in and work with them in a C#.Net app without any 3rd party libs needed.

You know you can programmatically add all controls too, right? Everything is just an object and can build entire display programmatically if you like. I've done that but only when needed. Usually it is one of those GUIs where the user can add items to a visible collection and then that will appear along with little button to edit, delete, etc. 99% of the time though I just knock out the GUI design using the drag n drop interface.

To me the difference between Unity GUI stuff and doing it in a normal win form app is night and day. Probably just a matter of personal preference or what a person is used to.

If it was something I was thinking of putting on the asset store... that I can see people definitely doing the development in Unity. So all Unity users can use it. But I can throw the tools out there and any Windows folks could use them at least.

 

Alright well @neginfinity I was mainly interested in seeing what you'd come up with for building the levels out and so forth for the "kit". Because again I thought there was some secret knowledge everyone had, mystical hot keys or something for working in the editor (I do like the Ctrl while moving to move in blocks that is helpful).

I fixed the texturing issue and having gone back to using the code approach of course it is dead easy to build levels and populate the game world.

Then I redid the textures slightly and even found inspiration to knock out a red demon dude sprite just to see how it would look.


Anyway, the big mystery is solved as far as I can see. The way to do it in Unity is to not do it in the Editor. Seems a bit strange in a way since I am sure they made that scene editor with the whole point being for everyone to use to create their levels. The important thing is I won't waste any more time trying to find the magical mystical secret of it!

Some time when I feel like doing some game dev I will mess around with this some more and make a little game out of it.

 

Finishing things is overrated, Ikea keep forgetting to put complete kits in boxes.. Doesn't seem to affect them.!

A decent high quality / moddable demo would do me, after that meh.!

 

Make an engine, good gameplay, a good story beginning, make it moddable and let fan finish the story with fan fiction while you rack in money of infinite early access and cut on selling mod ROFL

 

The problem is that in any normal gui library, if you programmatically add a control, you need to babysit it. Meaning make an object hide/show/delete/create it, track messages, etc.

In unity (in inspector/scene gui), you don't need to create an object, and don't need to babysit it. This makes creating complex layouts where controls appear/disappear very easy. A GUI control is a function call. No function call - no gui control.

Also, I'm not much of a fan of C#/.NET approach, and honestly think that Qt offers more punch/flexibility compared to it.

Still working on it.

Also, this statement doesn't sound right to me.

 

It's a 3D scene editor, the same as any 3D modelers 3D scene viewport existing on earth lol
You can place any objects, rotate, scale them, it's an universal way to you make your level. I think you are goind too much philosophy instead of practical.
All time spend making your debat that will lead you nowhere, you could have employed it better learning some basics about Unity editor or started making some game level. It looks like you really don't like 3D editors, 3D art workflows and tools, and you only like pure coding.
Anyway, you can continue this long discussion and just proscratinate any game you would like to start lol

 

Did you read the last 12 or so posts of the discussion? Or at least the post you replied to?

It was definitely worth discussing. And no time wasted on it. In fact it will greatly save time from being wasted chasing unknown info that does not exist. I had already wasted time on numerous occasions working in there trying to streamline building as well as testing out paid set. One problem with using paid assets is I couldn't then throw the source out to PD to give someone else a jumpstart, etc.

I've got the solution for it now. Just go straight into knocking out the simplest very efficient custom level editing system I can think of. Which is basically normal anyway but like I said I thought folks were doing it all in the editor in a high speed manner using some kind of tricks or something I didn't know.

 

Gamedev : Some Assembly Required.

 

You mean general game development subjects ?
Because there is no unknown infos about Unity, there is infos everywhere about anything like coding or editor, you can make yourself your opinion and test it as much as you want.
You are right perhaps this will avoid you to waste time trying to do something in a way that doesn't suits you.

 

I think you're reading too quickly. I meant building levels / game world in the editor. I thought everyone liked the editor so much because they were all building in a high speed very efficient manner using some kind of tricks or other things not common knowledge OR at least something I didn't know and never came across in all my searching on and streamlining tests of the subject. But then it finally came to light no that is not the case.

 

If you make a small game or some even smaller mobile game, some wave based game with arenas levels or small static levels Unity editor is very sufficient.
Otherwise, the solution is always the asset store plugins.

 

I didn't plan on doing any more game dev stuff but with a 4-day weekend coming up and the level building solved I am almost tempted to build a little game demo. Maybe. I guess if it's a rainy weekend I might.

 

The idea of the scene view is that you use it to place stuff that you made elsewhere. Build the level in Blender or whatever, import it, place it in the scene view, place lights, characters, etc. They did add some vertex snapping features so for certain games it might be feasible to use the scene view as a level editor, but that's not really what its purpose has ever been.

--Eric

 

I've been actually thinking of just assembling scenes in blender and importing it into project. The issue here is that things get a bit awkward when you want prefabbed behaviors all over the place, but this can be fixed with another script which will scan dependencies in original blender scene and attaching behaviors accordingly..

Assembling in scene view is possible, but tedious. Basically, it requires creation of 3d tiles with uniform spacing and pivot at corner. In this kind of setup unity's snapping is sufiicient for building a level.
----
On related note, one annoying thing in scene view are those tiny pixel wider arrows.

 

That makes a lot of sense. I didn't realize that because I've seen loads of videos where they build simple scenes in the editor OR show an already built scene and tell you they built it in the editor and just build your own in there and then follow along.

It's definitely doable it just isn't very efficient IMO. Like comparing manually laying out a 2D level tile by tile in the editor or using SpriteTile. Both ways work but one way is a whole lot faster and much less (basically none) frustrating. That's all I am after. Anyway thanks to you folks for clarifying.

 

I don't think it's inefficient. The way @Eric5h5 described is more or less exactly how I'm building my own game. I build my levels in the Unity editor scene view using 3d assets I've already made and place them by hand, manually adding lights, and so on. You can of course speed up the process by building your own Unity editor tools based on your specific needs.

 

Based on numerous videos I've watched many people build right in the Unity Scene Editor. It's never what I'd consider efficient though. But that doesn't mean you haven't arrived at an efficient workflow. Good deal if you have.

I think a lot of this kind of thing comes down to how different people view time. It's kind of like the graphics thing or anything else for that matter. If I can design a test level in 1 to 2 minutes I'd consider that efficient. Not a "final" level. A test level. Another person may find 15 minutes efficient and still another even 1 hour or more.

That's a very nice looking scene!

 

So, regarding unity editor, unity editor extensibility and Doom clone I mentioned earlier.

Obviously, I did the least reasonable thing and wrote a level editor first.

I'll be making a WIP thread shortly.

--edit--
WIP: https://forum.unity3d.com/threads/wip-doom-i-clone.472815/

 

After considering the original question of this thread, I will give my point of view.

To make it short: yes, I believe that Unity (and other engines too) has made the life of the developer too difficult.

LONGISH PHILOSOFICAL REASONING THAT YOU CAN SKIP:
I will reason my answer, but I don't expect everybody to agree with my way of thinking.

I am 54 at this moment and I can remember, in the middle seventies, when I was living in Paris, playing Pong with special dedicated machines. And it was entertaining. Let's say it was entertaining with intensity 7 in a scale from 0 (total boredom) to 10 (maximum level of entertainment).

40 years after, we have spectacular games, that cost maybe a hundred million dollars to develop. And they are not able to provide entertainment of intensity 200 in a scale from 0 to 10. From my point of view, maybe they reach 8 (other people might have different perceptions about this).

So, the most important factor for entertainment is not how complex the game is, but the fact that we can enjoy a videogame, even a very simple one, since this is a totally new experience compared with not having any kind of videogames.

In the past, if you were able to program in Assembly Language, you could develop a simple game that was able to provide entertainment, and you would be able, say, to offer entertainment of intensity 6, while your competition, who maybe lacked these programming skills, was not able to develop videogames. So, before Unity and other engines, the difference between you and your less skilled competition was 6 points of entertainment. In the past, you were fighting to get 6 points.

What Unity, and other game engines, has done, is to make easier for everybody to develop games and lower the barriers of entry, and have created a situation when the best videogames, which are maybe funny level 8, have to compete with simple videogames funny level 7. So, after Unity the difference between you and your less skilled competition is 2 points of entertainment. Today you are fighting today to get 2 points.

Since, in the past, the most able programmers were competing against people who could develop no videogames at all, the situation is more difficult for (very skilled) developers today. That's why I say that Unity has made the life of the developer more difficult.

I don't expect a lot of people, or maybe even nobody, to agree with me, but that's how I view the situation.

 

I had the same issues about 3D art, i experimented a lot to find the best tools and practices to keep making 3D art fun and not frustrating.

In the old days there was also many games with bad games or with bad gameplay.
The challenge is how good can you make a game ? graphics, gameplay, ideas, involving characters and background, this is a whole : Shovel Knight, Axiom Verge, Salt and Sanctuary, Ori , HyperLight Drifter , Yooka Laylee ,The Witness, Inside, Stardew Valley ...
It's really a matter of keeping something interesting and appealing in all areas.
There is tons of borring and very generic or copy paste indie games, and the good ones are very rare.
Anyone have the tools to make a game , but like in old days to make good ones it's all related to talent, nothing has really changed.

 

That looks interesting. Seems workable for more involved design such as Doom and probably very fast for building Wolf3D style levels where all is on same height and everything builds either straight ahead or 90-degree turns. And I think it was a great decision to start here because it is one of the biggest "pain points" IMO anyway.

Probably useful as a quick and easy generic building tool as well. Am interested in seeing how texturing works in it.

EDIT: forgot to mention great work! I'd have no clue how to build something like this inside Unity. I guess there is a way in Unity api to actually gain access to the vertices themselves as well as move them.

Anyway I'll probably work on my demo project a little this weekend using the image-to-level system. I need to flesh it out more to support placement of objects and enemies via colors but that should be straightforward. Just a matter of doing it. First I should get player moving around and firing. I knocked out some graphics for casting magic last night but that was it.

 

Semi-related, I just fired up Doom 2016 for the first time last night, and I tried out SnapMap for about 30 seconds (well, after the 5 minutes of load time), and I was unimpressed. At face value, it just looked like a bunch of components that you snap together, a la Lego, and it didn't feel as empowering to me as say, the original Doom mod tools. I used to play with DEU back in the day, but I recently stumbled upon Slade. I am more interested in this than SnapMap, probably because it scratches that nostalgic itch. To me, this is the first sign that I'm really getting old. I'd eventually hang up my game dev projects and go back to modding for OG Doom. Lol.

 

Because it is adressed to console market also and casual players that want to quickly make new maps.
It's console map editor , not only PC so it is not adressed to people that will mod textures, 3D models, or use a mouse to make complex levels.

 

I need to buy the new DOOM again. I grabbed it last year and was waiting for winter months to check it out. Ended up boys stopped over for a visit near end of October or early November so I handed it to then when they left and said check it out let me know how it is. They liked it a lot so I guess it appeals to the early 20-somethings. Well ok that is way too broad... appeals to some people here and there like all other games.

Anyway what you are describing is not too far from what I was thinking about with my image to level creation system. I could use images to define "prebuilt" corridors and rooms and then kind of do a random generation thing. But I think that is way overkill adding more time for no reason. At least at this point. Base game is critical first. Then "fancy crap" can be added later easily enough if desired.

 

Alright, more or less done with the editor part. It is suprisingly useful, though it is missing few polygon editing commands.

I'll be posting the rest in the WIP thread.

Interestingly... it should be possible to make multi-story levels in this with very small adjustments.

 

Looks like you get two assets out of this project. Quick n Easy Level Editor and the higher priced DOOM Kit that also includes QELE.

 

@neginfinity Very cool. Thanks for sharing.

 

That's a good idea.

 

Beyond working in editor building levels / game world I am sure there are other bottlenecks. I think as I run into those I will document here. Basically whenever something can't be implemented within 10 to 15 minutes there may be a bottleneck. Depending on overall scope of course but I say within 10 to 15 minutes with the idea being larger goals/tasks are broken down into a set of multiple smaller tasks.

Anyway I'll see what I can dig up if I work on it this weekend and I think I will.

 

Thanks.
I'd suggest taking a look at the asset store again for editor tools, it honestly sounds like you may indeed be missing out on what the rest of us have figured out a while ago. There's plenty of tools on the asset store such as Realtime CSG, ProBuilder, etc. which allow you to make levels within the Unity editor in minutes. There's also parametric modeling tools like Archimatix. Or don't even use them at all, you can still always build test levels out of the basic primitives in the Unity editor. Before I found the editor tools for me, I built a simple editor script that generated a minecraft style 2d array of cubes and I'd build the level by simply deleting the cubes I didn't want or moving them around. It worked great.

Also, you'll find that the part that takes time isn't actually building the level, but designing it. Placing a bunch of objects can be done in seconds, what takes time is figuring out where they should go, seeing how it feels if they're somewhere else, swapping them out for different ones, etc.

 

Well I decided to get some movement in. No turning at all just forward and backward movement with the little bobbing up and down motion.


I think it might be better to not actually bob the camera up and down but instead to bob the weapon (in this case the players hand) up and down. So I will try that out and see how it goes.

This did take longer than I would have expected. But it is that same ole thing I run into in Unity which is even the simplest things become somewhat complicated simply due to the architecture. And so every time I work on a project it seems I do it in a different way always trying to find the absolute easiest and most sensible way to do it. And that all is not a griping session it is just sharing the reality. Well my reality anyway.

Like this time around I already knew the preferred way to develop in Unity is to have many tiny scripts stuck on a GameObject. And I knew that having multiple scripts work together is the first issue to get around. Which can be done in many different ways of course and I've come up with many ways and previously tested.

So this time I came up with this...

Player GameObject...

has a script named PlayerConfigure and this is where all of the params are set.
has a script name PlayerMove and this handles the movement of the player including the bobbing up and down.

Behind the scenes I made a singleton PlayerObject class.
Both scripts have a reference to this single object.
At Startup PlayerConfigure loads the params (movementspeed, bobmovementspeed, etc) into the PlayerObject class.
At Startup PlayerMove configures the other PlayerObject variables such as player position, direction currently facing and so forth.

During Update of course PlayerMove just checks for movement requests and moves accordingly. The movement calculations for forward/backward movement as well as the bobbing motion are done on the _player.v3Position variable and then this is loaded into the Player GameObject.transform.position property.

And I know I have already broken the "standard" Unity protocol to a degree here because people would be hooking up character controllers or other such things. But to me this is such a simple thing I just don't see why all of that stuff would be needed. It shouldn't be IMO.

I see it as just moving a dang object around and checking for walls and so forth. No need to turn a very simple problem into a complex solution using physics engine and so forth, right? lol

BUT saying all of that this is working fine so far. I guess I just wonder if my decision will come back to bite me in the ass later on. I guess I will find out. Ha ha.

Well that's it for now. I might get inspired to do some more work later.

 

Well I just have it in my head now forget using the Editor. Just build what is needed. So my little define a level inside an image is working fine and I will use that extending as needed as I go along. I have no problem coming up with solutions for this and building my own little tools. Like I said before I just thought people were building everything in the Editor and perhaps knew some tricks to make it super fast to do so.

The image to level system is super fast. Just modify the image as desired and presto level is auto generated at next run accordingly. Actually could be used as a super easy way to allow modding / creation of custom levels.

 

Well, it's your call. Using an image editor to build the map is pretty neat, I can see that being powerful especially since like you say it opens the door to modding by allowing users to upload their own images. Although I imagine you'd be limited in terms of complexity for stuff like multiple floors or curved walls and stuff like that.

Here's ProBuilder in action inside the Unity editor...

 

Here is an example of the kind of things I wrestle with in Unity.

Think of this as just "pub talk".

For a Wolfenstein3D style game I currently am building levels from images. Straightforwardness enough.

I have a player (basically just camera there is no visible player or hand/weapon yet). And I have the player moving through the level well moving forward and backward.

Here is another decision point again due to something that I'd normally see as simple being a little more complex here.

Obviously, I need to check for walls. So this means adding colliders to all of the walls. And then it means performing ray casts in the direction moving (or doing a sphere cast). Seems like a lot of work just to do something so simple.

What I would find simpler is to just have a 2D map (just an array) that tells me if a wall is in a given cell or not. The X, Y of the map of course would correspond to the X, Z of the game world. A straightforward mapping. No colliders needed. Player moves just shoot ray in direction facing and check that map position for a wall. When I say shoot a ray I mean of course just do a loop and "move" a position starting at the player's position inside the map and moving in the direction they are facing.

So... I was about to work on this again and generate such a map array at the time the level is built from the image.

But... I kind of just wanted to discuss this with someone here. Damn I tell you it would be nice to have someone local who actually does this stuff just to talk about these things. lol

Anyway, although this seems like a much simpler more straightforward way of handling collisions (and pathfinding for enemies later, etc) I also know once again this would be going against the way a person probably should be doing it in Unity, right?

For my last little 3D maze type game I used the Character Controller and that did work very well but like I said it just seems strange to me why we need all of that stuff for what is basically just a 2D game rendered in 3D. But then with Unity being a 3D game engine maybe that is the part I keep forgetting about.

Anyway... thoughts on any of that?

 

Oh yeah they are good. I wasn't really into ProBuilder (at first it seemed great but in practice I found it kind of tedious) but I did find one that worked pretty well. Forgot what it was called now. I bought 2 or 3 different 3D block building systems a year or so ago and tested them all.

One thing that kills using such things is like with this game. If I actually make it or at least a one level demo I will probably throw it out as source in the PD on bitbucket/github. And I can't do that using a paid asset.

This simple image method is super fast to design levels plus if I do complete a level and then decide to put it out there in PD or whatever I can.


That is the image scaled up 8x. In reality it is 32x32 and each cell is 1 pixel. So the doors for example (the white for normal unlocked doors and purplish, blue and green for special locked doors) are really just a 1 pixel dot on the map at normal size.

 

Talking about "game difficulty", just out of interest what's everyone's thoughts on top down games? Are they a bit too common to be worth doing?

 

This hasn't come out yet but I think it looks awesome as far as graphics go and I think it looks solid as far as the game itself goes. It looks like a good bit of destruction and fun. Gameplay is scaled down more than what you want to do but actually that is another reason I am showing it to you (I mean maybe you've already seen it I don't know). People like the graphics a lot and are looking forward to the release. Coming sometime this year.

This is a great example of a very dialed in game scope I think. I mean sure it's still a lot of work but this I think is definitely solo Indie possible. And once this is done the next game can build on it adding in rpg elements, quests, unfolding story, maybe add two character classes, etc. As is it seems like a good solid fun game that is also essentially the foundation of making something like a Diablo style rpg.

Of course, screenshots and videos are one thing, right? If the game comes out with terrible controls or other flaws that will ruin it and the wait will have been for nothing.

 

Not my thing. Can be fun as a twin-stick shooter or a gameplay element.

I tried procore before, and didn't like it. It felt half-finished compared to blender - because of focus on polygonal modeling. SabreCSG was much more interesting, due to using CSG. I think archimesh(?) package offfers something comparable.

 

I quickly glossed over 36 pages of single player RPG's and they majority of them were top down.! But you have games like Pillars that did amazingly well.. Anywho, just a thought..!

 

Alright... just an update. Now I see why I used the CharacterController last time. I had probably done the same thing then building a map too.

The benefit of the charactercontroller is it auto-detects collisions with the walls AND if I remember right it also automatically handled the sliding along the wall.

I just implemented the map and a simple collision check and this works fine. But then while testing I was thinking when I get turning in this will be a little trickier. Oh yeah and then I need to implement sliding. Ah now I see why I used that CharacterController. It does save work after all! lol

However, I also seem to remember I couldn't use the base CharController as is because of implementing the bobbing up and down motion. Seems like I had to update the script to provide a way for me to know if the player was currently moving or not because there was nothing available to tell me that.

Alright next time will implement the CharacterController. Been a while since I dabbled in a 3D FPS style game in Unity. But I'll get my head into it sooner or later.

I don't know though it seems like it is always 6 one way half a dozen another. Instead of using CharacterController and then hacking the script to do what I need I could just implement wall slide using current system. Also seems like when I originally did it I converted the CC from the UnityScript to C# because couldn't find a C# version. I'll have to find that other test project and get it from there.

So... yeah this is the kind of stuff one runs into. Basically just continually bumping into something. Maybe I will go ahead and implement it all myself and see how much work it all takes. Be good to know for the future anyway.

Really thinking N6 would be the way to go to actually build a game like this though. I mean all of this stuff is already taken care of no conversions (such as flipping data around to match Unity rendering when checking for wall), etc.

I might just have a play around with N6 this weekend and see how long it takes to do it in there. Or maybe I will just relax watch Ancient Aliens and drink a couple of beers. lol

 

@GarBenjamin

Pub talk on:

You are wrestling with yourself again, there is no unity way. It's only your way. If a picture to map gives you the functionality you need + you are comfortable with it, that is the way. Just make sure to think a bit beforehand if the picture to map gives you all you need - it very well could, but that depends on the game design

For game variables, I found scriptable objects to work really well. I currently use them as a config SO, which is accessible through a singleton game manager. The config SO has other SO's in itself for say text, prefabs, variables, color palette, etc. I don't use the editor much and this system works well for me

Pub talk off.

 

I just managed to come up with a more or less working version of a custom character controller with camera management feature and it required 60-70 classes, in my case.

I know, it can probably be done with a couple of scripts with even more features than mine. But I was just determined to do it in the most convoluted way I could imagine

 

Yeah thanks man. I just grabbed a nice cold beer and on my way back to living room was thinking that. Well I don't know. I think there is a Unity Way. And my frustration comes from going against the grain.

Maybe in my desire to greatly simplify things (because to me it should all be super simple... basically it is just a 2D map)... maybe the problem with this approach is it is all basically not the way Unity is intended to be used so it ends up instead of being easier & faster it actually becomes more complex & time consuming. Maybe. I don't know. lol

I think I will just go ahead and finish it off using the 2D map array.

And then maybe when I am done I will rewrite it all to use the CharacterController so I can compare the two approaches.

I do think I will test out N6 this weekend though. Be stupid not to if it would really make it like 40% to 60% more productive building an actual game.

 

60 to 70 classes just to move a character around? How can that be possible? I don't even see how you would have 60 to 70 different methods.

 

Yeah, just a typical WASD + mouse look with a slightly improved 1st/3rd camera control (visible body parts, and etc). The source code is linked in my signature so you can see it if you like.

It ended up that way, as I wanted to experiment with a pure non-monobehavior approach and a kind of overkill layers.

 

That remind me when I was looking at unity the first time, I looked at the specs for the chara controller and nope hard out of it, later report of use gave me reason as I anticipated exactly the type of problem people where going to have. I want to do complex 6dof 3d game, unity does make it hard for me lol

 

Oh yeah that is right. You are more into the code everything yourself way too. I forgot that. But did you find that maybe you were able to make this 60 to 70 class system in about the same time as you could figure out using Unity's various stuff? Or do you think your way was much harder and more time consuming.

I generally revert to throwing everything out and programming it all myself because I run into bump after bump after bump and the time just adds up to the point where it is faster to do it from scratch.

Again though I don't think it is a problem with Unity. Obviously it is a great game engine. I mean just look at all of the games people make with it. It is more of a problem with me having done a lot of this stuff before many times so I think why in heck is this taking so long. OR my past gets in the way because I am thinking of a certain way to do things and that is not the way they are thinking. lol