Does Unity make game dev too difficult?

I think you are constantly mixing 'the way it is in Unity' with 'the way it should be in OOP'.

In OOP, as it is understood outside the Unity, subclassing a super type has nothing to do with saying something like "if you are interested, you can declare some arbitrary magic methods to receive a callback". Rather, it's just the way it is with MonoBehaviour in Unity.

On the other hand, subclassing a super type in OOP is a way to make developer's intention clear, as it is clearly seen from such cases like a marker interface.

Implementing IEnumerable, for example makes it clear that the class which implements it is something that can be enumerated, and it also enforces the class to expose relevant functionalities by contract. Normally, it doesn't work like "extend this class and you will be able to define arbitrary methods to manipulate collections", as it is the case with MonoBehavour in Unity.

So, unless you think OOP as it is adopted by the idiomatic C# approach to be something inherently wrong, I believe there's no reason why you should criticize that my understanding to be 'inaccurate' or 'mixed up', when all I did was to acknowledge the differences between the two, and expressed my preferences for a non-Unity specific approach.

 

I'm glad you like it and find it to be a good way to work.

 

What I'm saying is if I'm to follow the idiomatic OOP approach, relying on such magic methods is not the way I should follow.

And as you know, the major point of OOP is to make it possible for developers to understand and extend a complex system by looking at the abstract overview of its structure, which we call API, rather than having to read the source line by line basis.

 

Either I'm doing a poor job explaining my point or you're doing a poor job of reading my post. Maybe a little bit of both.

 

I don't think it's a problem of explaining or understanding your points, as I believe it has more to do with the way we understand what could be a good software design is.

Probably we should drop the subject then, as I suppose we both said plenty to make our respective points clear to others.

 

Did you see the edit where I mentioned the character stats thing, does that perhaps help to clarify my point?

 

No, I just noticed after reading your post. Thanks for the head up.

As for the matter, I believe that the problem is that Unity practically forces you to extend from MonoBehaviour whenever you want to attach some component to a game object, while doing so automatically gives you unwanted (at least for people like me, who prefer lightweight OOP approach) implications with magic methods, and so on.

As the way I see it, it could be seen as a compromise for promoting the typical Unity's workflow with components and their inspectors.

While I see benefits of such a workflow, it is still a compromise, which means there could be certain disadvantages also, so I find there to be no reason why we shouldn't try to find an alternative to mitigate such limitations.

 

I think I mistyped a magic name twice in last 2 or 3 years.

Cant' say the same about Interface-based methods. Because the event functions do not follow MonoBehavior paradigm usually what happens is that I add method, forget to add interface, wonder why it doesn't work, look up the interface, add it, then had to look up exact name of the parameter required by the interface. Major waste of time.

EventSystems is by far the worst part of unity API with the worst design. If using something like is what means to write "proper" code, then I don't want to see any of it in unity. Simplicity and utility is more important than strict adherence to some programming dogma/paradigm.

-----------

Also, I gotta say that @frosted provided very solid explanation in previous posts.
----------
"We must use interfaces because it is the proper way" is at its core an irrational argument. What benefit does it bring? A lot of inconvenience, and nothing more. I mean even in original standard C#/.NET api interface design was never sound to begin with.

Language and practices are tools. It is tool's job to do programmer's bidding. When a tool starts getting in the way it needs to be removed, replaced and fixed.

 

I see it as a problem with priorities.

You shouldn't be trying to follow the idiomatic OOP approach in the first place.
Programming is always about "pick the best tool for the job". Meaning you should pick whatever works the best for the situation - OOP, functional, procedural, declarative, wahtever. If your first urge is to use OOP, then it is obviously the case of "when you have a hammer, everything looks like a nail", and you're shooting yourself in the foot.

The primary priority is delivering the product. For that you need to select most suitable approach for the situation at hand. If your primary priority is "I need to use OOP" instead, priorities need to be re-evaluated.

-----------

