Does Unity make game dev too difficult?

I definitely think that 'my way' is much more time consuming than the usual 'buy some assets, and glue them together' kind of way which I believe to be how it is supposed to be done in Unity. And I found that, in general, it's easier to figure out how to do things in the 'normal way' because I can find more information about it, like tutorials, same codes, forum posts, and etc.

To be clear, I'm not saying that a pure POCO approach takes much more time than the usual MonoBehaviour way. It's just that building such an overkill abstraction layers could be quite time consuming, as it was for my case.

But I didn't expect it to make me create games any faster at the first place, and maybe it could be the difference between our views, even though we both seem to prefer the code centric approach.

For me, it's more of an aesthetical problem, rather than a productivity one, that I found myself to feel uncomfortable with the traditional approach. As a programmer, I just want to have a programmatic representation of the game world, in which I can control every aspects of it by code if I choose to do so.

And I cannot just rely on purchasing assets and writing 'glue scripts', because I don't want to deal with third party APIs all the time, as they obviously follow different conventions or design approaches from each other, and vary widely in quality also.

But if I was a professional developer and was working in a commercial project, I would probably have done it in the 'normal way', as I'm not confident that I could meet the deadline by reinventing every wheels. But, fortunately (or unfortunately, depending on the perspective ) I'm just a hobbyist and I could take as much time as I need, doing whatever experiments I'd like to try, so I just wanted to find a way which I could enjoy creating games in, and hopefully, learn Unity itself while I'm doing it.

So far, I learned that DI and Rx can be such a great way to create a game, as they are in other projects. But I'm not that confident about that monstrous 60-70 class character controller yet. Probably I'll need some time to use it myself in some realistic context to iron out all the warts it might have.

 

@GarBenjamin and @neginfinity looking good guys, I half wanted to join in the fun, which reminds me why general forums are such a time sink and takes you away from your original projects.

If you complete something don't forget to post it up in the next feedback Friday thread!

 

By the way, I'm in the middle of writing a Java Swing (yeah... that dreaded API) like wrapper around the IMGUI, so I could create UI in such a way:

Code (CSharp):

1.     public class MainMenu : Box, IObserverHost
2.     {
3.         public CompositeDisposable Disposables { get; } = new CompositeDisposable();
4.  
5.         public MainMenu(IUIManager manager) : base(
6.             new BoxLayout(BoxLayout.BoxOrientation.Vertical), manager)
7.         {
8.             Text = "Main Menu";
9.         }
10.  
11.         protected override void Initialize()
12.         {
13.             base.Initialize();
14.  
15.             var btnQuit = new Button(Manager)
16.             {
17.                 Text = "Quit to Desktop",
18.                 Padding = new RectOffset(10, 10, 10, 10),
19.                 Color = UnityEngine.Color.red
20.             };
21.  
22.             var btnDismiss = new Button(Manager)
23.             {
24.                 Text = "Return to Game",
25.                 Padding = new RectOffset(10, 10, 10, 10)
26.             };
27.  
28.             Add(btnQuit);
29.             Add(btnDismiss);
30.  
31.             Pack();
32.  
33.             this.Subscribe(btnQuit.Clicked, _ => OnQuit());
34.             this.Subscribe(btnDismiss.Clicked, _ => OnDismiss());
35.         }
36.  
37.         protected virtual void OnQuit()
38.         {
39.             Dispose();
40.             Application.Quit();
41.         }
42.  
43.         protected virtual void OnDismiss() => Dispose();
44.  
45.         private void Dispose()
46.         {
47.             Manager.Remove(this);
48.  
49.             Disposables.Dispose();          
50.         }
51.      }

As you see, it won't allow me to do it any faster than I can do it with the game object based UI, or just copy pasting bunch of IMGUI's static method calls.

It's just that I found such a code above looks more pleasing, and easier to read than such a mess that is GUI/GUILayout API, so I have to create such an additional structure to cover its ugliness with.

 

So what you're saying is that Unity has made game development harder by the very act of making game development easier?

I agree with what your underlying argument, but not the conclusion you're drawing from it. Game development itself, which was the original question, has indeed got easier. As you say, people with little or no skill can now in fact make games where they could not at all before. People who are skilled can now use a bunch of off-the-shelf stuff to get a head start, making the creation of games easier for them, too.

What's harder is that as a result of that things are far more competitive, which you also described quite well. Making a game is easier. Making a game that people care about, on the other hand... that's a different question, with a very different answer!

 

You are right to say that, from a technical point of view game development has indeed got easier, but from a different point of view, that is, game development that is actually appreciated by customers, it has gotten more difficult.

The gist of my argument is that the mere existence of a game, even if it is less than perfect, is the major factor bringing entertainment and appreciation by customers (by far). This factor comes into play when not too many videogames coexist (in other words, as long as videogames are scarce), because it is perceived as unique or near-unique, and this factor has gotten nullified by Unity and other engines. So, what Unity has done is to "commodify" the most important factor for enjoyment in any videogame, and most people won't appreciate what they can take for granted.

The paradox is that it is very likely that the gamers of today will enjoy sophisticated games less than people from the seventies enjoyed much more primitive games.

 

Well I can relate to that. I think there is a paradigm shift that needs to occur to really embrace Unity. Again not knocking it. But for people like us I do believe there is a disconnect. Like you said... code... well that makes sense. And getting rid of these monobehaviours and some of the other stuff. It's why I would prefer to just start with nothing but a blank text file and go from there.

I don't know what there stuff does. Not what it is really doing or how it is intended to be used or why they decided to do it the way they are. How complete it is. I could learn all of these things but I think that would take dedicated study for quite a while and a pretty major shift in how I view and approach game dev. So I have done basically the same as you. Just pushed to do things in a way that makes more sense to me and through the exposure I get with their stuff I learn their stuff.

