Does Unity make game dev too difficult?

My point is that your proposed solution would force all MonoBehaviours to implement all of those methods. Regardless of language features in play it would be a bad thing for every MonoBehaviour to enforce a contract with collision detection and all of the other stuff that's available.

You're right that there's a whole bunch of good stuff that comes out of static typing and that Unity's current approach (in this particular area) could take far better advantage of that.

 

As I wrote above, I'm rather reluctant to continue the discussion in this thread now, as it seems I'm the only one who prefers the OOP approach

But just to clarify, I didn't propose that they should make an interface which MonoBehaviour implements that defines every callback methods it currently provides as messages. It would suffer the same problem of coupling multiple, irrelevant functionalities together.

If I was to design API for Unity, I'd probably have made the platform to act like a DI container itself, and while not forcing any default class hierarchy, let users to extend one of the specific event callback interface, or hook up delegates or even observe properties of the injected components, like a collider or animator, for instance.

Again, I don't think Unity can or should change to such a model at this stage, and probably there's no point in discussing details of such an approach, as I can see that there's not even such a consensus here that using something like a DI container is a good thing, or even OOP for that matter.

So for now, I'm just content with the fact that there exist several choices in DI container frameworks in Unity right now, which allow me to build games in a way that feels more comfortable for myself.

 

I know, you talked about using things such as "abstract methods" to "enforce the contract". Regardless of language feature, it's the "enforce the contract" part which I feel is misguided. There is no contract. It's just a bunch of hooks which may optionally be used when implementing components where it's relevant.

Anyway, I'm totally down for OO approaches... where they're a good fit. There is no one tool that's an optimal fit for all jobs.

 

It is not AAA, it is just about anything with solid movement mechanics and physics. Those are no longer "AAA features". Basically, even bouncing ball may be problematic, if you're trying to bounce it against arbitrary polygonal soup.

 

I dunno, it wasn't me wot done it. As for the crossed-out thing, are you looking at the profile page or a post?



--Eric

 

Yeah, it's more a matter of preferences or a right tool for the right job sort of a thing, rather than what is right vs what is wrong, as even dynamic languages have their use and they have lot of supporters among the developers too.

But on the other hand, it also holds that the other way around. If you like to design a software system in a top down manner, for instance, it's often done by laying out such 'contracts' which can be statically verified at build time. They really help when you have literally hundreds or even thousands of interfaces or classes to deal with.

In such a system, it's much easier to inspect the overall structure, or refactor it using such contracts, because they provide a higher level abstracted view of the whole system, so you don't have to read each individual source files, or worry to much about breaking things when you change them.

And it also allows one to fully utilize IDE's power to navigate and refactor such a system. So, in general, I tend to think that as the complexity, or the team size grows it becomes more profitable to taking such an approach, rather than more dynamic or 'pragmatic' alternatives.

 

@GarBenjamin

I do not consider myself as a Unity fan. I see Unity as a tool that helps in game development but I would swap it out the minute I find something with better value for money.

I looked at naalaa today since you mentioned it a few times. I was a bit surprised to be honest, this looks like a very specialized library for tile map (inc. raycast) games like W3D. So no doubt it would allow building a prototype of a W3D like game quicker. But in the end, I feel you would end up with a game that is very similar to the showcased games and if this is your target, well here you have your tool. It looks to me much more than a game maker / modding tool for a specific genre (not saying that in a bad way, I did not try it but trust your assessment that it is good).

I just do not see this at eye to eye level to something like Unity, where you have analytics, etc. I think Unity is more for making and releasing games while naalaa is more for coding satisfaction. (personally I would just play with a shader for coding satisfaction at this point).

I think a big confusion is also that the terms AAA, AA, indie, hobbyist, etc. are not well defined and mean different things to different people. I think Unity is for people that want to release a game to one or many platforms and keep supporting it. Unity seems to work for a wide range of quality levels from non commercial hobbyist to professional titles. It offers room to grow...

 

@ OOP discussion

Does this all matter? In the end it is translated to bits, so basically we are arguing about different systems of higher level code organization? And as in many other areas of life different systems work for different people. What matters to the end user is (a) to have fast enough code and (b) little wait time for bug fixes / enhancements. So striking the right balance between speed and maintainability is what matters + the right balance is a very personal thing to the coder involved. I remember how we unrolled loops on C64 to gain a few cycles and the code was all messy but fast. It was in consequence difficult to maintain but for some things it was the right (and only thing) to do. For other things you would choose more structured approaches (forget about OOP though at this time) that were easier to maintain but at the cost of performance. Has anything changed?

 

Ha ha ha! Alright man. There is no sense in debating it. I don't know where you are coming from and you don't know where I am coming from.