Sure. Put one gameobject in the scene, and do everything in it.

 

Again, then why shouldn't I choose a tool which I feel more comfortable with? I never said everyone should use interfaces or use a more idiomatic OOP approach.

I find it funny that when it's only @frosted who has been trying to explain why I should see MonoBehaviour in a more favourable light, or you to say that I should not try to follow idiomatic OOP, but somehow I'm the one who's following some rigid dogma?

If you don't like OOP, then don't use it. If you are happy with magic methods, you can use it as they are. I never really forced any of you to embrace OOP, or claimed any other way to be inherently bad.

I just feel comfortable with OOP myself, as its understood outside the Unity world, and I'm not happy with MonoBehaviours or its magic methods. So, you think I should change my views and abandon OOP to embrace the Unity's way as it is, even though there's a working alternative, if I'm to be considered pragmatic, and not blindly adhering to a dogma?

Honestly speaking, I believe it's actually the other way around, that you got too accustomed to the way it is, so refusing to acknowledge there might be an alternative approach which could better suit other people's needs.

 

Let me try a less argumentative approach. In general, I think of the Unity Scene Hierarchy in somewhat similar terms to the DOM in HTML or XAML in WPF.

MonoBehaviours are a type of presentation component. They exist in the context of the presentation layer (scene hierarchy). Similar to many (most) presentation components they have various callback hooks for handling messages about the context in which they exist.

Is a "Panel" "Canvas" "Div" or whatever other base class for GUI elements bad because they include a bazillion event callbacks? No.

Should you implement "CharacterStats" as a subclass of panel? No.

If you think of MonoBehaviours in somewhat similar terms, as if they are presentation elements, then they might start making much more sense. There are differences, sure, but it's a good starting place.

In general, the interfaces and data that these kinds of 'presentation' base types expose is huge and varied. A "panel" can have quite a lot of responsibilities. If you look at just about any GUI API in existence the same patterns emerge.

Over the decades, we've decided that it's better to cram a bunch of crap into base types in hierarchical presentation. It's just the easiest way to work with these kinds of components. Is it ideal? No way. Is it generally the best way? Yes. The fact that the same basic model has been followed time and again is evidence.

MonoBehaviour's have some really key differences, and it's not always appropriate to think of them as pure presentation, but there are really important similarities and it's an easy comparison we're all familiar with.

 

If you read the W3C specification to see how actual IDL definitions of HTML DOM objects look like, or see how class hierarchies are usually designed to implement DOM model in browsers or other libraries, you might be able to better understand what I've been saying.

HTML 'div' element, for example, has quite a complex type hierarchy which involves many different 'interfaces', each representing a specific role, or an aspect, unlike how MonoBehaviour's signature looks like.

For instance, it implements 'NodeSelector' interface to provide querying its children, and also 'EventTarget' interface to define how we should attach or detach event listeners to the object.

And it's more remarkable, when you consider how the original HTML was developed pretty much by patch works from different browser vendors, but W3C went extra miles to introduce some sanity by defining such kind of interfaces in a retrospective manner.

And WPF's Panel also has quite an elaborate type hierarchy also. It has 6 ancestors in its hierarhcy, and implements whole bunch of small interfaces like IFrameworkInputElement, IInputElement, ISupportInitialize, IQueryAmbient and so on.

If interfaces were so useless, or it was much better to just replace them with bunch of magic methods, why do you think they designed such widely used specifications in that way?

And I also have looked into how GUI APIs are designed in popular frameworks as you suggested, and even created couple of them myself despite they were proprietary. But from what I've seen, the better designed among them tend to follow commonly acknowledged best practices of OOP, like splitting different functionalities in separate interfaces, as mentioned in the above example.

And more importantly, they never rely on such magic methods to function, like it is the case with MonoBehaviours.

And I think treating MonoBehaviour to be merely a presentational concept can be quite useful. But if what you are suggesting is to separate actual game logic from presentational layer, that is MonoBehaviour, then I don't see any difference between the model I said I preferred to the typical Unity's way.