But now I do want to try to embrace it more. That was my original plan. It's just that sometimes it seems to me like this way is making simpler things more complex and more complex things simpler. I think that is kind of how I see it.

It could also be that I am just burned out. lol For a couple of months I had no desire to do anything related to game dev at all. I kind of am getting back to that point after just spending a day or so messing around with this project.

When I run into what feels like more work than it should be just to achieve something so basic it kind of makes me think why bother. Ah I probably just need a good night's sleep. I have a 4-day weekend. I am sure I will return to this at some point and finish off the player control.

 

Hang in there, and I'm also hoping to see something great coming out of the community RPG project you've been working on in public

 

I haven't done anything on that community rpg in quite a while. I wasn't going to do any game dev until maybe October or November. But after making this thread and all of fhe discussion I kind of just ended up dabbling on it. lol

 

The perspective will probably massively shift the audience the game attracts and the user-expectations. If you go down that route make sure all the other gameplay systems offer a kind of complexity that players of POE and similar games would expect. If you want the gameplay systems more like e.g. System Shock, I'd stick to first person.

 

Here's my attempt at trying to recreate most of the core mechanics from wolf3d in about 4hrs, 2hr update so far.

https://forum.unity3d.com/threads/wolf3d-in-4hrs.472957/

 

It hardly looks fantastic. I think the reason you misunderstand the Unity paradigm is precisely these kinds of assessments. There is barely a real artist here who would add something like that to their portfolio or collaborate with someone who wanted that type of look as an end product. I may be wrong.

 

I don't think anything's "too common" to be worth doing. It's all in the implementation. That's the whole reason for the resurgence of IE type games--they aren't coming from randos spamming that type of gameplay, they're coming from Avellone and Fargo and Larian--people who know how to make good ones.

 

I strongly disagree with this.

When creating my own engine, I was highly motivated. It was likely a mix of incredible levels of satisfaction AND the total absence of other people's work frustrating/annoying/hindering me.

Unity is extremely demotivating for me. Bad assets are same. I greatly dislike other people's code or design choices. I think too differently. I have great frustration to punch other programmers/designers in the face.
Custom engine is extremely motivating for me. I love my own work. I understand it. I get great desire to fix any issues that were caused by myself. I can only blame me.

I also ran a 60hr test using Unity, already having experience with it, creating a project. Then I created that exact same project in a custom engine, with absolutely zero experience in doing so, up to the same time as with Unity (60h).

All game code was entirely separate from the engines. Meaning the game simulation was not included in either 60h tests. Only engine-based things, like Rendering, Gameobjects, etc. - linking the game to the engine, were tested.

Caveat:

1. Project was exclusively 2D.
2. Project used very few of Unity's features. No need for Mechanim, no need for scene editor, no animation timeline, etc.
3. This was prior to Unity's new GUI, which was a vast improvement IMO.
4. I had years of prior Unity experience. Zero experience in making a game engine.
5. Without any Unity experience, Unity would have been so far behind it would have been a joke.

The results were

• Custom was incredibly efficient for the entire span. Very stable & predictable efficiency. Every task took some time, but about the same amount of time. From start to finish.
• Unity incredibly efficient early on & inefficient later on & had "unstable efficiency". Anytime Unity would save me time, it would drain it at insane levels elsewhere. One task may take 1 minute or is already done (0) but another would drain 9 hours while costing only 3 in the custom test. Predicting time cost of any task was very hard if it related to Unity.
• This meant that the longer the project took, the more time you'd save NOT using Unity.
• Custom performed infinitely better, with zero known bugs & full knowledge of underlying code structure.
• Unity performed fine, being only 2D, but with plenty of bugs, performance issues like hitches, and a fully closed source.
• Unity saves you more time, the more features you use. Of youre making a 2D pixel art game, Unity is horrible. If youre using 3D + mechanim + Unity features + scene editor + asset store, then Unity is amazing.
  
• Unity excelled SIGNIFICANTLY in two areas
• The Asset Store. There are assets that save you weeks of worth that can be bought for pennies on the dollar, like Behavior Designer or Dialogue System.
• Rapid Prototyping. Unity is amazing at this. So much so, I can see gamedevs using their own custom engine, but using Unity to prototype ideas & using Unity as a game tool for their custom engine.
• In every other area, Custom either matched or greatly succeeded against Unity.

The biggest difference for the engines themselves is efficiency & startup costs.

Unity had very low startup costs. Alot worked out of the box, like rendering. Custom engines have a very large startup cost. However matching Unity in 2D rendering, gameobject hierarchy, or scene management is rudimentary game programming. Maybe a day or two of work saved at best. That is not why Unity is good, unless for rapid prototyping.

Biggest Caveat: You could write your own scripts or assets to improve Unity & increase its efficiency. This would theoretically bring Unity to match more efficient engines (doubtful, but more testing is required). However it may take MORE time than if you made your own engine & didnt use Unity (for that specific efficiency fix - because the Ubity inefficiency wouldnt exist in custom, and you wouldnt have to reroute someone else's engine to do something the right way. That is a PITA to fix someone else's problem.)

 

I would like to add that my project after that test uses ALOT (almost all) of Unity's features, and I dont have any empirical evidence ready for argument, but...

Unity itself has saved me ALOT of work with this project. It is 2D sprites in a 3D world, perspective & orthorgraphic 3D camera, and makes extensive use of Unity's 'new' GUI system, mechanim, ALOT of the asset store, and latest 5.6 2d updates.

I also use the Unity Editor to build levels, to edit my item database, store alot of gameobject data, etc.

So that has probably saved me month or two of work. The asset store has saved me untold amounts of work & assets like Forge allow me to have multiplayer (when I would otherwise skip it entirely in a custom engine.)

