Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Does Unity make game dev too difficult?

Discussion in 'General Discussion' started by GarBenjamin, May 18, 2017.

Thread Status:
Not open for further replies.
  1. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    3,015
    There is absolutely nothing wrong with C++. I have used it longer than C#, since C++ has been around longer. My comment about C++ was in reference to what Braineeee said about a team claiming Blueprint would save them from coding. Some people try to build an entire game using only Blueprint, and my point was that at some point most serious UE4 games will need to use at least some C++. If a team has nobody with C++ experience, that can be a problem when using UE4. My comment was not a negative comment regarding C++ itself.
     
  2. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    That's what I did at one point on the way to my "final" code oriented approach. I used prefabs for everything but all managed assembled in code. Later I threw out the prefabs and just used the scene / project views to create pools of game objects.

    But... I'd like to connect with the visual way of doing things. So when I get back to game dev again (like that community rpg or whatever) I'll try to use the visual approach. I know this is the disconnect for me. I have a feeling many people here see a game and mainly see the graphics and when I see a game I mainly see the data, systems and interactions.

    I have a difficult time moving from throwing art out there "hanging" (on nothing) in virtual space and starting from that point because I am used to data driving everything. Data model(s) exist first and then the visuals are created based on that.
     
  3. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    So.



    Newtonian physics. Movement is based on real numbers and computed based on planet's masses and gravity. Moon orbits earth, earth orbits sun. The ship shoots past the moon and flies by the eearth.

    Given that it didn't take me too long to implement it, you could've fixed shaking problems in your game long time ago.

    P.S. I'm still not sure what was supposed to be funny. Or why you haven't done something like this by yourself one year ago.
     
    ShilohGames, Murgilod and Martin_H like this.
  4. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    I also have a very code oriented mindset, as you probably remember. Actually, I'm leaning so much towards the programming approach that the first and only project I started with Unity was one that would make that approach better (link in my signature), and currently I'm trying to write some Java Swing like wrapper around IMGUI, so that I could use it instead of the default Game Object based system for everything.

    I've been trying it with Zenject and UniRx, and so far I'm more or less satisfied with the direction it is going. I've met some rough edges, but as both of the frameworks are open source, I could easily look into their code if necessary or even suggest changes. And they also integrate nicely with Unity as well, for example the former has direct supports for Prefabs or Scriptable Objects, while the latter can wrap various MonoBehaviour callbacks into Rx observables automatically.

    So, I'd recommend you to try them out sometime, if you like the programming approach like me. I feel it to be much a better way than such 'just write bunch of quick and dirty scripts to slap onto game objects and be done with it' type of the approach which I really couldn't get myself accustomed with.
     
    Last edited: May 21, 2017
    GarBenjamin likes this.
  5. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Then why at about 18 seconds in does the scene window show a tiny moon wireframe going past your wireframe spaceship, or is it your spaceship is huge.

    I can believe you have written a quick double precision system and scaled it into the Unity scene. However I think if you were to land your spaceship it would look like something off Independence Day 2, with a giant spaceship hitting the planet, please prove me wrong?
     
  6. Deleted User

    Deleted User

    Guest

    I've never actually tried to make a game in BP's start to finish, reverse engineered the examples.. Sorry if I got the wrong end of the stick, I think my point (and the point I keep making) is both Unity and Unreal make as easy as it's going to get in terms of games development.

    They have both come a long way and there's a lot of helpers that weren't there before..

    @GarBenjamin

    Why would you see data interactions and interactions when modern RPG's are based around UI's / environments and character event systems? I mean you need at least base characters and an environment to react to..

    Think of it this way from a coding standpoint what are you going to need? Inventory system (which needs a UI (art)), combat system (which requires characters and animations plus UI (art)), AI / pathfinding derivatives (which interacts with its environments (again art)), dialogue system (UI based again) but event manager driven.

    Things like skill tree's whilst difficult to balance is trivial to code, the next thing might be data management feed via .JSON / Excel or SQL if it's large again usually to list the amount of art assets (as well as quests / event tracking etc.). We might code up some inverse kinematics, but that's again based upon having the art ready..

    The character controller is so trivial I'll not even mention it (plus the likes of UE comes with frameworks). Sorry if I seem to be going off on a tangent here, but it seems a little chicken before the egg.

    The real problems stem from things like optimisation which is generally caused by art, optimising shaders and so forth. In this day and age you wouldn't be doing things like adding your own occlusion systems or animations components, vertex paint tools, phsyx components (like ragdoll / interactive) etc. etc. You'd save yourself years of "coding" development by using the right toolset (or engine)..

    By the time it takes me to make a street in a city, I could of coded up most of the game.. It's always an afterthought.! Well to me at least.
     
    TeagansDad and GarBenjamin like this.
  7. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Ugh.

    I spawn visual proxies at different layers. I think I've explained it previously. 3 stacked cameras,one camera per distance layer.

    Screenshots:
    screen.png screen2.png
    screen3.png
    Pictured: 20 meter big ship, moon with 1700km radius, and earth with 6500 km radius. Earth is selected.

    Ship's "radius" is 20 meters.

    Floating wriframe in scene view is scalable view for purposes of visualizing where things are.
     
    Last edited: May 21, 2017
    neoshaman likes this.
  8. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Go play Kerball. It's all entirely doable within Unity. I don't see why you are arguing this when such a clear example of everything you want is right there.

    While we are in the topic, the Skyrim map is only about 8km along each side. Which is probably within the limits of 32-bit precision.
     
  9. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    It is. Basically, if you take "number of significant decimal digits" characteristic of floating point (which is imprecise, and decide that you want to maintain 1 centimeter precision, then you can calculate how big your scene can be without employing any tricks.

    Single precision floats technically have 6..9 decimal digits precision, meaning safe scene size will be between 1000000 and 100 000 000 centimeters. Meaning at least +-10 kilometers. Since single precision floating point uses 23 bits to store values, actual number is probably higher, and sticking to +-10 km cube will actually allow millimeter precision in the area.

    Regardless of approach, large scale scene will require tricks, single precision or not.

    For example, sun can be technically called a point light. However, if someone tries to render scene on earth with sun acting as point light - you know with cubemapped shadows, then shadows in the area will be horrible.

    And yeah, kerbal almost certainly uses the same approach as I did in that quick example from earlier.
     
  10. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    I suspect I have a slightly different point of view than @GarBenjamin 's as he's talking about a data driven approach while I'm mostly concerned with the traditional OOP way. However, I believe the differences can be ignored in this context as they are both something we can call a 'code centric' approach.

    Anyway, the way I see it is that what we see in Unity's editor and the code I see in my IDE are just two different representations of the same thing - the former being a visual, and interactive representation of your game world, while the latter being a conceptual one.

    While I'm not entirely denying the usefulness of GUI editing environment which Unity provides (it would be a madness if I do so), but I want to have a comprehensive, and well structured conceptual model for my game too, because they can be sometimes more intuitive to use for a programmer like me, or can be more powerful for doing certain tasks.

    Ideally, it'd be best if could Unity allow us do most of the things we need for creating a game in either ways, so we can choose depending on the situation or preferences.

    And while I'm not denying that sometimes, you can just make everything visually, using some GUI oriented logic system, and behavour tree editor, and etc, but there are other examples where actual coding can create something very powerful.

    Consider, some of the most advanced mods from Skyrim, like Frostfall or Requiem, for example. They wouldn't be made possible if there wasn't such a well defined set of high level programmatic view of the game world, so I think it all depends the kind of a game you are making, and your personal preferences.
     
    Last edited: May 22, 2017
    GarBenjamin likes this.
  11. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    3,015
    I have worked with both Unity and UE4, and I definitely agree that both Unity and UE4 make it very easy to make games. I even played around with Blueprint in UE4.0 back when UE4 was first announced. Blueprint was ok was for simple things, like making a door open, but Blueprint was a mess once I tried to do anything more complicated than that. I honestly believe that every serious UE4 game will hit a point where Blueprint actually makes it harder than just using C++. That is my general take on Blueprint. If I was building a game in UE4, I would use C++.

    I not saying there is no use for Blueprint or that nobody should ever use it. I am just saying that Blueprint is the wrong tool for doing anything complicated. Theoretically, an artist with no knowledge of C++ could build an entire game using Blueprint, but it would be very painful.
     
    Kiwasi and neginfinity like this.
  12. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Oh yeah of course graphics assets are needed. I am not saying otherwise. I'm just talking about approaching the development from a different way than what Unity seems to be designed for. Basically it would be get some basic content for the game (generally placeholder stuff) but that stuff has no meaning in and of itself. It is the underlying data and the code that brings everything together and brings it all to life.

    Basically like @mysticfall mentioned. Yes, not saying completely data driven but... kind of. I see all games as ultimately being just data. Whether objects in a true OOP sense or structs, arrays or lists, etc it is all data. The logic is what drives everything. Logic changes the data and those changes result in the visual and audio representation changing accordingly. That is how I have always approached it.

    The visual representation of the UI is just that. It is the logic that powers it all and brings meaning to it. And more than that the visual and audio side can be swapped out easily enough. The important thing is to make sure the logic is correct. If the UI logic is working correctly that is the key. Character interaction, events etc again all logic. It is this stuff that is the game.

    The visuals displayed in any game at any one moment are just one representation of the state of the underlying data at that moment. And that visual representation can be swapped out. Same exact logic but swap in a different character. Swap in a different model for a door or a chest, etc. It does not change the game although may change the feel / vibe of the game. Maybe a wooden chest for a standard medieval style rpg is swapped with a metallic locker for a sci-fi style rpg. Yet same logic drives it all. Doors may all swing open in the medieval style rpg and maybe they all slide open in the sci fi. Different visual (and likely audio) representation of the same underlying logic and data.

    So for me it is just a different way of doing things to start with the graphics and work on the game world visually and have that drive everything else. To just have a scene sitting there with art assets in it but no meaning for any of it. No data describing it in anyway. I would figure out what data is needed. What systems are needed and so forth. Then can test that with any visual and audio assets.

    Now, I must say I have made progress in tying the two sides together. It is still odd to me but basically using empty GameObjects to provide metadata about the visual representation. But I prefer just scanning everything in the scene and building lists of objects that I then work with in the code. So everything out there in the scene has an object backing it up on the code side. And then I code against those internal objects and as needed update the visual representation out in the scene.
     
    Last edited: May 22, 2017
    Deleted User and mysticfall like this.
  13. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    If I did that then I'd never release anything because it could always be made better.

    I'm always working to "the best of my abilities", but within that there's still going to be a focus, generally "fast", "good" or "cheap". We were talking about how quickly something could be done, so my brain defaulted to "fast" mode, and the end product would absolutely reflect that. That said, as a professional sometimes it's important to be able to do that - getting a thing done as quickly as possible means managing to tick all of the boxes without spending a minute more than you have to on any particular thing. (Though clearly you don't want to find yourself in that position too often!)

    That starts with a vague communication as to what "X" is in the first place, and snowballs from there. Even within experienced, professional teams you'll find the same wild variations in estimates until the thing to be done is defined in detail.
     
    Martin_H likes this.
  14. Deleted User

    Deleted User

    Guest

    It does seem to me we are somewhat overcomplicating this, if we were talking minecraft or a code orientated game then I'd tend to agree. But when it comes to a modern RPG the code is one of the least time consuming / trivial parts, just make sure you adhere to proper component based derivative architecture with as little in the way of dependancies as possible.. @mysticfall, yes I have worked the creation kit, it's a good insight into how bethesda make games.

    When you're prototying it's neither here or there, you'll generally be playtesting your sandbox to make sure NPC's are doing what they're supposed to be.. I do both as and when needed, bearing in mind I will eventually have to move to an event system with a feed (like .Json / SQL)..

    As you'll probably need a fair amount of experience to pull off an RPG that's well optimised, again game logic isn't the part to be concerned about, it's the art that's the real issue (and what that brings).. Also I'm kind of wondering why you're mentioning it in a thread about Unity making game dev too difficult?

    It has occured to me recently that a lot of RPG's mechanics are a little too simple, but I believe that's for another thread :)..

    Literally just curious ;)..
     
    Last edited by a moderator: May 22, 2017
    GarBenjamin likes this.
  15. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Ah you know... it's the nature of threads. One thing leads to another to another and all kinds of nooks and crannies are looked in. :)

    The reason we got on the code is because of mentioning the Editor and me striving to make working in a visual "art first" way make sense to me. So I was explaining that I am basically not an "art first" kind of person. I always think in terms of code, data, interaction... basically "the game". I mean sure I think about the art. I have an idea of what it may look like but I don't start there.

    Anyway, I think I see what you're saying. You're talking about the scope, right? The greatest scope of work for a modern rpg is in the creation of all of the content that is needed. I agree with that. I think there is still a lot of coding and various systems in place and generally working together in harmony so I do think there is a good size scope on the code size too. Of course everything can be scaled and simplified we know that. But yeah the amount of content especially combined with the quality of that content almost certainly makes that the bigger scope of work.

    Still I see it like that doesn't all need to be done up front, right? The game could be created with the simplest of art or a subset of final art (perhaps resized, recolored, etc to represent the unfinished art) and then when the game is all up n running a person can spend however long they want to just making content. And this just seems like the most logical way of approaching it to me. And if we look out there it seems to be pretty common approach in general. Updates come out releasing new content. Expansion packs are released that provide new content. As long as you have that core game actually complete... the logic, the data... you are at a golden point and then can spend however long is needed to continually produce content and release it to your raving fans. I think. :)
     
    neoshaman and Deleted User like this.
  16. Deleted User

    Deleted User

    Guest

    It's just a matter of preference really, it does makes pathfinding / AI harder without the scene down though.. Actually a lot of games start with the UI first, then move onto the art. They might not open the editor for ages.. I was discussing it a while back with ZombieGorilla.
     
    GarBenjamin likes this.
  17. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    I might be wrong, since I've never created a modern RPG game before, or just any game for that matter :cool: But isn't it more like the case that the code used in such a project is not actually trivial, but the complexity is just hidden behind other assets you purchase from the store?

    I believe it would be more likely the case, because most of the assets I downloaded, including fairly simple examples contain quite a lot of scripts with them.

    Probably, if you follow the typical 'Unity way' of doing things, you might seldom need to look into any scripts you didn't write yourself. Or if any coding is needed, it would be just quick scripts to glue everything together, in which case, it can be justly said it's trivial to write them.

    But we can say the same about art assets, as we can create quite a good looking RPG game just from aggregating premade art resources from Asset Store. In some cases, it might work, but in other cases, where identity or originality of the game is largely dependent upon the art direction, you can't just build your entire game out of generic artworks other people have made for you.

    Probably the same thing can be said of the code. I agree that something like carefully designed abstraction layers won't be really needed for some types of games. But if you want something more than a generic yet another RPG game, you might need some unique edge, and that edge can very well be found in the coding department as in art.

    You might be able to make your game truly moddable, in which case you will need a very well defined high level API to begin with. Or if it could be some unique gameplay mechanism, be it crafting, companion, building, AI, or whatever area for which there's no premade asset item available on Asset Store.

    Or you might simply want to reuse the base of your game for the next one, but don't want to do major rewrites everytime you need to swap out some part of the system with a better asset.

    I believe there would be a lot of such examples, in which writing codes is more than something trivial, or even crucial to make your game successful. You can't create such games like Eve Online, Kerbal Space Program, Second Life, and etc which cannot be possibly made by simply purchasing some generic scripts and throw tons of top quality art resources, for example.

    So I believe it all depends on what types of games you want to create, and which approach you feel more comfortable with.
     
  18. Deleted User

    Deleted User

    Guest

    I actually use Unreal for my project that doesn't have pre-made art (well besides speedtree) / codeworks and it's all in C++ from the ground up (besides the engine of course). When you've been coding for ages, spent time with XNA / Torque / CryEngine and open source engines.. When you've prototyped several games and built frameworks from scratch in OpenTK, LWJGL and QT.. Coding game logic for an RPG is trivial at best..

    When it comes to optimising shaders / rendering systems / procedural tools / tools in general etc. it can become much more difficult, but if you're smart you'd use the engine with the correct feature set for your project.

    I said RPG and I was talking about an RPG, I didn't mention games like Kerbal Space program, the asset store stuff is completely irrelevant as already stated.. But even on that a player doesn't notice code, but if you check out steam they do notice pre-made art..! (it's not always a good thing either)..

    As for the rest, well a lot of it is common and going to the lengths of an editing system for modding can be quite a task but I don't personally believe it's worth it / I'm not interested.

    So with that in mind, is there a point you wish to discuss?
     
  19. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    I think what he's driving at is that most of the gameplay code in a modern RPG is stuff that's been done many times before, is well studied, and is not technically challenging in and of itself for an experienced developer. Interactive objects / inventories, quests and dialog systems aren't necessarily "trivial" in so far as they're light on code, but there's going to be little if any ground-up research you need to do there.
     
    Deleted User likes this.
  20. Deleted User

    Deleted User

    Guest

    Exactly and I'm not saying it doesn't take time or it doesn't take skill.. The ultimate point is modern RPG's are extremely art focussed and that's where the major effort / challenge lies.
     
    Martin_H likes this.
  21. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    I've been coding for ages also, designing many complex frameworks and systems in the past, but I don't think it entitled me to declare that there's no other way to do it than I did myself, in any of the area I feel familiar with.

    If you say coding is not as important as art in typical RPG games, I'd probably have agreed. But there are always such games which try it in a different way, and usually those are the ones that succeed and have potential to redefine the genre or set up a new trend.

    Just imagine someone declaring, "I've been writing games for the past decade so believe me, you don't need anything like a public SDK or a mod kit in a game" before modding became trendy in the industry.

    Ok, sorry about KSP. But what about Eve Online, which is according to Wikipedia, "a space-based, persistent world massively multiplayer online role-playing game". Do you truly believe it would be trivial to code something like that?

    There will always be such games which try to do it differently, and RPG genre is a no exception to the rule.

    Wasn'it one of the main points of the OP to evaluate cons and pros of the code centric approach? And I see no point in being aggressive.

    I actually agree, it's just that I found the need to qualify the claim to typical RPG games, because I felt him to be over generalizing for the entire genre.
     
    Last edited: May 22, 2017
  22. Deleted User

    Deleted User

    Guest

    Well that's what we call "nitpicking a debate to equal on our own terms" or semantics, if you want to discuss redefining a genre post a thread in the game design section.

    If we're pulling the semantics train, that's an MMORPG and something completely different.. Made by a crack team of AAA developers, you never know it could be quite trivial to them.. I saw an interview with Ubisoft (another AAA games developer) saying the art pipeline again was the real challenge.. (I'm guessing you're new to games right)?

    But Unity is mainly aimed at indies, so one can assume games like that are out of scope in terms of discussion.

    Unless your an asset flipper or cloner most do try to do it "differently" try being the operative word there, I can't even fathom why you believe any part of this discussion is "aggressive".

    Maybe I am, maybe I'm not but it still doesn't change the fact that generally art is the biggest challenge in a modern RPG... I'm sorry if this doesn't appeal to your coders pride and sets a path of semantical back and forthing.

    But the issue still remains the same, you do know we are talking about game logic right? Not all the issues that come with fringe examples that require their own engines from the ground with seleted middleware integrations to be able to actually run the game at any decent performance.

    Again, I'm assuming Indie level (that's a broad term within itself, but usually means smaller) as we're discussing Unity..
     
    Last edited by a moderator: May 22, 2017
  23. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    At first, you simply said "coding a modern RPG is trivial".

    So, I argued such games like Skyrim might need serious coding work, because of its modding capability.

    Than you simply responded with "I'm not interested in modding." (From when this discussion has been about your personal preferrences?)

    Then, I said not all RPG games are trivial to code, because of such examples like Eve Online.

    Then you began to backtrack your arguments like:

    "MMORPG is not an RPG." (Ok, that 'RPG' in 'MMORPG' must mean 'Rocket Propelled Grenade', then)
    "Unity is mainly for indies, so an AAA RPG games don't count." (Didn't you say 'modern' RPG?)
    "It can be trivial for AAA developers."
    (Didn't you just say we were talking about indies?)​

    So... who is "pulling the semantics train" you say? :rolleyes:

    All I said about you before this post was simply that you might be over generalizing it.

    So, if you believe you've been super friendly when you implied that my arguments were 'pointless', or that I was 'nitpicking', or that I'm saying this out of my 'coder's pride', and etc then I don't see any point of continuing this discussion with you, because you seem to have such a rare talent of redefining any word to mean whatever you want.
     
    Last edited: May 22, 2017
  24. Deleted User

    Deleted User

    Guest

    Can it not be an modern RPG and made by an indie? Skyrim is a "typical" RPG to me and modding support holistically is by far not the difficult bit (which is odd you're insisting as you've never made an RPG). I just mentioned it's something I'm not personally bothered with implementing, although never say never and it's not the first time I've added modding support.

    Yes it requires work like any game but there isn't anything specifically difficult about it.. It's just a matter of time to get that massive world working smoothly.. They kitbashed the art and kept many systems as basic as possible, I admire the simplicity of the design as opposed to a game like Witcher 3 where the event driven system must of taken who knows how long by itself. But even W3 only becomes complicated due to scale, not because the inherent systems are that difficult and art is still the main challenge

    It's not called backtracking when it's a fact, but sure lets not let facts get in the way of opinions.. An MMORPG is not the same genre as a bog standard RPG, Unity is mainly used by indies (I never said AAA RPG's don't count, stop making stuff up and misquoting).. It just seems prudent in a discussion about Unity and indies to talk thusly..

    It could be trivial to a massive team of awesome dev's, I don't really know I've never attempted to make a AAA space fairing game like Eve Online, neither have you so you don't know either..

    I'll apologise, I'm nitpicking because you're nitpicking and two wrongs don't make a right. Although discussions that devolve into this just ruin it for everyone and is one of my major bug bears.. You're not even trying to empathise or understand where someone else is coming from, you're just too busy trying to get one over..

    Yeah I might be generalising a bit too much, but I've only played one RPG in X many years thats worth going against that generalisation and that was only really impressive due to scale and execution.. If removed into a smaller example it would be like any other "typical" RPG..

    Now if we want to continue in a mature vein and try to find some common ground cool, if it's going to be more antics like "meeh you said this".. Then sure, lets drop it.
     
  25. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    Ok, I'll apologize for whatever words I used that might have sounded aggressive to you, too.

    And I'd suggest to just let it drop, because as I see it, the discussion has been running in circles for a while, and it seems we both have said enough of our respective points.

    Hope we can talk again, in a more constructive / friendly mood later.
     
    Deleted User likes this.
  26. andymads

    andymads

    Joined:
    Jun 16, 2011
    Posts:
    1,614
    I haven't read the whole thread.

    I've been developing games professionally for a reasonable length of time (since 2000). For me personally, Unity has made the process pretty easy and enjoyable.
     
    GarBenjamin likes this.
  27. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Wow, so let me try and understand this you have 3 layers, representing different scales. So your 'camera' is 3 separate cameras in the same space and at the same point but viewing different layers.

    I would expect like my dropship example that you would stack the camera near and far clipping planes, but it sounds like you have 3 separate 'virtual scales' and a camera for each.

    So that mean you need 3 sets of models or scales to work to?

    How well does it cope when a planet crosses from one zone to another, in theory a planets surface could be over the line but it's origin is still not there yet?

    This is the kind of thing I would love to see in the learn section, Unity Learn 001# - Model an accurate representation of the solar system. Imagine if Unity had this tutorial that time there was the NASA competition!

    Well done @neginfinity

    I'm off to see if I can do this and make a solar system to fly around!

    PS I still think there would be an issue with landing on a planet, e.g. Kerbal ended up writing a dedicated planet/terrain renderer?
     
  28. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Me too but there are always points where I have tripped over some gnarly bit of the API or bumped into the 'not talked about' outer limits of Unity's capabilities. What aspect of Unity do you think could be made easier?
     
  29. andymads

    andymads

    Joined:
    Jun 16, 2011
    Posts:
    1,614
    Nothing comes to mind immediately. Saying that, I'm not using certain parts of Unity as recently I've only been making 2d puzzle games.
     
  30. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    Unity does a ton of work that used to be required to do manually in a custom engine. The time saved from what Unity offers is really huge. It does make development a lot easier. I'm not saying its perfect because it's somewhat game-genre agnostic and somewhat generic, which in some ways makes certain kinds of games a struggle, but on the whole it has done a lot to really take a lot of the "pain" out of development and remove a lot of programming that used to be required. It has opened it up to a lot more people.
     
    aer0ace and GarBenjamin like this.
  31. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Yep.

    They "technically" match near/far clipping planes, except that each layer is scaled down compared to previous one.
    First layer is 1:1 scale.
    Second layer is 1/8000 scale.
    Third is 1/64000000 scale. That's why there's a tiny earth floating in the scene view.
    Each camera has same fov, and same clipplane valeus (0.001 zNear 8000 zFar).
    Double precision object manager controls objects and asks them to create/destroy proxies as necessary.

    Int the example I used same model with different scale factor. Basically, object stores prefab size (how big 3d model is, in units), actual object size (how big object is supposed to be, in units) and then visual proxy is scaled up/down based on visible layer. Models files are single-precision obviously. All planets use standard unit sphere in the example, which are then scaled to match planetary radius.

    Transition between 2nd and 3rd layer is imperceptible (same would apply to transition between layers past that, if you add them), but you definitely want a dedicated terrain patch renderer for huge planets. As far as I can tell, in the example it would be possible to stand on the surface of the moon, but surface of the earth had issues due to significantly larger radius. Flying through asteroid belts and the like wouldn't cause any issue, aside from complexities involved when handling culling of visible objects. Speaking of object culling on planetary scales you'll probably need to deal with object's perceived brightness and "angular width" to deal how distant objects are rendered. Basically.. distant bright object will need to be rendered as flares, while distant objects that are smaler than a pixel will need to be culled.

    You'll need terrain patch renderer and you'll need to process actions on the planet differently.

    Basically... if you just throw object onto the planet surface, all the movement calculations will get very awkward, because just by standing still on earth you'll be moving somewhere at speed of 30 kilometers per second and will be also subject to gravitational pull from both moon and sun. Needless to say, this kind of complexity isn't needed. Not to mention that deailing with standing on a sphere may be interesting.

    As far as I can tell, to interact with planet surface, no matter what you do, you'll need to render immediately visible patch differently, meaning you'll need to store per-planet elevation data (could be just perlin noise/generator), and you'll want both your terrain path renderer and distant planet renderer to use that data to achieve uniform look. Basically... number of polygons required for planet visible from space distance, and from planet when you stand on its surface is very different.

    Overall, every aspect is doable, but even with full double precision engine, you would still need to jump through several hoops to render interplanetary travel with surface landing.
     
    neoshaman and ShilohGames like this.
  32. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    This is true. Definitely Unity has made game dev more accessible to other people.

    The main question is has it made game dev better for you? And if so how much better? IIRC you also developed in Blitz. Not that long ago you wanted to create a shootemup. I seem to recall you dislike term shmup.

    Could you develop your shootemup in Unity as easily and quickly as you could in Blitz? Or easier and faster?

    If not (or if even yes) what are the biggest obstacles to developing the game in Unity? Is it solely the creation of the art? This is the point of the thread. What could be improved that would help you to complete an awesome shootemup?
     
    Last edited: May 22, 2017
  33. ToshoDaimos

    ToshoDaimos

    Joined:
    Jan 30, 2013
    Posts:
    679
    It's ridiculous that some of you say that "coding an RPG is trivial". Modern open world 3d RPG is one of the hardest games to make. IMO, it's only topped by 3d MMORPG. High-end 3d RPG is VASTLY harder to make than something like CoD. Complexity of all systems is MUCH greater and on top of that you need a MOUNTAIN of assets. It's also much harder to design, debug and playtest than an FPS.
     
  34. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    ShadowK has worked and released games at least.
     
  35. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    I wouldn't describe creating the program architecture and doing all of the programming for an rpg as trivial. I think what ShadowK is saying is that not any one piece of the programming side is highly complex. Taking it one system / piece at a time designing and programming that system/section. Then moving on to the next.

    I do think there is a lot of work involved though and was getting at that earlier in the thread even for FPS. The difficulty aspect comes from the amount of work that needs to be done much more so than any one thing being super complicated. And my interpretation of ShadowK's comments is that he is looking at it like the time spent to create all of the graphics is much greater than the time spent doing all of the programming.

    I don't think it *has* to be that way but if using modern AAA rpgs as the target then I think it is understandable why he views it this way and is likely accurate.

    I don't think a modern rpg is a reasonable goal for a solo or tiny Indie team to begin with. One scaled down and focused on capturing the essence of a modern rpg sure. But not truly targeting a modern rpg (or modern anything for that matter).

    It's simple right... the only way it would be reasonable to tackle such a project is if all of the dozens (or 100+) people on the AAA dev teams are fairly incompetent, very slow workers. If that is the case then sure perhaps one highly skilled hard working person can compete with a team of 40+ barely skilled time wasting people.

    I highly doubt that is the reality though. I imagine the people on these AAA teams are the best of the best. The best programmers, the best artists, the best audio engineers, etc.
     
    Deleted User likes this.
  36. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    Let me just point out that the FIRST thing that @ShadowK said was that the most difficult part of making an RPG was all of the art (aka assets)...which has nothing to do with "coding."

    And, can you point out some of these complex systems in modern RPGs? What are some complex systems in Mass Effect Andromeda? The Witcher 3? Fallout 4? Horizon? As far as I'm aware, the only "modern RPG" with significant systems complexity is Breath of the Wild, though I'm not sure how in-depth it is.
     
    Deleted User likes this.
  37. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    It's not the people who aren't the best, it's the logistic, the politics and the iteration, at that scale it can go wrong quickly.
     
    Deleted User likes this.
  38. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    So modern rpgs I don't see that as a Unity problem. I mean sure Unity could be improved to make some things easier whether it is implementing the systems or achieving the desired graphics quality. But still this goal is basically dead from the beginning due to external factors such as lack sufficient people, lack of time, etc.

    But something that should be much more in the realm of reality is for a tiny (and perhaps even solo) Indie team to target something like this...


    If a person targeted a graphics style along these lines although improved via resolution, colors and shader FX now available... and this scope and depth. Not saying make THIS game. Saying this level of graphics (updated "naturally" via modern resolution, colors and any easy shader fx) and this scope of game in its entirety including depth of play. Then I think we are in the realm of reality and it would still be a lot of work.

    But with this example maybe we can look at it and think of what would be needed to make it easier and faster to create in Unity. Possibly level design tools for a start. Probably interaction means as well.
     
    Last edited: May 23, 2017
  39. Deleted User

    Deleted User

    Guest

    @GarBenjamin

    I think we just got mixed up in terminology, it's not trivial by itself (like everything in games it takes a lot of effort).. What I mean is it's trivial compared to the artwork.. Also if you've done it before or have access to a 153 hour tutorial that guide you through every system (there's a couple about) it does greatly help..

    I do honestly believe you seriously understimate indie's and what they can get through, I've shared experiences etc. ad nauseum in the other AAA threads..

    Then again if we talk fringe cases like Witcher 3 which I've heard to do everything (as a player) it will take you 500 hours, I mean someone explain to me how you could compete with that in a team of ten? Even if they were incompetent and lazy (which CD Projekt Red are the exact opposite) the math doesn't fit.

    For a start you'd need engine experts, there is nothing that comes out the box today capable of supporting that sort of game whilst being able to run it on a console. The amount of tools etc. it's of course an unfathomable task, the issue is AAA doesn't stand still so a AAA RPG that was released in 2009 or 2011 is a fraction of the size compared to the latest and greatest.

    Not to say any of that actually matters because one of my favourite games of all time is still Dragon Age Origins, but even a game like that would be a major task for an indie (well that's dependant on size of indie of course).

    Once you have your core components in for an RPG, it's just a matter of rinse and repeat ad infinity.. In terms of both artwork and code, this event there, this quest here etc.

    It's all about content..!
     
    Last edited by a moderator: May 22, 2017
    GarBenjamin likes this.
  40. ToshoDaimos

    ToshoDaimos

    Joined:
    Jan 30, 2013
    Posts:
    679
    Are you insane? The Witcher 3 has no complex systems? Mass Effect 4 has no complex systems? The Witcher 3 had budget of around 80 million dollars, using cheap Polish labor. I can assure you that not all of this goes into assets and marketing.

    I'm talking about relative complexity. For ex. making The Witcher 3 is VASTLY more complex than the latest CoD. Most indies consider CoD to be an untouchable AAA area and yet so many people try to make 3d RPGs. There is gradation of complexity: from humble Android Tetris clone to monstrous AAA 3d MMORPG. Any competitive 3d RPG is much closer to the high-end.

    Basically you say that making a high-end modern 3d game is not complex. XD
     
    Last edited: May 22, 2017
  41. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    @ShadowK It is entirely possible I am underestimating Indies. Some of the difference could be in what we are looking at as Indies.

    I generally focus on the solo Indie developers working maybe 60 hours per month or possibly a team of up to 3 people each working maybe 50 hours per month. I look at games and the development times of things like Axiom Verge, Stardew Valley and Environmental Station Alpha. AV was about 7 years as I recall and the others were less. SV was about 3 years I believe.

    So I think something like an Ocarina of Time is realistic. And also I don't see that as having low expectations of Indies. As far as I know none have made a game close to Ocarina yet.

    I've seen many posts showing early work on such games and these are nearly always dropped at some point several weeks to several months later. But there may be a tiny team out there actually working on such a game currently getting close to completion.
     
  42. ToshoDaimos

    ToshoDaimos

    Joined:
    Jan 30, 2013
    Posts:
    679
    There is a simple way to judge how hard and complex something is to make: judge commercial output. How many indie teams made something like The Witcher 3? NONE. How many indie teams made something like Mass Effect 4 or Fallout 4? NONE. A lot of people are trying, believe me. For every 3d indie game released on Steam there are at least 25 2d.
     
  43. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    Please use specifics, instead of generalities and strawmen like that last sentence.

    Feel free to mention some of these complex systems. I actually had several paragraphs talking about how these games didn't actually have programming (that's what we're talking about here, not "complexity" in general) complexity, but felt it was superfluous.

    Can you mention a single "programmatically" complex system in Mass Effect Andromeda? The inventory system? The leveling system? The AI? The movement of the Nomad? The quest system? Literally the only thing moderately complex is the tracking of your decisions, and that has nothing to do with coding. At all.

    I want to point out again that @ShadowK was talking about programming and coding complexity. No one's disputing that these games are probably more complex than CoD (though I don't play CoD, so I wouldn't know--I mostly play RPGs like we're talking about).
     
    Deleted User likes this.
  44. Deleted User

    Deleted User

    Guest

    Also just to mention, I couldn't care less about AAA. They do their own thing, I keep an eye out to see what other indie's are doing.. I doubt I will ever have the budget to compete with AAA so it's impressive to play, but it's irrelevant as a small indie developer.

    What happened to quality over quantity? Some large budget RPG's that came out over the past few years have been mind numbingly basic / boring, although because it's a large budget game filled with content it just dragged on and on and on.. Probably the first time I gave up playing a well known RPG.

    I'd take a 10 - 15 hour well done indie RPG over one of those any day, with what we have available to us it's entirely possible.. I've seen it time and time again, if you don't believe it's possible or can't do it that's most likely because you're not cut out to be a games developer at that level.. It happens.!

    I work well as a team and worked on projects like openworld MMO's (that have been released), but when it comes down to my own stuff I lack focus / direction and motivation.. I'd honestly say I'm not cut out to be an independant developer working on my own projects.. But I would like to prove myself wrong..

    I've accepted a challenge from @GarBenjamin to stop scrapping my projects and have at least a 45 minute playable demo by Xmas.. If I can't do it I'll give up on these types of games completely, probably finish off the other half baked top down or maybe join another promising project? We'll see.!

    Anyway, back on topic for dev's going for this type of project there is so much that can help.. I mean UE has mod support out the gate, shader frameworks, material editors (with a bunch of helpers), art tools etc. etc. and it's really well thought out..

    It's not to turn this into a UE vs. Unity thread, but if the OP is asking there's so many things that I could keep on listing that makes it a powerhouse for rapid development.. As much as some hate the game framework and how much pain it'll cause trying to avoid it, that same framework takes a lot of drugery out of projects like mine.
     
    Last edited by a moderator: May 22, 2017
    Billy4184 and GarBenjamin like this.
  45. mysticfall

    mysticfall

    Joined:
    Aug 9, 2016
    Posts:
    649
    Without trying to continue my previous discussion with @ShadowK, I'll just give my thoughts about coding complexity of any system in general, as a long time business system developer.

    Unlike video games, business softwares are written to last for a decade, which means there will be constant upgrades and other maintenance tasks. So, the primary concerns of software architects in that field are often how to build a system in such an way that can be most easily extendable, and maintained in future, rather than devising some features which haven't been seen before, because it is often a job of domain experts.

    So, you cannot really say any system is easy to build without looking inside its structure, simply because it only implements common features.

    Roughly speaking, business applications are all about reading and updating some values in some sort of a database, and such systems have been made gazillion times before for decades. But the exact architecture or design methods always have been in a constant flux, so it feels difficult to even catch up with the latest trend.

    Paradigms or architectures like OOP, FP, DDD, CQRS, event sourcing come and go, and new frameworks and libraries like DI, ORM, AOP, Rx are constantly created to deal with an old problem in a new way.

    And those changes are difficult to notice from the outside, because what you see is the same GUI stuffs, dealing with the same business you've been known for a long time.

    Maybe it's been different with video games, since you don't usually worry too much about maintaining your code base for a decade, unless it's an MMOG. But with the trend with modding support, and such a possibility that creating and reusing the same framework (not neccessariliy an in-house game engine) for number of different projects, I believe having a well designed and extendable framework or a platform can be invaluable, at least in certain cases.

    I'm not interested anymore in discussing what is the definition of 'typical' or 'modern' RPG, because it turned out to be quite unconstructive nitpitckings with words from the both sides.

    I'm rather trying to say that you cannot judge coding complexity simply by looking at the feature list, because in many cases, at least outside the gaming industry, technology has been evolving to meet the challenges of doing an old thing in a new way.

    And from what I've observed so far, such common practices like DI or Rx have been embraced by the game developers too, albeit slowly. And such technologies won't be noticeable from the outside because it won't directly introduce any new features, but will help them building more complex systems easier, thus potentially allowing them to invest more time for other unique features.

    Probably not every game developers need to build their games in such a way that can be easily extended from outside, or maintainable for a prolonged time. But some actually do, and especially when the scope becomes larger, the more important it becomes to have such a solid ground to build your game upon.
     
    Last edited: May 23, 2017
    GarBenjamin, Ryiah and Deleted User like this.
  46. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Does this mean you will or will not use Unity? Will to show that one man can make a difference or will not to show that one tool can make a difference? lol
     
  47. Deleted User

    Deleted User

    Guest

    @mysticfall

    The thing is you're building your game upon a well componetised modular architecture built by hundreds of specialists, even the modding support in UE is build directly into the cooking system. There's even an underlying architecture which allows you to focus on building your game atop of it and things like mem / alloc is taken care of for you..

    In Unity you are essentially manipulating a high level framework via OOP / component based approach, which already makes it far easier to get things done than any other engine or framework I've used to date and again C# does things like GC which is sooo nice.

    Point being these engines do as much as possible to simplify the process, it's really up to them to make sure they follow the best principles mainly.. Although I thoroughly understand in any large project it is astute to maintain modular workflows yourself.. If nothing else for your sanity, I won't deny the amount of times I've forgotten what I did last week and / or stuck dependencies in where they shouldn't and removed something.

    This isn't (thankfully) QT / GL where you build every portion of it from scratch, I of course agree you can't judge complexity based on a feature list.. But as @angrypenguin said for many games there are well known practices and principles that's been around for a long time giving information on how to solve most common issues.

    A lot of it is covered and even if you're a beginner you only have to reach out to look at tutorials, what shifts the paradigm is when you want to do something that isn't covered in most books / tutorials / API or engine examples.

    Also when you have to fix engine issues (UE gives you the source and I have had to delve into it a few times).. Trying to create a editor tools for Unity is far easier than UE where you really do have to understand the architecture, again another subject that isn't cookie cutter and adds a lot of development time and requires expertise.

    You will find that you'll get little to no support on advanced matters and trying to figure it out can add a large amount of time to your projects. You can make things very complicated very fast and I do wonder sometimes if that's the reason a lot of games "stick" to the mould? I know it's one of the reasons I'm not trying to push the boat out (tried it / failed miserably)..

    It's an interesting discussion and please don't take anything I've said other than curiosity and trying to understand :)..

    @GarBenjamin

    Y'know, yes toolsets are great and this ties into what I was talking about with MysticFall, a lot of this discussion is (rightly or wrongly) based on a lot of assumptions. Maybe that's a major issue when we talk about such things?

    Tell me if my logic is squiffy here, but if I don't have to spend months building tools etc. doesn't that mean I can spend more time focusing on my project? Making it bigger / better and shinier.

    Also I'm not sure if you have ever worked with CryEngine, but one of the biggest issues (or fears) (back before source was released) was hitting an issue (my word there was plenty) and not being able to do anything about it.. In UE you have freedom and can focus on quality no matter what happens, in an closed binary I'm at the mercy of Unity.!

    There's a lot of pro's for Unity too, but you already know them soo..!

    So what would you choose? It's simplicity vs. flexibility.. Y'know as a small team or lone developer I would struggle to recommend one above the other.
     
    Last edited by a moderator: May 23, 2017
    GarBenjamin and mysticfall like this.
  48. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Well I would say whichever you think would give you the best chance of completing a playable demo in about 6 months. Unity might be faster due to C# and if you enjoy the component-based system perhaps that would be another productivity boost. Maybe UE offers the same. I don't know. BUT the part you mentioned about spending months building tools... that doesn't sound very good unless at the end of those months the tools increase your productivity by 2 to 3 times. Which one needs the tools built... Unity? Doesn't the asset store have the tools you'd need (maybe in source form so you could customize as needed)?
     
  49. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,492
    Speaking of indie vs AAA rpg complexity, how would you guy rate Mount and Blade, obviously they don't have the content of AAA (lot of copy paste, low quality asset) but they seem to have the complexity beyond (dynamic world+ army management + typical rpg requirement).
     
  50. Deleted User

    Deleted User

    Guest

    I just had a look, probably behaviour designer / A*, amplify shader editor, Final IK, Playway and Alloy would cover most of it..

    For some reason I'm a little bit nervous about Unity, Mecanim had issues with re-targeting animations (but not with generic rigs) which is a must for RPG's as you'd generally only use a couple of skelebobs for humanoid NPC's then just add morph targets / randomisers for character creators and general crowds etc.

    I've not tried an adventurous (or really any) major project since 4.5, cloth was broken last time I properly checked (not sure now).. I'd of course avoid the terrain system (for many reasons), I had issues with phsyx.. For e.g. I'd created a character interaction / dialogue system. So I'd stored NPC position data in an array for about 50m using a sqr mgnt to calculate relative distance (yes there are cleaner ways, but just a test)..

    So I'd used a trigger point for NPC's which was activated via a bool / key press when within a certain distance and you'd expect it to work right (it does in UE)? It's simple.. Just to note you're going to have to forgive me because its been years, for some reason it didn't consistantly work.. I spent days changing everything I could, asked for help / researched the crap out of it and rebooting the editor seemed to fix it..

    I did try it in 5.2 (same code)? I believe and it worked fine (must of been sorted with the upgrade)..

    The point on that is I kept running into daft little issues all the time and constantly had to find workarounds.. Again in UE it tends to just work (or crash the editor).. But it was at least consistant.

    I'd have to split my "scenes" up far more as last time I tried loading a large scene in a build it took 5 minutes to load, that's on a PC and I'm sure users wouldn't be happy about it. Although it might make things more manageable anyway..

    Umbra had issues with things like reflections on water, lets say you tilt the camera and it occludes terrain for e.g.. In fact I'd like to avoid a static based occlusion system all together. So could you implement something like HZB? Do you have access to do so?. On occulsion I kept getting a load of repeats of frustrum culling for no real reason at all..

    I'm always confused as to what I can and can't get away with..

    I had issues with vsync causing stuttering and overhead.. There were so many crappy / sloppy little issues all over the place that Unity drove me nuts.

    Just to mention I've seen a lot of released Unity games have these crappy little issues , take pillars of eternity for example.. They must of used the Unity inbuilt pathfinding system as some of the NPC's started bugging out and doing an irish jig.. I had to overwrite that portion to make sure they slow down gradually and come to a complete halt (stopping distance if I remember correctly), whatever Unity does by default is urm wrong (not to mention the overhead is massive if you want something somewhat accurate)..

    I'd probably want to avoid what Unity gives you by default and treat it more like XNA.. But its been that long (since UE's beta release) I'm back to noob status.
     
    Last edited by a moderator: May 23, 2017
    GarBenjamin likes this.
Thread Status:
Not open for further replies.