With a DI framework in Unity, you typically define a single entry point on a game object, and treat it as a context for all dependent components. In this case, only the entry point needs to be MonoBehaviour, but we can write all the rest of the system as plain POCOs. What's the real difference between this model, and what you suggest with separating actual logic from MonoBehaviours?

And if such an approach of treating MonoBehaviours to be merely a presentational components to be widely accepted, I'm afraid it's not me that you'll need to persuade to follow such an example.

While I'm agreeing with such a method in principle, I think that the majority of those who develop on Unity ignore such a distinction, as most of the materials that I've seen, including Unity's official tutorials and examples seem to follow such a practice of 'just throwing everything on MonoBehaviours and be done with it' kind of an approach instead.

 

Because it may not be the best tool for the job.

 

Then I'd suggest you to visit below links, and tell those people how they are mislead into using a worse tool for the job:

• Zenject Dependency Injection IOC
• Adic - Dependency Injection Container
• StrangeIoC

 

- I'm not saying that interfaces are bad.
- I'm not saying that idiomatic C# is bad.
- I'm not saying that magic methods are good (or even an important aspect of a monobehaviour, I consider it's magicalness to be implementation detail - I don't care either way, in practice it has very nearly zero effect on me).
- I am not saying that a gui base types should not implement a bunch of interfaces.

I am not arguing any of these points. @neginfinity is making a broader argument than I am, so maybe you're batching the two arguments together (understandable).

Finally, I am not a strong adherent of "the unity way". I think people tend to use monobehaviours too much, and put too much crap in them.

If you are subclassing "CharacterStats" from "Panel", the problem isn't in Panel. It's unfair to complain about Panel's design, even if there are various tutorials that suggest this is the right approach.

I'm just trying to narrow down the idea of what a monobehaviour is.

In terms of DI - in Unity I've used a couple and written a couple - I think there are better approaches in the Unity environment and I've moved onto different approaches that better fit my needs. YMMV, and that's O.K.

 