Like any engine, the value is dependent on how much you actually use & what features your game needs.

 

@CarterG81 thanks for sharing all of that. Great information and when you say "Anytime Unity would save me time, it would drain it at insane levels elsewhere. One task may take 1 minute or is already done (0) but another would drain 9 hours while costing only 3 in the custom test. Predicting time cost of any task was very hard if it related to Unity."

That exactly matches my own experience. That is something I have noticed too is that it is so weird that it saves a lot of time on some things (sometimes even more complex things) but then it actually makes other things (sometimes very basic things) more complicated and time consuming. I don't know it's just odd although makes sense I suppose due to keeping with the rest of the architecture.

You've also hit on something else that I've thought about the past few years. I do think if a person is wanting to make big games (or as I like to say big ass games), AAA-like games or at least games that are "in that direction"... as you say "Unity saves you more time, the more features you use. If you're using 3D + mechanim + Unity features + scene editor + asset store, then Unity is amazing".

So for me... I have no desire or time to focus on any of that stuff. The scope of games I see as realistic for me to tackle are something like a Wolfenstein3D style as in the core but then add in some rpg elements such as gear to find, leveling up, maybe a shop to buy and sell gear, possibly an NPC or two for some light quests within that environment.

I think that is really what it comes down to. Most people here probably do want to make these big ass games or AAA style games (to a degree... I mean like cinematic, complex animations and so forth). So for them all of these tools such as the Animator and physics system etc really do save a lot of time.

My own ambitions are quite modest in comparison so for me the majority of what Unity offers does nothing to help me and at times actually serves only to add additional work. Unless I just throw it all out and use it like I was as just a way to pool objects, load resources, render and play audio.

Maybe it really just isn't the right choice for me. As much as I enjoy the community and the discussions here maybe it really would be better for me to just choose something that is more in line with the kind of games I desire to make. Something like AGK or NaaLaa 6 seem like a great match.

I'll have to think about it this weekend.

Anyway, I did spend some time working on the Wolf3D demo project. I ended up doing a test using the CharacterController and this is the way to do it in Unity. Still took a bit of messing around but overall it was quite efficient.

I really should do a test with N6 and see how long it would take.

 

Except those two quotes are contradictory. Unity helps a lot with something like a Wolfenstein3D game with RPG elements, and there's no reason you shouldn't be able to make one quickly using it. Much more quickly than making it from scratch. From the discussion here, it seems that you spend most of your time over-thinking everything, rather than just doing it. Not to be mean, but in the time it took you to make a character move forward, neginfinity banged out an impressive-looking Doom level editor. Maybe less time talking on forums about doing stuff faster, and more time actually working and learning, eh? I trust you see the irony there....

--Eric

 

There is no doubt that is a big part of it. I always feel pretty lost working in Unity. So I do spend a good amount of time just trying to get started and do anything with it.

I've made a fair amount of progress. Like I just put a little more time in and textured the normal door and stuck one in just to test it out.

But I agree with you. And that is basically what I was saying. I don't understand what the issue is. The fact that @neginfinity and others could make one quickly in Unity tells me either they are simply significantly more experienced and skilled developers than I am or Unity just works significantly better for them than it does for me.

Considering I am normally a very fast developer in everything I have used I think it is something about Unity specifically. I don't know what it is. Why it is. I wish I did.

But anyway, I think I will check out some other things and see if there is a difference or not.

 

@GarBenjamin

again, pub talk:

- Your community RPG was a good tool to work with others and
- familiarize yourself with their style and with
- Unity itself

But you did not stick with it.

I can't judge on your programming skills but given you work in the field, they should be more than sufficient. I think you just need to stick with something and stop making your timed benchmarks. It is a hobby, forget about time. The more you "play" it the better you will become naturally...so you will improve no matter what.

 

Have you thought, maybe, about getting someone to tutor you? No offense intended, of course.
I mean if someone walks you through their development process, you may be able to figure out what the issue is.

Also... this post reminded me of that one time where I was looking for ways to cut corners at drawing and modeling. In the end it looks like the most efficient idea was to waste X hundreds of hours banging my head against a wall (figuratively speaking) while trying to do something over and over and over till I get slightly better at it or till it finally "clicks" for me. Haven't found many corners to cut, but then again a lot of modeling and art related information is very disorganized (especially modeling), meaning the way to go is sometimes to acquire intuitive understanding of the subject. :-\ Once again, no offense intended.

 

Several times I have read your posts in different threads because it has always impressed me the fact that you are an original thinker, with your own ideas and approaches. I have even used the search engine to look for your name to read what you were commenting at the moment. So, I don't know if the advice that I will give you is correct, but, if I were you, I would try to do something different, original, which doesn't need to be very complex. Maybe part of what is burning you out is that you try to do another Wolfenstein instead of developing the unique concept that you have inside, and that nobody else has. Or maybe I have just written a stupid comment.

 

You are right. A large part of it is I am kind of just burnt out on game dev in general. Particularly this time of year. Winter is a better time for game dev for me. Or it used to be anyway. These days that is pretty much filled with holiday stuff.

Maybe I just need a long break from it all. It is possible.

 

I have thought about that many times with Unity. I have watched many videos on it but I find the way they do things so non-intuitive and unnatural that I don't get much out of it. I mean I do pick up things here and there of course. But it is almost like the whole core idea behind it just doesn't mesh with me or something.

But I can always grind my way through it. Anyway, yes I have considered that many times now. I often think there is just some few basic things that I must be missing.

I even tried that Roll-a-Ball tutorial once. And sure I mean it all worked fine and was simple enough but at the same time to me it was like I didn't even do anything really. Collisions were taking place and yet I wasn't doing any collision checking. Movement seemed to be happening kind of auto-magically. And my mind always wants to go to the inside. To understand what it happening and see the code that is actually doing it all. Development like that makes me feel detached I guess is the best way to describe it. Like I am steering something but have no real direct control over it.