I think maybe you are thinking I am talking about dropping down to Assembly and programming everything from scratch or something. lol And that is not it at all. I am saying 15 to 16 years ago I was doing 3D demos in C++ and Direct3D (well Direct X in general for reading keyboard, etc). I am not talking about even dropping down to that level with tons of time spent setting up arrays and doing matrix multiplication and the other overhead. Because that would be too much in this age.

I'm talking about simply using a straightforward api to load in a 3D model including animations and then just make the damn game. It's an object. It has coords for its position. It has a state of what it is currently doing. A good api will already have collision checking routines to be used for 3D objects. Worst case you write your own cube to cube or sphere to sphere collision routines. Physics... I am not planning on making Angry birds or any other physics game. But I will use physics. I just don't need science simulation quality physics for a game. And going by some AAA games they would be better off ditching that stuff as well... the point is whether they are doing it or you are doing it IT IS NOT REAL. It is code. A simulation. Theirs is generic one size fits all. Mine doesn't need to be and won't be.

Again I am talking about... maybe you have never used something in between low level Assembly or C++ & Direct3D or whatever and Unity. I don't know. There is a middle ground in between.

I think... I tell you what at some point I will make either a raycasting game or true 3D game outside of Unity and throw it out on GameJolt and when I do I will let you know.

EDIT: Last thing on it... here is an example just to try to illustrate what I am saying... You may remember the old QBasic. And may or may not know there is a fairly modern version named QB64. It is continually updated. Here is an example of a raycasting engine and game a guy wrote in that. Of course he could have made the enemy have better AI but the same can be said for many games made in anything else. The game itself could have much more to it. Again that is completely up to the developer to do that. Want more? Then add it in there.

And my only point with that is... all he had to focus on was making the raycasting engine (which is now likely freely available for anyone to use) and then the graphics and coding of the game. There was nothing else to learn. No other obstacles. It was just focusing purely on making the dang game and whatever issues he ran into with his own code or graphics and so forth. And that makes it a lot simpler.

That is just one example of a middle ground approach between a large game engine and C++ & Direct 3D or OpenGL. And there are numerous options along these lines out there. And quite likely much easier ones than QB64.

 

His profile page doesn't open. "This user's profile is not available".

 

This. I can see his post history. But not the profile page.

 

Yep.
There was DirectX, Xna way of doing things, but there was no tools at all, only few people was able to create their game editor and all needed tools. Today we have high level tools for most game parts and some people are complaining lol
They are coders centric, they expect low level framework, basic editor and no tools but this is not Unity or UE4.

People that never used 3D engines are not heavy coders, they will first learn the tools, it's high level and easy to understand, it will keep their code minimal.

For example with Navmesh you can achieve in some minutes superior navigation , while a coder will spend months trying to code some navigation system or will take a simplistic way like 3D tiles movements only applicable to dungeons lol

 

If I recall correctly, he suggested whoever brought the Lithium forum switch onto us should kill themselves.

I'd say just pick one or roll some dice, and get back to making games. This whole back and forth and looking for the engine or toolset that fits you perfectly in every way doesn't seem very productive or fun to me. But who knows, maybe that's already the fun part for you?
I just don't understand how you can focus so much on "not being able to focus enough on making your game". I have complaints about Unity too, but I don't care nearly enough about the workflows or API, to invest time into checking out all those other options, because that's time I could spend more directly towards making my game.

 

He said he doesn't care about making a game, he does not have the motivation to make one, he likes to experiment low level engines.
Yep this is a big waste of time such discussions, nothing productive only talking for talking lol

 

@GarBenjamin

Pub talk:

I think the posters before me have a point, check out this and reflect
https://forum.unity3d.com/threads/d...ent-faster-or-slower-easier-or-harder.343112/

 

Ha ha. Yeah guys that's because I made the decision several or many posts back. But didn't want to just ignore people replying to my posts.

It's done. And for the record... if Unity makes game dev easier for you and anyone then of course use it. Believe me if that was the case for me then I wouldn't make such posts or a poll like that. I had forgot all about that poll @sngdan. I should have just switched back then but kept thinking there has to be something I wasn't getting.

And there was.... I wasn't getting that a full featured outright game engine just isn't right for me. I can use it to make games but it will never be as enjoyable and simple and productive for me as using only an api no matter how much I'd like it to.

So again it's decided.

 

I don't think it's because it's fully featured engine as a problem.