I admit that my previous post contained counter arguments for broader scope (especially regarding interfaces, which should've been directed to @neginfinity instead). I'm sorry it sounded like a strawman argument.

But you have quoted my posts number of times, to point out that I should not adhere to the idiomatic C#'s way as a dogma, or that I better embrace the way MonoBehaviour is, for I was wrong to criticize its various aspects which I didn't like. So I had to write my own to elaborate on any points that I don't agree.

And again, if all you really wanted to say was that I better separate non-visual logic from MonoBehaviours, then I don't know why you had to write so many posts to counter my arguments, as it was precisely what I assumed to be a more idiomatic C# approach all along (as a DI framework in Unity is essentially a tool to achieve just that).

 

There are a bunch of separate threads of argument kind of mushed together.

What constitutes "presentation layer" in a generalized game engine?

Is collision handling presentation or is that game logic?

There's a lot of grey area there. Much more so than in most traditional GUI. Further, the elements that compose 'presentation' are much, much more varied and much more complex than in traditional GUI.

Even in plain old traditional GUI, the lines between presentation and logic aren't as neat and tidy as most want them to be, in a game engine those lines are going to be extremely subjective. This is even more so the case because the needs of game projects will vary much MUCH more from project to project than traditional GUI.

A turn based, hex based game has dramatically different logic than your average FPS. The lines between game logic and presentation can get more and more fuzzy and in many cases more tightly coupled.

I disagree with your posts mostly in that I don't think MonoBehaviours are a mess, and I don't think they're bad design (the magicalness is debatable, but I consider it a lesser part of the overall picture). I think of them as a compromise that was immensely well struck.

 

I agree with that. Surprisingly good approach.

It sounds like you might be starting to take this personally.

It is possible to work without 3rd party frameworks, with less classes, and also faster.
If your selected approach requires a 3rd party adaptor written and maintained by other people over long period, then it sounds that originally it was less suitable for the job. Otherwise it wouldn't need an adaptor/wrapper/etc.


Besides:

What would I gain from doing that? "Ha, I showed them!" or some other nonsense like that?
Their lives, their decisions and their consequences of the decisions they made.

Spoiler

However, when people start talking about hundreds of classes in a unity project and 3rd party framework that is required to make them work comfortably, the situation looks like a case of over-engineering and unnecessary overcomplication to me. It also reminds me of how many years ago I loved dealing with those class hierarchies, until eventually I got a slap in the face and figured out that sometimes it is possible to make things work with 5 object types, and in quarter of time it would take with OOP-heavy approach. Using that robot swarm approach I mentioned earlier.

The resulting paradigm shfit and chance of perspective was quite signficant for me and because of that when people heavily rely on OOP approach I wish they could experience something similar. In the end, OOP is often guilty of creating those huge bloated frameworks @GarBenjamin dislikes, so it might be a good idea to check how working in a simpler way feels. For broadening horizons and such.

Either way, I'll try to refrain from further posting until the whole "programming methodology" talk stops. Other things to do, and stuff.

 

As I repeatedly pointed out, I never tried to force anyone to adopt any method that I find to be preferable.

But haven't you tried to persuade me to abandon my approach, saying that using interfaces are bad, and things like that the whole time?

And what should I say, if you claim that I'm using "a worse tool for the job"? Isn't it something reasonable to show you that the tool I've been using was something that many people think highly of?

Do you mean I should just accept your argument as truth, and abandon my accustomed approach? Or do you think that my giving you those links were any more 'personal' than what you claimed of my using a 'worse tool'?

I appreciate that if you were trying to help by delivering me from using a 'worse', or 'more complicated' approach. But if, after a prolonged discussion, it still stands that we both have different views. Then it's just that, opinions can differ.

Even though I feel you have quite a strong bias against OOP, as much as you think that I have it for the 'Unity way', I don't keep claiming that you are using a wrong tool, or you are complicating things, and such.

If you felt disillusioned with the OOP approach, or suffered from bloated frameworks, I respect your personal experience and opinions.

But I expect you to do the same for mine, because I have my own experiences which tells me otherwise. I've been working on projects with thousands of interfaces and classes, and I have my own list of what worked and what didn't for such a task.

Of course, I'm open for a discussion for such a matter, but when it comes down to just repeating "no, you're using it wrong", I believe it's time to agree to disagree and move on for both of us.

 

@mysticfall Lol you have to get used to it. I am used to it. If you are talking about things that are not pro Unity or at least things that seem like they might be suggesting even hinting that the choices in Unity may not be the best... you will face disagreement and sometimes outright hostility. I've not seen that here in your discussion because those two have kept it civil but it sure can and does happen.

The majority of the people here love the Unity game engine. Oh they might not like every thing about it and have their own tiny criticisms here and there but you're going right for the heart of the beast. The monobehaviour. To not like monobehaviour is basically to say you don't like Unity or at least the mindset behind Unity. Monobehaviour is a core principle.

I think they are just trying to share with you how much of a core piece monobehaviours are and there is no harm in using them.

 

As I see it, the main point of the discussion has been idiomatic C# approach vs the 'Unity way'. And it is probably undeniable that the latter involves doing most of the task using MonoBehaviours or editor extensions that are based on them, as it's almost universally recommended by official tutorials, examples, and other such materials.

So, if you position was we should separate presentation logic from business (game) logic, then you are pretty much in the same boat as I am, in that you are trying to advocate something very different from the way people are accustomed to when they are working on Unity.

But instead, if what you are saying is that such logics are actually inseparable in games, then I have to disagree, because I can think of many examples in a typical game that don't really corresponds to a game object in a scene.

And if I'm not mistaken, people have been using singletons to deal with such cases all the time, or simply making them as MonoBehaviours, even though they don't have anything to do with 'presentation'. So the problem is something real, which people can encounter in their projects quite often.

Then I have to ask, what was the point that you think we disagree so strongly that you had to warn me against following 'rigid dogma' and things like that?

Probably, the only real differences could be the one you mentioned, that how we see such 'magic methods' and other peculiar aspects of MonoBehaviour.

I already explained why I see them as 'defects' as I'm following a more idiomatic OOP approach, and there are whole lot of reasons why they can be regarded as such in that particular perspective, which I won reiterate here.

The important thing is, I never claimed that such an approach should be the one and only viable method to create games in Unity. And there could be many different reasons why someone choose one programming paradigm, or design principles over another.

If you don't see them as defects, it's probably that you are just taking a different approach from mine in writing codes, that probably does not put much emphasis on class hierarchies as I do.

We can argue whether or not such peculiar aspects of MonoBehaviour to be really a defect or not from an idiomatic OOP perspective. Or we can discuss if they pose any meaningful problems in a more typical Unity's approach.

But if we are to argue 'idiomatic OOP vs the Unity way', I believe we'll need more solid ground than talking about those magic methods, because they are obviously problematic in the former, while not so in the latter.

That being said, I have never showed much interest in arguing that the idiomatic OOP should be the way to go for everyone, so I'm really perplexed as to why I have to be dragged into arguing against everyone else over my own personal preferences.

 

Yeah its important to recognize when you're trying to fit a square peg into a round hole, it happens to all of us at some point. If you do plan on switching, before you do I would suggest trying to make at least one project in Unity with the approach/mindset that @neginfinity suggested, of approaching the project like a swarm of independent robots working together (if you aren't already doing that of course, if so carry on).