Again I think a lot of it is just simply me and Unity. I really do.

But I would be open to hiring someone to spend some time at some point starting at the beginning and creating a very simple game sure. Maybe this winter if I still want to understand I will do that.

It's a great suggestion and no offense taken at all. I honestly don't write this stuff just to make noise. I find it incredibly frustrating and often wonder what in hell the problem is why it seems so alien to me.

 

Well thanks I appreciate that. That's part of the frustration I have. So often I have tutored others in development at work and help with designing solutions to problems and so forth. Yet for some reason I am at a brick wall when it comes to Unity. I don't understand why that is but it seems to be the way it is.

I don't think it is the games doing it. It is more that if I could knock out a demo of a Wolfenstein3D level in a few hours in Unity as others do then I would finally feel "free" to be able to go beyond and make something more. Which is why I also think maybe the next time I feel in a game dev mood it would make more sense for me to try something else instead of continually trying to force myself to "get it" (Unity).

 

Haha, no ! Just start having fun with it...I doubt a break will change things. I mean of course take one, if you want but it wont be the solution to improve the game dev. I think game dev in general is very difficult (not the tinkering aspect of it) as it requires multiple skills and only a few indies are blessed with skills in the various disciplines required.

I have said it before, best approach is to define a goal and try to then make a plan on how to get there. Even if you are not a skilled project manager, this is kind of the one step that can not be compromised. The plan includes tools, timeline, make vs. buy, etc. Does not have to be super sophisticated, can be changed in the process but should be there all the time. Game dev is not trivial and without a plan it can easily become a time sink without any tangible output. I think even if your goal is just to have fun, not necessarily a commercial game, etc....a plan will still help you.

I also do not think Unity is your problem, but it might also not be part of your solution, again, depending on your goal and plan to get there. Unity is as much or as little as you want it to be. But let's say if your goal is to make a really cool W3D level, use an existing tool and just design the level (modding). If your goal is to design a W3D level in 4 hours, again use an existing tool (modding). If your goal is to program from scratch a W3D like functionality, use say C++ only...you will likely not get very far in 4 hours but you might be very happy with the result as it is 100% controlled by you and you did not use another API. I think my point being, if you want to develop a sound game and are solo with limited time...forget about programming all together, this is where the least amount of time will be spend. Use a very simple and high level framework, spend the time on level design, assets, etc.

Edit:
this learning was hard for me to accept, too. I learned coding in the C64 area and it was a great feeling to be in control of "everything", timing the raster + making the impossible happen, squeezing every wasted cycle out of your code, optimize memory till the end of day, etc.... the challenge then was different and mostly related to coding. Today, that is not the case anymore....game dev requires a different skill set today.

 

@GarBenjamin have you ever made one of the tutorial projects from start to finish, with your own art? I think it is very hard to learn a different method of something without completing something in its entirety.

I know you're an experienced programmer, but maybe approaching it this way would help you to become comfortable with the fundamental way that Unity does things.

 