It's more a very fundamental philosophy. When you are a non programmer, you see everything as tangible objects. Unity allow you to drag and drop asset (prefab), build a level, have some physics and lighting, BEFORE even coding logic. Even logic has been "objectified" as component you drag and drop onto object to gave them behavior. You can have a whole game planned in engine before having a single line of code ever place, from gui to lay out. And it looks like the soft you are used to, be it excel (inspector) 3d modeling etc ... You can make very decent looking 3rd person games with just a parented camera and one script that move the transform with simple code.

Now if you are a programmer (or at worst a designer who script) it's a bit more involved, as it seems most function are hidden behind a clumsy interface, like settig up input in a separate windows dedicated to it, generally badly designed and poorly documented and breaking the workflow of the logic (damn I need to quickly test this new input logic but I can't set the deadzone directly on code I have to hunt down that fraking windows, where it is again, is in file or edit dropdown menu?).

That's what's happening to you, you want to set up everything as logic, not as tangible.

 

I think that is a good way to describe it. And yes to me all of that stuff you mentioned breaks the flow. It gets me "out of the zone" so to speak. Because I see it like part of it is over here, part of it is over there, another part is some place else and so forth and I continually am bouncing all around. And maybe that is due to me just not getting what the right workflow for such stuff is but I think it is more that it has to be done to begin with that is the obstacle.

Again I am not saying it is terrible or something like that. Just that for me it is not the best way to work. I find it more frustrating than I do helpful. And this is not limited to Unity. Gamemaker Studio, UE basically any full game engine works along these lines. I think it comes from the "game engine" part. To bring all of the features available in such an engine it has to have a lot of different things going on, a lot of stuff already defined choices already made. Whether that is GameObjects, monobehaviours with callbacks or whatever. In something else like GMS it would be a lot of predefined events and actions and so forth. By the time I dig through all of that to find out they don't have exactly what I am looking for I could have just wrote it.

Anyway... it would still be cool to see some of the FPS projects that were started in here be finished. And maybe I will dabble on that one I started from time to time and and at least get it to a playable level state. But I will spend most of my time and do my projects in something else. I think I might actually spend some time on an FPS in N6 this weekend. I kind of feel a little of my old love for game dev returning since messing around with that the other day.

 

I really don't think it's just the interface, I specifically out tangible as a philosophy.

I mean pick a simple situation: you pick a coin in a game... Now how do you code it in unity?

- is the player taking the coin (ie detect it has collided a coin and handle the coin objects then increase internal counter that report to GUI)
- is the coin react to the player? (ie detect the player has collided and report to the coin counter)
- is the coin counter checking for collision between player and coin?
- do you need an events passing system to communicate between them?
Basically who is responsible of what?-

Script are good for self contain behavior inside objects, but interactions? They require explicit thoughts. Now this is a simple example that might be obvious to any good programmer. But extend that to a whole game ... that's a whole different way of thinking. There is no implicit order of things between things.

Now contrast to blitz3D, i declare the character, I declare the coin, I declare the coin counter, I place them on level through code, then I have a code that check collision between coin and player, the main body of code has the responsibility of interaction and these are simply self contain paragraph. I write it like I would write a game design document, just list of things and description. It's harder to build level, but faster to build interaction, to add a new interaction I just had a new section. And debugging is "easy" because you go through the explicit order of things.

Both have drawbacks obviously, but they are different mindset. When I presented unity to a programmer, his first question was "okay, where is the main()", that say everything, unity have multiple "main" not only between objects but also inside objects (start, update, fixed update, collision, etc ... even though they have explicit order between them).

edit: IMHO the magic is not monobehavior but script order

 

End of the day unless the only goal is to release a 20+ year old FPS all this becomes somewhat irrelevant, open the source code of something like Lumberyard and UE and you'll instantly notice how mammoth they are in size. They have to be gui and system / feature driven or it would be a complete and utter nightmare to do anything of note.

Using OpenTK or QT vs. modern engines, by the time you have simple collisions I'd of created a modern looking prototype. It took me a long time to figure this one out (as daft as it sounds), but never try to fight the engine.. They are too big, they are too complex and you will always loose.

Y'know on a lot of points I do agree, I have created frameworks using LWJGL and QT (plus the rest).. Knowing exactly what everything is called and what everything does is great, componetising functions into modular flows whilst still using direct calls into your main game CPP / H is fast in a lightweight framework. Although developing any one toolset like mecanim would wipe out any time benefits..

Compared to engine X, Unity's component based architecture requires near enough little thought to get things moving. It is the most simple and effective system I've seen for games within the last 20 years.

If you've only got the odd hour to spend on games development, where you want to push everything from code then Eclipse + LWJGL with basic render function scripts (which you can get from bennybox) is the best way to go.. If you want anything near modern suck it up and learn an engine.

 