That having been said, I just had an idea that may be of interest to you. Your goal here with this FPS project wasn't so much the game itself as it was to try and get a feel for the "Unity way" of doing things right?

With that in mind, maybe this FPS project isn't what you should be working on. Instead, I'm thinking maybe you should take another shot at your old Alien Vampaders project from this thread.
Basically, try reconstructing that game from the ground up, even using the same art assets and sound files, but this time doing it the "Unity way".

It could be advantageous for several reasons. For one thing, it's a relatively simple game, so it's easy to iterate and try out new things. The logic is straightforward. It's familiar territory for you, it's something you've done before. Because of all this, it might give you a better point of reference, you can look at the old version vs the new version and more easily compare the two approaches. You could even try reconstructing the same game multiple times, using different approaches each time. For example maybe in one version you handle the collisions yourself while in another you try using rigidbodies, and so on.

 

Oh ha, as a self taught programmer it is quite funny to read all this.

My view remains the same, Unity is quite a sophisticated tool that has lots of flexibility (type of games, 3D/2d, platforms, etc.) and makes game dev much easier. I am certain that other tools exist that might be better suited for specific types of games, platforms, etc. In the end all tools have their pro and cons. The market share of Unity somehow underlines that they found a sweet spot for many but also not for everyone.

I find Unity refreshing (but also challenging) because it gives a lot of flexibility. I don't get too wrapped up with analyzing if things are good or bad, I accept that they are the way they are and work with them. Say a game object, if I attach a Sprite renderer to it, I see it as a memory location (like it was on the c64 and the Vic picked it up for rendering, instead of writing the position into a register, it's now transform.position). Mono behavior, no big deal. I can use it more or less. One game object with the start (init) and update function (game loop) is all that is required to run a game.

If I have a point of criticism in terms of not making game dev easier, it's mainly related to the app submission process, Ie better support for screen shots, video recording, all the warnings in say Xcode, etc...

I also think that a good tutorial of a very simple game (gameplay, edit: say a multiplayer pong) but including the following is missing (but maybe that is a bit much to ask )
- best practise approaches to the basics like game loop, saving, pooling, Highscore, etc.
- integration of all services, i.e. Analytics, advertising, etc.
- build for all supported platforms (to show, if there are platform specific changes)
- submission to all supported platforms

 