@sngdan There was a time toward end of last year where I thought perhaps having started in game dev so long ago and being used to that way (I loved that way of development... everything was logical. Nothing happened unless I made it happen. I don't know it was just all like common sense)... that maybe I am kind of just out of my time. lol

But then I thought no that is not the case because like at work on every job I've had I do the same kind of programming. No it is not games but it is all the same basic kind of approach. Even in the C# projects or Oracle PL/SQL or MS SQL Server. Sure there is a GUI in SSMS but I know nobody who actually uses that. To do anything just pop open a window and start typing. If I make a desktop app to do something... say a simulator to test against for interfacing with a 3rd party vendor product everything in there is just built by me (or whoever). Sure there are events going on but I see that as no different than interrupt callbacks that have been there for decades.

I think this is a big part of it. In nothing else... no other development I do or have done... has anything been like Unity or Gamemaker Studio. There have been CASE tools and so forth but developers always joked about clicking a button writing 10,000 lines of code and threw them aside and got back to work.

See like I can develop games in Unity. I mean I have done it. But the most efficient way for me to do it has been to not use any of the stuff Unity provides except the stuff I have to use that Unity provides.

I don't know. I just think my head is wired differently or something. Maybe I am partially insane. Who knows. lol

 

Your goal is to make a Wolf3D clone, but you're talking about normal mapping a door.

Do you see a disconnect there?

I've said before that there's a difference between working on things and getting things done. Which one do you do?

What project planning do you do?

Regardless of tools, if I ever start feeling "lost" then I know I haven't planned enough, and I spend a little time catching up on that. I try to always have a small set of clear tasks to choose from doing next, and I always know what short-term goal I'm working towards, on top of longer-term planning like milestones and such. This helps me stay focused on doing things that actually matter and move my product forward in practical ways.

It also helps me keep focused when I have to learn how to do a new thing. An important thing to realise is that you don't have to be an expert in the thing you're learning to get the job done. So, my focus is very much on the "getting it done" rather than the "learning about it".

 

I get the suspicion you might just be enjoying programming a lot more than making a game. Many of the things you try seem to maximize the time you get to spend on coding, like cutting down the time spent on art. When I think of how many hundreds or thousands of hours are left till my game is where I want it to be, I'm fairly sure less than 20% of that time will be coding. Maybe even less than 10%. I'll probably spend more time playtesting than writing or reading code.
If writing code is all you really want, maybe it's time to re-align the gamedesign aspect with that. Wolfenstein3D imho is a game heavy on content and relatively light on coding, that's like the opposite of what you should be working on, when you want to code as much as possible. Maybe check out a bit of Minecraft's sourcecode. Even some of the friggin textures are made from hardcoded for loops iirc. And the game is about procedural generation, so no level editor required. Maybe something procedural and voxel- or ascii-based would suit you better?


Edit: http://steamcommunity.com/sharedfiles/filedetails/?id=921161312
Check out the comments. Not much love for Wolfenstein clones.

 

Are you serious here because this looks like you are coming into the discussion having already judged and set in your beliefs about me? Because we tend to see what we want to see or what matches our beliefs. lol Not that it is a terrible thing. It happens it is a human thing so I am not trying to slam you for it more just make you aware of it.

I never said anything about normal mapping. I have an unwrapped texture image of a cube. That base image is copied and then I just quickly sketched over it to apply on the "Normal Door" as in a door that requires no key to unlock. And I spent some time adding said door into the system.

EDIT: I just read the other part and agree on the project planning. That can be very helpful especially if it goes into the technical side to investigate the approach used and so forth. Basically my plan for this project is...

There was no plan. Only after the discussion on making such a game in Unity did I think ah maybe I will give it a shot to build the core engine. So I then defined this list as guidance.

Figure out how to best design the levels for max speed & flexibility
Figure out how to best implement player control, movement and interaction with the level environment (collisions with walls and so forth)
....

Actually I can see why it is taking time. "Figure out". Research always takes time. Having to think of and test several different ways to do something. So that isn't Unity other than me nkt having any clear idea of how to approach it in Unity. That goes back to for me it is not very intuitive. And it has been a year or more since I did anything in 3D well besides that community rpg which also has no character controller or anything else on it.

Anyway project management is good. Can be a black hole too. But some is definitely very helpful.

 

@Martin_H I do enjoy programming as in the technical design part of course. Typing on keyboard not so much but that is still best way to do the transfer.

I actually do enjoy the other aspects of game dev too. Even making the art. And my goal here is the faster I can implement the systems and so forth the more time I can then spend in other areas such as on the art. I doubt I will ever spend half as much time on it as many people do but that doesn't matter... I just am saying for me a benefit of being abe to develop the core and systems quickly is then I'd feel like I could spend more time on the other parts.

No offense meant to the developer but that Wolfenstein game looks like a sort of poor man's version of a straight up clone of Wolf3D. Looks like a "first game" kind of thing. I didn't read through all of the comments but I can see why it wouldn't be met with much love. It looks like it is as blatant of a direct clone as they were able to make.

Maybe I just see game dev differently than many do. When I look at Wolf3D I see much more than Wolf3D as it is and when I think about making that I am looking at it as a core. A base. A foundation on which to build a game with a little more depth and interest (at least to me).

This game you linked... first get rid of the german soldiers replace those with demons or aliens or better yet mutant bunny wabbits. Build on the basic key->lock puzzles a bit. Add something very different. Just one room that is "weird" or whatever. Add... well whatever... some rpg aspects of gear or even leveling character, definitely some enemy variety with distinct behaviors.

So this person's version of the game is just not much of a game. It offers basically nothing over the original. They should be happy they made it (although it kind of looks like they nicked some of the content seems like I have seen it before someplace) and throw it out as a free game on web portals. It might be fun for 3 to 4 mins of mindless blasting. But not on Steam like this.

It is not Wolf3D inspired games people hate it is just no effort on design & gameplay... offering nothing unique... nothing more... just a shallow copy that misses the point of the original.... that is what people hate.

My two cents on it.

 

I think I am slowly figuring out what it is. And I know this is something I keep having to relearn again and again and again.

Like the doors for example. Originally, I thought well now how in heck should I do this in Unity?

The What I would Call Not The Unity Way Approach

So I came up with a parent GameObject named NormalDoor. Just an empty GO.
Beneath that are two cube models scaled appropriately and set as the left and right door parts (these are double doors that slide open). Each of these two halves have a collider.

Then I thought okay so how do I best detect the presence of the player or enemies and open the doors accordingly?

My first thought was wiring up communication. I made the colliders triggers. Then Made a DoorPart script. And that had a RegisterTriggerEnterCallback and a RegisterTriggerExitCallback. And then I made a DoorInteraction script that I added to the NormalDoor parent GameObject. And in Startup I got the child DoorPart scripts and registered the callbacks for each of them.

And that all worked fine of course for the communication so the NormalDoor DoorInteraction script was able to detect when an entity entered and exited the collider. However, setting those colliders to triggers broke the automatic collision detection that was delivered by using the CharacterController.

So then I thought well damn here we go again. I guess I will need to drop back to using raycasts and scanning the world to detect all of this stuff. And this is how it generally goes for me in Unity. The simplest things just spiral out of control into complexity.

BUT... this time I thought now wait just a minute here before I do that... there has to be something I am missing here. I can't believe it would be this complex just to do something so dang simple.

And I thought AHA! Remember all of those posts with people talking about the GameObjects use the GOs for anything and everything. So how I could use another GameObject or two to simplify this?


The What I Would Call The Unity Way Approach

So what I then did was to delete the DoorPart script. Got rid of the delegate declaration I was using for a callback method. Turned the left and right door colliders back to normal and not be triggers.

Then I added a new collider to the NormalDoor parent GameObject itself and made that the trigger. This way greatly simplified things. But I just didn't think of it to begin with. I don't know why exactly but this whole GameObject thing just I really have a hard time connecting with it.

Actually I didn't need to add any additional GameObjects at all I just had to look at the GOs I had in a different way.

But anyway this is I think is how you are probably supposed to do it in Unity.

And the DoorInteraction script is this:

Code (CSharp):

1. using System;
2. using UnityEngine;
3.  
4. namespace GarWolf3dBase
5. {
6.     public enum DoorState
7.     {
8.         Undefined = -1,
9.         Locked = 0,
10.         Closed = 1,
11.         Closing = 2,
12.         Opening = 3,
13.         Open = 4
14.     }
15.  
16.     public enum KeyType
17.     {
18.         Undefined = -1,
19.         None = 0,
20.         Red = 1,
21.         Blue = 2,
22.         Green = 3
23.     }
24.  
25.     public class DoorInteraction : MonoBehaviour
26.     {
27.         public Transform _left;
28.         public Transform _right;
29.         public DoorState _state;
30.         public KeyType _keyRequired;
31.  
32.         // count entities entering the trigger
33.         // when the entities exit the trigger this is decremented
34.         // when the number reaches 0 no entity should be within the door so it should close
35.         private int _enteredCount;
36.  
37.         private Vector3 v3DoorPosition;
38.  
39.         void Update()
40.         {
41.             switch (_state)
42.             {
43.                 case DoorState.Opening:
44.                     StateDoorOpening();
45.                     break;
46.  
47.                 case DoorState.Closing:
48.                     StateDoorClosing();
49.                     break;
50.             }
51.         }
52.  
53.         private void StateDoorClosing()
54.         {
55.             float adjustAmount = 2f * Time.deltaTime;
56.  
57.             v3DoorPosition = _left.transform.localPosition;
58.             v3DoorPosition.x += adjustAmount;
59.  
60.             if (v3DoorPosition.x >= -0.5f)
61.                 v3DoorPosition.x = -0.5f;
62.  
63.             _left.transform.localPosition = v3DoorPosition;
64.  
65.             v3DoorPosition.x = -v3DoorPosition.x;
66.             _right.transform.localPosition = v3DoorPosition;
67.  
68.             if (v3DoorPosition.x <= 0.5f)
69.                 SetNewState(DoorState.Closed);
70.         }
71.  
72.         private void StateDoorOpening()
73.         {
74.             float adjustAmount = 2f * Time.deltaTime;
75.  
76.             v3DoorPosition = _left.transform.localPosition;
77.             v3DoorPosition.x -= adjustAmount;
78.  
79.             if (v3DoorPosition.x < -1.49f)
80.                 v3DoorPosition.x = -1.49f;
81.  
82.             _left.transform.localPosition = v3DoorPosition;
83.  
84.             v3DoorPosition.x = -v3DoorPosition.x;
85.             _right.transform.localPosition = v3DoorPosition;
86.  
87.             if (v3DoorPosition.x >= 1.49f)
88.                 SetNewState(DoorState.Open);
89.         }
90.  
91.         void OnTriggerEnter(Collider source)
92.         {
93.             _enteredCount++;
94.             OpenDoor();
95.         }
96.  
97.         void OnTriggerExit(Collider source)
98.         {
99.             _enteredCount--;
100.             CloseDoor();
101.         }
102.  
103.  
104.         private void OpenDoor()
105.         {
106.             if (!DoorCanBeOpened())
107.                 return;
108.  
109.             SetNewState(DoorState.Opening);
110.         }
111.  
112.         private void CloseDoor()
113.         {
114.             if (!DoorCanBeClosed())
115.                 return;
116.  
117.             SetNewState(DoorState.Closing);
118.         }
119.  
120.         private bool DoorCanBeOpened()
121.         {
122.             if (_state == DoorState.Locked)
123.             {
124.                 // if player doesn't have the key, door cannot be opened
125.                 if (!PlayerObject.Instance.UseKey(_keyRequired))
126.                     return false;
127.  
128.                 // Door has been unlocked
129.                 SetNewState(DoorState.Closed);
130.             }
131.  
132.             if (_state == DoorState.Closed)
133.                 return true;
134.  
135.             return false;
136.         }
137.  
138.  
139.         private bool DoorCanBeClosed()
140.         {
141.            // entities (player or enemies) are within door range so it will not close
142.             if (_enteredCount > 0)
143.                 return false;
144.  
145.            // of course only an open door or a door currently opening can be closed
146.             if (_state != DoorState.Open && _state != DoorState.Opening)
147.                 return false;
148.  
149.             return true;
150.         }
151.  
152.         private void SetNewState(DoorState newState)
153.         {
154.             _state = newState;
155.         }
156.     }
157. }

I really don't know what it is about these GOs... I think it is something to do with the visual part of it. Like I see them in the scene and in my mind that is just some visual thing and has nothing to do with implementing logic or something. I don't know really. But I am kind of starting to understand the root cause I think.

Also disregard the enteredCount stuff in the script. I was playing around with different ways to simplify the tracking of entities being in range of the door. In the end though I will just need to do a scan (spherecast probably) for entities periodically when the door is in the Closed state. If nothing is around it can close. I think that will be simplest.

 

For doors I just use the lerp function.

You could also use overlapsphere to detect how near the player or enemies are.

 

Yeah that is what I mean the SphereCast I called it but couldn't remember the name. But that is the one.

Lerp I have never used. I can see how it would be useful for handling the "animation" part of the doors but I don't see how it would handle the state management part unless there is some kind of callback at the end of the range or something.

 

I was just thinking part of the struggle for me might be that perhaps Unity really does simplify gamedev but I am not used to that or at least not used to how they are simplifying it. Normally when I need to implement something whether in a personal game project or a work business project I need to do it. Everything just requires some degree of a lower level thinking (or higher level depending on how you look at it) even building a C# windows desktop application. Something as simple as a combo list box might contain objects for example. And basically a person needs to architect everything out of what are essentially low level building blocks.

I know I am not doing a good job of explaining it. But I think I am starting to see it. It is basically... I *think* Unity may really make game dev easier but I have a very hard time "seeing it". Like I can be looking right at the scene and see things that others here probably immediately think oh just do this... easy... and to me I see nothing but some empty GO that I made as a "container" basically just to hold the two door parts. Of course, part of that is also not remembering much of the api at this point. Been digging into AGK, N6 to a degree and not doing much of anything in game dev lately. lol

But I think maybe what it is... I am looking at it from a more complex point of view so I look right past the answer which is right there but is too simple for me to see. Maybe that is how to word it. Anyway the important thing is I think I may be on a path to understanding finally after 3 years of on and off messing around in this thing. lol

 

Yes I was serious, and no it wasn't prejudice, because...

...I think I misread in your post that you had "textured and normaled the door".

 

@GarBenjamin Just from reading your posts I can tell you're an accomplished programmer. It looks like you're trying to do everything OOP.

That may be where the complication arises.

 

This time I am trying to actually throw out as much of "my way" as I can as far as architecture and use more of a bunch of tiny scripts way.

Basically I am trying to use the best of both ways I guess. Trying to find the end all be all way for me to approach it in Unity.

That door thing was a pretty big breakthrough. I am glad I looked at it from a GameObject perspective instead of dropping down to using my WorldScanningSystem I made last year. That thing works well it is very low level and lets me tag every GO in the world as being a specific type and then the scanner has various methods that can be called to query the world around a given spot, in a given direction, etc. But I just think that was once again overkill solving a problem that might not actually exist... I just need to be able to see the solution Unity intended.

In this case it was to use a combination of GameObjects with different types of colliders. Non-trigger to block movement on the door parts themselves and a trigger on the parent container to detect proximity. In this way Unity game dev is a bit like a puzzle. And actually having a deeper general knowledge of programming may not be a good thing. Because a person (at least me) naturally uses their tried and tested methods and in doing so this can clash with the way Unity intended and ends up making something that should be very simple become more complicated.

 

Some suggestions...

• A full project plan isn't always necessary, but making sure you're crystal clear on scope, overall timeline and what "completed" will be is important. You can't focus on getting something "done" if you don't know what "done" is.
  
• Rather than "figure out", make sure that your tasks each have a concrete deliverable. Once you have achieved that deliverable then stop. I'll generally make those deliverables either plans or working test cases.
  
• Don't worry about "best", because "best" often isn't practically achievable in realistic timeframes. Instead, identify some practical criteria for what's good enough and hit that. It won't be perfect, that's ok. You'll learn from doing it and you'll do future tasks better.

 

What do you mean by block movement why would you need to do that?

 

I mean when the doors are closed they need to block movement. Although currently in my project the "normal doors" open automatically not even requiring a key press there are other doors that are locked and need the correct key. The blocking is more important for them. The non-trigger colliders stop the CharacterController from moving through those so works as needed. And then trigger collider on the parent container GO is bigger serving as the door proximity sensor and because it is a trigger it doesn't block movement so works as needed.

 

Actually, I'd even argue that it might be because his approach was not entirely OOP. I'm not saying that OOP is sort of a silver bullet, but the example with the door script can be solved in OOP just as easily.

I'm heavily leaning towards the non-MonoBehavior, and pure OOP approach, so if I was to do that, then I'd probably start with generalizing the key concepts before even considering anything about colliders or game objects.

For example, as we are talking about doors, let's have IDoor created as an empty interface first. Then we can define some common properties and behaviors, like the opened state, or method to open or close it, and so forth.

Then, we can extend it as a SlidingDoor, one or more door parts declared as properties, and it's the first time we introduced something of a Unity specific type, which is Transform.

Then we need something that detects certain events, so we call it ISensor, and define an event (or IObservable, if we are using Rx) as a property. And we can add an implementation which uses Collider's trigger callback (or an equivalent in UniRx) to fire the aforementioned trigger.

Finally, we need something that combines them both, say DoorOpener (sorry, I can't think up any better name for the moment), which accepts ISensor and IDoor as properties, and simply wire them both so that if the sensor triggers, just invoke Open() method of the door instance.

In the whole process, we didn't even care if door parts of the SlidingDoor should be a trigger or not, because the DoorOpener will work with any kind of doors, including even non sliding ones, and it's not at all important where we should put a trigger, as long as we somehow put it into a proper property of an ISensor derivative.

Of course, there might be a similar confusion with triggers and colliders after that. But a good thing about such a top-down approach would be that, such problems are all implementation details. So, as long as those upper, abstract structures make sense, you can try different things until you find something that works, without affecting the overall structure.

Again, I'm not arguing it's the only way to do such things. But I don't think such a problem depicted in @GarBenjamin 's example is something inherent in OOP approach.

 

Great advice to get things done! Though I have to say it sounds a bit like... work. And I'm really trying hard to keep my game from turning from a hobby into work. I'm not quite sure how much planning I can deal with before it sucks out the fun for me.

It never occurred to me that this could be what you struggle with. I guess to me it's quite a natural way to work because I'd do similar things in blender with object hierarchies. And even back when I worked 100% in code, using Cocos2D, all the sprites where in parent/children hierarchies, so not a wildly different concept.

 

You should do it the "smart" way. With available plugins you can avoid to spend too much time coding and focus on game content instead, until you want to spend time creating your own plugins.
If you spend the majority of your time coding something instead of making game content , something is perhaps wrong on your approach or perhaps you have only fun coding.

 

I only run into the too much time spent on the programming side in Unity. That isn't too say that I don't write a good amount of code no matter what I am using. I just mean it takes more effort on the programming side to actually get everything working. Mainly due to running into issues / lack of having the right perspective here. But I am starting to get it I think.

You are right though. That is what I was saying earlier. I often think there is something I am missing. Because for some reason it seems like complete beginners can come in and throw together an FPS game fairly easily. I just figure they are really picking it up super fast for whatever reason. I suppose it is possible some of them are using plugins.

But again with plugins that seems to be just adding yet another layer that needs to be learned, right? And then learning how to get the various plugins all connected and playing nice together. And so forth.

I think it is just a different perspective. Like maybe some of these folks come in and look at it like playing around and building in Minecraft or something like that. I don't know.

This time I am trying to be more patient and each step along the way stop and ask myself "is this how a complete n00b would do it?" Because I honestly think that is the viewpoint Unity has in mind with this thing. That's how I solved my earlier door issue so I think this is for the most part correct.

 

Here's one way how I could go about it.

1. Make an empty "DoorRoot" gameobject at center of doorframe.
2. Parent two more objects at location of hinges ("LeftDoor", "RightDoor").
3. Parent boxes to hinges, attache colliders and kinematic rigibodies to them.
4. To "DoorRoot", attach animator controller to it and create controller for it.
5. Create two empty animation clips for "door open"/"door close" scripts. Using animation window, position them the way you like for both positions.
6. Create animator controller for door root. Make one "activated" bool parameter, drag "DoorOpened", "DoorClosed" clips inside the animator, connect them with transitions so when "activated" is true, animation transitions to DoorOpen, and otherwise goes back to "DoorClosed" clip.
7. Create InteractiveObject monobehavior. Along the lines of:

Code (csharp):

1.  
2. public class Interactive: MonoBehavior{
3.      [SerializeField] paramName = "activated";
4.      public void toggle(){
5.          var anim = GetComponent<Animator>();
6.          if (anim)
7.              anim.SetBool(paramName, !anim.GetBool(paramName));      
8.      }
9. }
10.  

8. Make "InteractionSensor" script. Along the lines of:

Code (csharp):

1.  
2. public class InteractionSensor: MonoBehavior{
3.     public void trigger(){
4.         var obj = GetComponentInParent<Interactive>();
5.         if (obj)
6.             obj.toggle();
7.     }
8. }
9.  

9. Now. When player presses "interact" key, shoot ray. Check if collider is present, and try to get "InteractionSensor" from it. If successful, call "trigger()".

That's it. You have openable door in 16 lines of code (well, you'll need few more lines on raycast code), most time being spent setting up animation controller. It can also handle ANY door. Even Fallout style door with huge rolling gear. As long as you make an animation for it, that is.

Animation controller can be replaced with another component (I heard DoTween is popular) or you could write another one yourself. Doesn't really matter.

 

Noobs usually do things the only way they know, or the first way they find through trial and error that works. As far as I've heard some of the stuff taught in the unity learn section doesn't scale up well to make a more demanding and complex game, and you might be skipping such solutions already because you see those problems. I didn't actually view many of those videos because I mostly learned from reading the docs and trial and error, so I could be wrong here.
All I'm saying is just because it seems they "get things done" so quickly (which I think you shouldn't focus on so much), doesn't mean their solutions are actually viable long term. There's a balance to be struck, overengineering/overgeneralizing would be bad too. Maybe "just do it" is what you should focus on and don't overanalyze the whole meta aspects of how you could or should use Unity. Try things out and if you find better solutions then refactor. Isn't experimenting with different approaches and finding better ones part of the fun?