I disagree. When you're a programmer you see everything as set of intangible abstractions, some of them implemented as tangible or less tangible objects. It is the same thing as what you're described.

Also, unity - due to framework design, is VERY programmer-friendly. Documentation is good enough, aside from certain obscurities you can usually find anything quickly by using google search. Now, if google didn't keep trying to give me 4.6 documentation, that would've been even better.

Yeah, exactly. First time after making a quick prototype in unity the first thing I thought was along the lines "Man... now a good portion of my knowledge is pretty much useless"

 

I'm not sure how you disagree

I'm just saying they will see the asset and build the asset like a set of toy and not think how everything interact together, because, duh, that's magic, of course it cannot go through the floor. Programmer see both at the same time and understand how one relate to the other. Understanding that the player IS NOT the visual asset but a bunch of abstract class organized around functionality is another level completely.

 

Using "site:https://docs.unity3d.com/ScriptReference" would prevent stuff from docs.unity3d.com/462/Documentation/ScriptReference (and other versions) from showing up. Or "/Manual" for non-script reference pages.

--Eric

 

I'm not going to type that out every time. Use already tracks half of the things I do, perhaps its predictive search will essentially figure out that I don't want 4.6.2 docs. Wish I could just specify this once and for all.

 

It is the one of the common problems of programmers who first try to learn OOP, as it's from a procedural mindset, so rather a specific issue with those who only experienced such a paradigm.

Just to be clear, the disputes over 'magic methods' were quite different from such a misconception. The problem, in this case, was not that they were difficult to understand, but rather that they are violating some of the commonly accepted principles of software design, as they lack accountability, and mingle multiple different responsibilities, and so forth.

Of course, opinions might vary as to the severity or even validity of such problems. But it wasn't about the difficulty of understanding such callbacks, when they were criticized in this thread.

 

I'm not sure why you'd type it out every time when bookmarks are a thing that exists.

--Eric

 

Wow man this is still being discussed.

Well for me I guess it is just something where a person either views it the same or doesn't.

Is a monobehaviour difficult? No. Adding components difficult? No. Heck even using the Animator and states isn't difficult.

But that kind of view completely misses the point. It all does add complexity to game dev. It adds work to game dev.

Again from my perspective it does. I think that is what people are missing here. I have no dream to make GTA 5. Nor Witcher 3, COD, etc. I have no desire or need to get into IK, animation blending and other things AAA games are doing. This doesn't mean that I don't care if a character's feet are floating above the ground when they walk (although I don't care as much as others I would guess). It means there are simple ways to solve problems. And it means it may never even be an issue to begin with.

I think it is still a case where many people here are focused on making games along the lines of current AAA releases. And that's cool if people have the desire and the resources to actually do such a thing go to it.

I see that as a completely unrealistic goal and not even worth spending time thinking about. Current AAA games aren't even on my radar at all when it comes to my own game dev. Games from AAA 20 years or more ago sure. Modern Indie games made by one person in less than 1 year working maybe half-time at best sure. Those are realistic goals (more or less). They represent a solid target for a single developer working part-time.

If other people want to target games like Witcher 3 or other modern AAA games in Unity then knock yourselves out. I will be one of the first to congratulate you if you manage to pull it off some many years down the road! The point is if that is what you are focused on then yes I get why you would need to learn all of these various things in a game engine like Unity. However, the other side is equally true. If a person doesn't have that as their goal they have no need for the stuff.

 

Except it doesn't.

Not relevant, since 99% of people here don't either. We use those Unity features to save time and effort for much smaller games.

--Eric

 

The game that has physics, ragdolls and animation blending is not an AAA. It is basically a minimum standard set of features for a 3d game, unless your goal is to emulate Quake 1. It is absolute minimum. On the "Space invaders" level minimum.

I recall playing, once upon a time Zombie Nation and Zombie Driver HD. Those are nowhere near AAA level - one is racing game and the other is a twin stick shooter.

But they BOTH have those features.

Or there was very fun "Brothers: Tales of Two Sons" game. Masterpiece material, although it can be finished in 3 or 4 hours. Same. Animation blending is there. Physics Was probably too, although it wasn't using ragdolls.

This stuff isn't adding comlexity, it removes it, by providing you a minimum set of features you'll need anyway, and saves you from having to implement them yourself.