Maybe the difference is that I see both of these options as insane extremes. I would absolutely not want to work with a code base that embraced either of these viewpoints, at least, not on a game project in Unity.

That's kind of what I mean by dogma.

Pure idiomatic c# would embrace that separation wholeheartedly, but I think that the general purpose domain has clearer points of separation between 'presentation' and 'logic' than games do.

Again, is a Collision part of presentation or business logic? Can you even generalize about it?

Remember, there are a lot of different kinds of collisions occurring in game engines.

 

While "We shall defend honor of our clan!" kind of discussions occasionally happen (infrequently, I must add), Most of the time what happens is that people see someone taking an inefficient approach (sometimes perceived inefficeitn approach) and attempt to work with it, and it frustrates them.

Basically imagine someone working in text editor, making a lot of types, and then pressing using Mouse to click undo (and positioning the cursor in bottom right corner of the screen immediately afterwards). That's roughly the feeling.

 

I avoid OOP where ever possible.

 

@mysticfall
another good example is animation.

Naturally, most people would think of animation as "presentation logic" - but when you start to deal with the details of stuff like root motion and having animation data drive position change, the water starts to get muddy.

In my project, animation is both responsible for presentation and business logic, in most cases they're inseparable. The navigation system feeds the movement system which feeds the animation system which ultimately writes position data, which gets fed back into the navigation system.

To some extent modifying 'presentation' cannot be done without affecting logic. This is not a programming error or a mistake, this is intentional by design.

You can argue the same to some extent with some more complex traditional gui, but really nothing I've ever seen in a gui environment comes close to the kinds of things you need to do sometimes in a game environment. Lines blur.

 

I truly LOL! Thanks for that.

 

It's worth noting that everything in a game engine is procedurally interpreted. Even an image isn't just an image, there are layers of logic written that manipulate, interpret and remap images.

Yes, browsers do this as well, but again, not to the same degree (outside of webgl). Shaders, materials, renderers that map geometry to uv coordinates to texture coordinates, etc.

Games have very different kinds of processes (and problems) from almost all other domains. It's not unnatural for them to also need a different set of idioms and practices.

In the most general of terms, games write and transform more data than any other domain - by an order of magnitude. No other domain regularly deals with as many transformations and writes as games do. In fact, most domains don't really do any, they just pipe data from source to destination with nearly no transformation what so ever.

 

In my opinion, 'dogma' is a belief people adhere to without a reasonable ground, not something leaning towards a certain direction.

The Unity way, as we discussed could be seen as an extreme form of development method, which emphasizes visual manipulation of component parts and their compositions in a non-language specific way.

C# itself is a general language that relies on OOP to build a software, but Unity is a special case that borrowed it to its own use.

And being such a special/extreme case doesn't make it a dogma, but once people start claiming there could be no better way than there is without really trying or understanding the alternatives (to be clear, I'm not saying this against anyone particular in this thread), then it becomes a dogma, in my opinion.

And as to colliders, or animations, I fail to see their relevancy to the discussion. It's true that they are core concepts of the platform, and sometimes game logic depends on specific types of configurations of such components.

But that doesn't mean that we should handle every callback events from such components as magic methods, and put them all into a single class.

I suspect it's more of an attempt to optimize performance by eliminating any intermediate layers between the C# and underlying C++ layers, than any conscious design to account for such proximity between such components and game logic.

And if I'm mistaken, there might be different ideas, or at least confusions as to how such things should be designed among the developers of UT, as we've already seen from the examples of IDragHandler, and etc.

 

It remind me the type of frustration new hires had to my former company, when they are instructed to work with the data driven paradigm, due to in order chip and multi core parallelism, and they still try to argue for OOP to the tech lead LOL.

 

multi core/single core parallelism is where it's going now I'm still surprised at the strong support for OOP and languages like c# and java but I suppose it takes a long time to die.