@neginfinity That sounds like a really clever solution, if you have a grip on the animation system. I never really used that, so for me personally that would require quite a bit of extra time to figure all the animation stuff out and I'd be done quicker "coding" the animation and exposing an animation curve for it in the inspector.

 

Animation system works somewhat similar to blender. When you have an animation clip active in animation window and red button is pressed, the current clip will record ALL object parameters you change. Object position, orientation, and individual fields in components attached to the object (and object's children). You can even animate materials this way.

The only problem with animation system is that for some reason it uses euler angles to animating rotations. It will work for rotating doors, but for complex rotations working around it may require large number of "in-between" frames.

In the approach I described you pretty much will need one keyframe per clip.

 

Many of them doesn't make barriers or think too much like you do lol , they have fun in the learning process.

Many start with some first prorotypes first on one area at time like navigation, physics , or basic AI states. They just learn what they need to make their game before making a mini game.
You just need to learn and practice step by step, one feature, one tool at time.

 

I do occasionally make stuff just for the sake of messing around with it. As soon as I decide that something is a thing I want to complete, though, the planning begins.

That said, for hobby projects the tasks don't have due dates, just priorities (which sometimes get ignored). For work projects due dates are important.

 

Okay, I decided to get the special doors (aka color coded locked doors) implemented in the image to map creation system, configure them in inspector etc and so forth.

I hid the ceiling "layer" for the video show the scene shows the full view.

Same system but slightly updated map image that produces the above:


I'm at 7 hours on this project so far. Seems like quite a chunk of time just to make some graphics and implement this much of it... but overall I think it is very good considering I had at least a few false starts coming to grips with how to approach this in Unity.

Of course this is all basic stuff but I definitely have an improved view of Unity at this point. I feel like I understand how it is to be used much better than I did before. And that is saying something because I have been messing around with it working on game projects off and on for about 3 and 1/2 years now.

I still don't see the need for the Animator and a good chunk of other stuff but that is just because of the kind of things I want to create. I suppose the Animator might be useful at some point but I have to say I found that very strange the couple of times I used it. Setting flags and so forth. BUT I don't want to slam it at this point since I am finally starting to "get it".

Hopefully progress will be faster from this point on. Next time... maybe tomorrow... I will add in the collectibles. Which will only be the keys for now just so I can test and be sure the DoorInteraction system works. It *should* but need to test.

Anyway, at this point I think yes a person could create a Wolfenstein 3D game in Unity in 2 weeks even working part time. But who knows what pitfalls lie ahead when I get to enemies and so forth. I am hoping my new "what would Jimmy do?" and "how can throwing additional GameObjects at the problem help?" approach will help a lot with such things.