Speaking of "Raycast games" (That's an odd name), properly doing those is also a lot of work. Once character with a small number of animation sequnces can easily result in a LARGE number of animation frames which you'll have to either draw by hand or render. Those kinds of things kind a make you appreciate stuff you can do with 3d more.

Also, physics and ragdolls? Those are a very cheap way to avoid making death animation clips. Basically, it is the feature you'll want if you're saving costs or on a tight budget.

 

But he is a programmer who is trying to resist the need to have asset to build too, I think he hasn't made the leap to make everything by code, asset too, he hasn't embrace the dark side of minimalism and pgc, he is still trap in common conception of what a game should look, you can see the dark side tearing him from inside. Come on @GarBenjamin join the darkside, fully commit to code driven asset and minimalist graphic, no more humanoid, no more ragdoll, no more hand, no more wall texture, be done with pixel art, be done with the tradition, became a of full code sith.

 

I'm willing to challenge him for the title of 'Code Sith', as I'm a very persistent supporter for the code centric approach myself

But I'll happily keep my RigidBody or Animator components though, because I think being 'code driven' is something quite different from 'making everything from scratch' or 'confining oneself to the very minimal requirements'.

I'm not saying nobody should do such things, but surely they are something different from a code centric approach.

 

As @neginfinity aptly described, this sort of stuff is minimal requirement for a medicore indie game never mind AAA. Also if I had the kind of money to compete in the AAA section I'd hire a massive team and sit there all day sipping JD's..

Throw artwork out the way and in about the same time it took you to make that Doom clone some of us could make a crappy openworld RPG. I'd love to say it's because of my own skill as a developer but that's somewhat untrue, you take advantage of the engine and it allows you to do so. Take IK for example, it must of taken a whole ten minutes to copy the Unity doc's example and apply it to a distance from NPC array with a boolean that makes the head track the player as they walk by at a certain distance.

Also worked to initialise dialogue sequence by adding basic input, again allowed within certain distance from player to NPC. Also that same system can be re-used for combat system..

Artwork, rendering, lighting, shaders and content is the bane of my existance not basic gameplay logic.. A lot of my coding time is spent optimising shaders, finding issues in complex rendering functions, fixing issues with tools, UI development (for dialogue's, inventory systems, quests etc.). In the time it takes to UV map a small village and build a single character you could have half an event manager finished.

All of this would frankly be impossible if I had to build the surrounding frameworks and API's. If you're going to fight an object / component based system then yeah it will make life more difficult. If you're going to embrace it for modern development you'll be laughing.

As I already said, I can relate though.. After years with XNA / Torque / QT I fought with it, I also fought with Unreal after years of using Unity. The only way I can progress forward is to accept the way they want me to do it.

Not getting into engine debates, but I always wondered why I struggle less with UE than others do. It's because if they tell me to use BP's I will, if they want me to code a specific portion I will.. I go by all their examples even for C++ and never try to stray too far away from it..

 

Alright there is no sense in discussing it. We have very different views on it. But one thing we do have in common is the basic interest in game dev. I wish you all the best of success with your game projects! I hope you make the kind of games you want to make and have a lot of fun doing so.

 

I think that engines are more suitable for certain mindsets with UNity being more programmer friendly.
Unity is also close to general purpose framework, offers more freedom in chosing how to do things, while Unreal 4 tries harder to steer you into their way of doing things.

My problem in unreal 4 was that they forced me to use blueprints (which didn't click for me despite large number of "blueprint-enlightened people") and the suggested workflow ticked me off big time, repeatedly. Since I decided that I'm not going to program anything with mouse, I ended up using unity most of the time.

My opinion may change again someday, though.

 

Gar, of course I'm not or never will try and tell you what you should think (ever),.! I do respect (and understand) your opinion and I'm seriously glad you've found what works for you.. Although it's not just about you , I think a lot of us are trying to understand our positions as well and backing / forthing about what works for us clears the air.

At this point it's more for us than you.. Especially experienced developers like @neginfinity I'm sure we can get stuck in a trap almost. I agree with him, can't say I'm a fan of them imposing visual scripting on us either but when you look at the alternatives (I have dug through the source a couple of times) it is a lary imposition to go against it.

I think quite a few of us are at that stage where we've done our basic projects, I started off with the stealth demo in Unity and learnt from that to create a top down game.. Now we want to move on, but in games it's not a linear progression to bump up to the next step. It becomes harder by an order of magnitude and you'll run into issues where the engine starts dictating what you can and can't achieve.

Like UE imposes blueprints and from what I've seen dynamic games are interesting, Unity somewhat dictates scale due to performance and systems. Point being, you have to compromise (or move) at some point..

 

No worries man. Yeah it is a balancing act for sure. And I think that is where the disconnect is in this discussion. For me it is all about maximizing productivity in completing a game of a certain scope and presentation quality. And no doubt much of the difference between myself and most Unity developers is in what we feel are the minimum requirements for presentation quality.

I think complex precise animations, complex fairly precise physics, complex visuals in general have their place and can add value but don't see such things as a minimum. This is what I meant by AAA. Maybe that term causes the misunderstanding. What I mean is I view it like it is the AAA game loving players that want that stuff. These are the people that everytime something like Witcher 3 comes out they then expect a Witcher 4 to be twice as big and look at twice as good and take 4 times the money to produce. That is basically the mindset in that sector judging from the various posts I have read around the net.

I don't think a hobbyist or Indie needs to focus on such things. I think some people do because they enjoy doing so and I think others do because they are targeting AAA meaning they kind of have that same mindset... if so and so popular game had triangular reverse split rasterization (fake buzzword for sake of example) they feel every game and certainly their game must have at least that.

I don't share that view. For me I want to make a very good and interesting game and I think that has less to do with tech (physics systems, animation, shaders, component-based design, 2D or 3D, to ragdoll or not, etc) and more to do with game design and implementation within the context of the goals of that design.

The tech part is just a choice and people should of course use whatever makes the development process the easiest and fastest (i.e. reduced cost) to achieve the same basic end result.

I'm planning on doing some dabbling in this and that for a while and then I'll figure out what to do. I played around with a couple 3D engines... err no not engines... libraries (I mean some are full engines but I look at those to see how much am I forced to use and how little can I get away with using... how proprietary is the basic concept, etc) over the weekend. Some are just monstrous beasts which is exactly what I am not looking for. But some look promising as well.

Anyway good luck man on your game. Hope to see that WIP thread!

 

No indie will make alone what is done by a team of 100 or 300 people working 5 years and polishing every aspect.
Many indies are clever and focus on the right aspect taking account of their time and budget

I find such games that don't hesitate to throw in multiple gameplay and ideas lot more fresh and interesting than all these FPS or medieval hack n slash rpg.
For example a small game like Radiation Island ( www.youtube.com/watch?v=4UbBwMLtxTI ) , it's far from perfect, but the overall quest, upgrades and content was good enought to keep me playing it, i found it lot more interesting and enjoyable than some already seen AAA games.

Anyway i don't expect to play some game from you soon lol

 

I have been playing around with Unity now for a good year, learned a lot and still have much more to learn.

So far I have only developed for family use and some C64 nostalgia with shaders, so no external market but I have like many others a few (abandoned) prototypes on my hard drive (some fairly complex) that started as something I thought would be worth to release.

Feedback Friday54 @iamthwee posted something that reminded me of one of my test projects (that was never meant for release). It is possibly my simplest Unity project (approx. 40-50 hours development time, mainly levels). After that feedback Friday (thanks to @iamthwee I enhanced the visuals / presentation a bit), I decided to put it on the app store.

Getting an account, learning submission requirements, updating Xcode versions, generating required assets, setting up a support website, learning about keywords, etc...that took the same amount of time than developing the game.

My key take away, invaluable experience...if I could turn back the time, this should have been my first month Unity project back then, having a live project makes you see things you never think about.

Long story short and not to derail the thread, Unity helped a lot in this process. I was able to throw out a webgl build for feedback friday, compile the same code to IOS, add crash reporting (no crash so far !) and analytics (30 minutes reading and done). Seeing level progression + regional use and understanding the reasoning of it (mixing this with ios connect data) is really fun + the world map with live connects (a toy, but a great sense of achievement).

There are so many tools at play, when developing (in particular if it is a more complex game) and I think if you want to publish, then a lot of the smaller engines might fall short, or you have to invest a lot of time in programming functionality that comes out of the box with Unity (cross platform, services, etc.)

Again, I am not biased towards Unity, I guess all the other more sophisticated engines have similar functionality and their complexities. Recommendation: Get something on a commercial store as fast as possible to learn (not to earn) and give you an end-to-end view on the development tool you are using.

edit:
@zenGarden - yes, agree realistic scope is important and of course it should not be total crap The game you posted is way more sophisticated than my one...

 

+1
It will give you an overview about how much time it is needed, and you'll learn a lot from reviews about the polishing aspect si important ( appealing UI, sounds, effects, presentation , gameplay fun ).

What game ? Morphite or Survival Island ? both are sophisicated and polished to some degree.

Did you tried Godot ? It is far from advanced as Unity for example, but it is easy to use and it is very lightweight , perfect to make small games.
GD script is cool, streight forward, and editor has intellisense like editing

Code (CSharp):

1. extends Position3D
2.  
3. # class member variables go here, for example:
4. # var a = 2
5. # var b = "textvar"
6. var  ray = null
7.  
8. func _ready():
9.     ray = get_node("RayCast")
10.     set_process(true)
11.  
12.     # Called every time the node is added to the scene.
13.     # Initialization here
14. func _process(delta):
15.     if(Input.is_key_pressed(KEY_UP)):
16.         self.translate(Vector3(0.3,0,0))
17.     if(Input.is_key_pressed(KEY_DOWN)):
18.         self.translate(Vector3(-0.3,0,0))
19.      
20.     if(ray.is_enabled() && ray.is_colliding()):
21.         var collided = ray.get_collider()
22.         if( collided.get_name() == "Cube1"):
23.             collided.hide()
24.     else:
25.         get_parent().get_node("Cube1").show()    

 

I looked at Godot before and seemed the same as the "big ones" to me. Just maybe simplified somewhat but same thing the tutorial I watched had you immediately jumping into an editor and messing around. Thanks though I appreciate the suggestion.

Good! lol It will be a while for sure. I am not putting much time into this stuff so I may very well spend all summer just dabbling in this and that. Basically, I just think all of this stuff can be much simpler and faster. A big part of that for me is I have worked in many other things recently even.

Right now I am leaning toward AGK2 or IrrlichtLime for 3D. But first I'll do the simpler 3D-rendered game (the wolf3D style raycasting). See, it's not just the getting rid of the extra layers in the code that I am after it's also streamlining the content production. So I have been checking back into stuff I found years ago to see how far it has advanced. For 3D models one nice thing is 3D printing has become very popular and because of that a lot of money has been poured into solutions for the average Jane and Joe to be able to super easily & quickly produce 3D models for example.

For example, there are many solutions now for producing 3D models from photographs. And some are very slick indeed.

Of course, the ideal is something like this. Shows if you really understand the secret animating models is a super simple & fast process.

Ha ha! We're not quite there yet but honestly I wouldn't be too surprised at some point in the future that will be pretty much real. Just a massive built-in library of canned animations and some customization combined with speech recognition. Unfortunately, the graphics creation side always seems to lag behind. It is getting there though!

Things like Smoothie-3D would certainly ease the content production a bit. Again result of the 3D Printing boom.

What is needed is for the average Jane & Joe to have a need for animating their models. If that happens then we'd see the same kind of investment poured into making it incredibly easy & fast (and maybe even free) to animate these models. But it has to be a business model like the 3D printing. See the 3D printing service providers and manufacturers of course wanted to make 3D modeling as accessible as possible for the average person because they make their money from the printing.

Anyway... I will keep investigating. I might just find an animation solution in the robotics industry or something like that. Perhaps in video production but I checked that sector a little already and didn't find it.

I don't know if this was just a hoax or not... I wouldn't doubt it was legit and seems to be... but haven't heard anything more on it since. If it was a hoax at that time I expect it to be real before too long. Would certainly be helpful for people to quickly knock out a lot of content for use in FPS and RPG games.

 

Gar, I'm somewhat familiar with modeling/animation:

Spoiler

And as far as I know, magical "we'll make 3d object for you from photographs!" solutions are usually junk.

As far as I can tell, there's no real secret to modeling/animation aside from pouring XYZ (hundreds of) hours into practice, stubbornly trying to make what you want, repeatedly failing and slowly, progressivley getting better. It is a tedious process.

There's photogrammetry, but it requires babysitting, human processing the end result, and basically means that in instead of wasting X hours making the character, you'll need to own expensive photo cameras, lighting setup, will need to find actual actor, make costumes for then and apply makeup, only to have a model that will need to be manually fine-tuned/retopologized in the end.

There are also copyright issues, I recall someone got into trouble scanning a statue somewhere, even though the statue was a replica of a public domain work.

 

Definitely need to be careful what is turned into a model and included in any form of media released publicly. I'm more thinking in terms of my front yard, animals, insects, basically all of nature (because thankfully nobody has claimed ownership of those yet except for God and I think he doesn't get into copyright claims) as well as being able to quickly sketch enemies, etc on paper and turn them into 3D models.

It used to be junk but seems to have progressed a lot since I last checked it out. I wouldn't say we are there yet but one day it will be hopefully in time I can use it. lol That would be the only way I would focus on making higher quality visuals otherwise focus is on ultra basic low poly flat shaded (which I do think it is nice look in itself).

I've actually been thinking modeling and animation tools in general are quite lacking. There are a few companies doing some creative work (such as drawing motions which become animations) but for the most part it seems to be basically the same stuff going on now at least for modeling as it was long ago.

I guess I kind of just question everything anymore for good or bad. It's actually the animation part that I think is mainly the issue. Although I also think the modeling part can be improved. I think maybe I will dabble at some point in making my own utility to build models and create animations or else hire someone to build them according to my specs. Maybe that's it... I need to basically reinvent everything. lol

 

If you're using photo of something, and haven't taken the photo yourself, then copyright belongs to the photographer.

"Quickly sketch" in 3d is "one or two hours". If there's a way to do it faster, I haven't found it.

Nothing comes close to speed of 2d drawing, because in 2d you can quickly sketch something in 30 to 60 seconds.

 

I mean photos I take and things I sketch. Although I suppose I would need to at least shade them in.

You're right and that's what I mean. I just don't accept it. I may need to but for now I think there is a better way even it still needs to be created. Worst case back to cubes and spheres or just ultra low poly or ultra low res pixel art. But doesn't hurt to explore and think about it for a while. So I'm thinking many nights over the next months I will probably sit with a beer and ponder.

 

I'm not denying that it's still the best (or even only) viable option to do 3D modelling by hand for now.

But I'm quite positive that building 3D models from photographs will be practical and even a norm in not so distant future, considering what kinds of things that the machine learning technology is capable of.

Today, there exists quite a hurdle for people to learn 3D modelling process, because it's not always intuitive and also very time consuming. And I guess we already started to see some changes as the advent of PBR textures, for example, have made such 'technics' which artists had to learn in order to make their model look more realistic to be obsolete. And now we are quite close to the stage where a software can generate suitable PBR textures from an arbitrary photograph.

Considering all these, I think it's quite reasonable to assume that we'll see an actual, practical solution that generates 3D models from photographs, using machine learning technology soon.

Of course, it will take some time before we begin to see such things put into practice in the industry. But I'll bet in the next 15 years or so, such a knowledge of constructing meshes with vertices using a traditional modelling tool will become completely obsolete, and probably we can say the same thing about creating animations by manual rigging and changing bone positions, too.

 

There was a potentially better way in a program called SmoothTeddy. This one was used in GraffityWars and MagicPengel. Nobody really ever picked the approach up.

The problem with using photographs is that you're not creating anything new and are not creating stuff you can imagine. So you'll STILL need someone to make the thing for you to photograph.

I think that relying on photographs will lead to a dead end.and generally uninspired works.

I think at some point there will be AI-assisted tools, but I don't see anyone working on this kind of tech.

------

Also... people often treat machine learning for some sort of magic that will solve all the world's problems. Those tools have specific application, and their primary applications are classification problems. While it is possible to tweak imagenet classificator to produce deepdream images, it is worth keeping in mind, that original data required a week of training on a cluster. This is not exactly practical.

Applying those to animation also would require impractical amount of sample data.

Now, there's stuff like this:

But I haven't seen anyone turn it into a viable product, plus rather than a neural net it is a genetic algorithm.

 

If a machine learning algorithm can construct a 3D mesh out of a 2D photograph, it'll be a short step toward applying the same technic to 2D illustrations. And it's hard to deny that drawing is a much more intuitive way to express what you imagine in your mind than merging or extruding vertices.

And even if such a technic cannot be applied to convert illustrations to models immediately, I don't think there's any doubt that it will make the job of creating video games tremendously easier once realized, considering how many video games we have today, that mainly use such objects, like buildings, cars, guns, and etc that we see and have photographs of in real life.

 

Well there you go! That is what I am talking about. And the related videos that show up on that one you shared led me to GRSketch.

Although I was mainly thinking of sketching whatever I wanted I had only thought of that as a first step and then taking a photo / scan of it to get to the model. This is even better just sketch and make the dang model. Much better than using splines and extruding and such. So that is what I need to explore. Would make the modeling significantly faster for me at least.

Well it looks like some other folks out there have been using their heads trying to make this a lot more enjoyable.

I'll explore all of these things and see where I end up. Might just work for my needs because I am not targeting HD AAA type stuff just a way to get some decent content knocked out quickly. So this seems like a good direction for further research. Glad you posted that video.

 

Definitely not. Underlying data is very different, and unless your sketch artist sketches in hyperrealistic style, photographic classificator will not work on illustrations.

 

The source materials don't have to be hyper-realistic for a machine learning algorithm to process, as it only requires sufficient number of input data that it can compare and analyze. If you have drawn a Unicorn, for example, it doesn't have to be photorealistic for a machine learning algorithm to identify it as something like a horse with a horn, provided that it already 'knows' what horses or horns look like, from analyzing other input data.

And from what I've observed, even the very original and creative artworks are often based on reality to some extent. Fantasy games, for example, usually feature artistically modified version of reality, like some medieval looking houses or weapons which don't exactly look like their historical counterparts, rather than inventing only the most exotic concepts that nobody has ever seen before.

And more importantly, even if there could be such games with so original content that can make it difficult to use such technology, they'd be an exception rather than a norm, considering how many truly 'unique' video games we have today, compared to more generic RPGs and FPSs in the market.