At the moment I'm dedicating my time to golang and nodejs.

 

Ok, it's kind of exhausting to keep arguing alone versus many people at once. So, I'll try to retire myself from the discussion now.

But before that, I'll reiterate my position here, as I have a suspicion that people trying to paint me as some sort of a clueless OOP fundamentalist who's doing a Holy War against the way it is with Unity.

I never said that OOP is some kind of a silver bullet, or that everyone should adopt a purely OOP approach when they develop games in Unity.

I'm actually confident that I can make a simple FPS in a way that people usually do, using game objects, prefabs, script objects, or sending mesages, and all. So I'm not preferring OOP because I'm clueless in any other way.

It's just that I, personally, don't like the way it is supposed to be done with writing everything as MonoBehaviours.

And lastly, I believe that there to be an alternative, like DI frameworks which people are already using to create games in Unity, to allow me to adopt more OOP friendly approach.

So, unless you are going for a Holy War against OOP, I don't really see why my posts incurred so many criticisms from so many people, as I was mostly talking about my own preferences and experiences.

 

Yeah it's a pretty unfair argument, especially when you kinda tried to bail from it 4 posts ago

Worth nothing: I wasn't trying to rage against you - I was really just trying to help you see things a different way.

 

For what it's worth I had a revelation at lunch break today.... there was never any reason to leave C & Allegro, Blitz or C# & XNA. I just saw them as being dropped (Allegro actually persevered) so I looked for something that seemed like it would be around for a long time. Ended up here. In reality people are developing Indie games in Blitz and C# & XNA even now and possibly C & Allegro too. So... I have many more options than I first realized.

Hindsight is 20/20.

 

This game was fantastic. @GarBenjamin something in this style should be your next project.

 

I thought so too yet someone earlier in this thread thought it was a very poor example. It is amazing how diverse the views are here. lol That is a good thing overall.

Well I will continue to test N6 in spare time when I get the urge to do some game dev. And that is what I am testing first project is raycast based game. Although now I am thinking about digging back into B3D or BlitzMax.

I think it was @darkhog who suggested BlitzMax to me a couple years ago. I think he might have left and chose something else for his own projects. Haven't seen him around in a while now.

 

I would seriously try this as my next wip but I got blocky to complete before I get sidetracked.

https://forum.unity3d.com/threads/blocky.469292/

 

If you can help the port of the source code I'll be thankful /hint

 

Banned (that's what the crossed-out username means).

--Eric

 

It doesn't show up as crossed out to me. But I did notice that when I typed it in the name didn't show in the list but figured it was a long list and hadn't populated fully. Hmm... banned. Alright.

 

Something like this is a better visual style to shoot for. For me anyway. This is a programmer's game. Quite popular too.

As you can see this fella seems to really enjoy it. But I am sure he is remembering playing similar games long ago and just getting caught in the magical nostalgia (I would have inserted a sort of angelic AHHHH! at that point if I could have).

 

Unity's "way" makes things easy for me to understand.

I can treat GameObjects as things that actually exist, then just attach behaviours to them. All the code is in classes that make sense. Animation/GUI/Networking can also be kept in seperate behaviours. I just roughed out a turn-based FPS in 2 days.

I don't see the big deal.

 

Huh. Not one I expected. Now I'm going to engage on pointless speculation and wonder what he got himself in trouble for.

Interesting I don't see the crossed out thing either. Might be a mod only feature?

 

There was a reason. Using a game engine instead of a low level-level framework will greatly increase chances of actually finishing a game.

Basically... the choice of the tool depends on whether you want to make games or write game engines.

 

blitz is no low level though, I have been closer to finish a game entirely on my own with it than unity. My first attempt with unity was met with big roadblock that was just formality in blitz3D.

 

Honestly I never got started with Unity at all for that reason. Although I did some searching around and found many people were using it to make their first games I knew right from the start it would make things more complex than they had ever been before. But I also knew that was directly due to it being a game engine and not an api. And that was because it was targeting helping people make sort of their own mini versions of AAA games. Or at least that is the way I saw it.

I know someone will want to hoot & holler about me saying this but I am writing it to reply to you. It honestly doesn't make game dev easier. Not for me. Truly the games I have completed and the many I started and didn't complete would have been significantly in some cases many times easier in something besides Unity.

For example using AGK I think instead of spending 36 hours on Atlantic Crisis and 40 hours on Treasure of Ali-Gar those numbers would have been closer to 27 and 32 at the max. For the FPS yes if I had to write my own ray casting engine that would have taken a couple of days. But if I had that done again it would have been further along

Part of the reason I have continued to use Unity is simply because it is a challenge and I do like that (sometimes other times I just want to get things done.... I kind of bounce back and forth between the two). It is not making it easier in anyway other than the multi-platform support. That part is awesome.

Seriously I'm not saying these things to bash Unity or start some kind of holy war or whatever. I wish people could see in my head to understand that. Although it might be scary in there. lol Like I spent 1 hour 15 minutes testing N6 yesterday and at the end of that had reproduced the level I made for Unity, player movement, collisions and also started on enemy population and some simple movement.

I don't how else to explain it other than to say doing it at what you guys call a "lower level" way to me I see that as there is nothing to get in my way. There are no roadblocks. There is nothing much if any to learn. There are not loads of dependencies and complexities already created that I have to be aware of and deal with.

Anyway I don't want to keep talking like this because again although it is 100% true I think people just get ticked off and take it in a way different than intended.

I think different things just work better for different people. Some people can't build anything with a big fancy toolbox filled with all kinds of tools yet they can create an amazing ship inside a tiny bottle. Different skills and mindset I guess.

 

In case of engines, things start getting significantly more fun when you shift from 2d to 3d. In this case unity shaves off between 1 and 7 years of development time.

In a low level framework, getting one character running, reacting, supporting ragdolls, inverse kinematics, etc will take signifiacnt amount of effort. It can be hard to the point where project can die before you even have a level.

Basically, I've been on that road many times, and would rather not waste my time in this fashion ever again. The choice is basically ebtween finishing something in severla hours or spending several MONTHS to achieve inferior result. I thin it is not worth it.

For 2d... sure, you generally should be able to get by with Tiled + low level frameworks. For 3d? Nah.

 

Right see that is what I was saying. If a person is interested in making games kind of like mini AAA style games that is what Unity is intended for. I think anyway. Otherwise it wouldn't have support for IK and animation blends, state machines for animations and so forth.

A person can certainly make a 3D game without using a big game engine. One quick option is Blitz3D. Another is to use C++ and the DarkGDK. Or AGK. Or use raycasting and sprites for pseudo 3D. If a person isn't expecting to ever make a game anywhere like a AAA production (maybe in scope but not in the visual emphasis department) then you have no need for much of what game engines like Unity and UE offer. Or I should say such engines don't help me. Because the things they are mainly helping with are things that I won't use anyway. Do you see what I mean?

Anyway it is probably best to drop it. Again these kind of discussions tick people off because they feel like a person is attacking their favorite game engine. And I am not. I am just truthfully speaking with you but it is easy to take it in the wrong way. lol

I'm just gonna keep dabbling around and basically from now on probably use a variety of different languages and apis (which I have been doing the past couple of years too). Basically just have a certain language and api for certain types of games. Try to get the best easiest fastest dev for each different project type.

 

That isn't a class, it's an interface, and an interface does exactly what mysticfall was talking about with having a "contract" about functionality being in place.

If you implement a class you are saying "this thing is a type of that thing", eg: "my 4WD is a vehicle", where with an interface you are saying "this thing provides this functionality", eg: "my 4WD can accelerate and turn".

You're right that it gets verbose to type, but you're wrong that it doesn't gain anything. For starters it means that you can have collections of things based on the functionality that they provide rather than the types that they are.