Unity questions

Z

Zoopy

Banned
Joined
Jul 20, 2016
Messages
1,457
Reaction score
35
Disclaimer: This is coming from an absolute programming noob, so please excuse if I sound clueless. It's because I actually am and want to do this project to teach myself more about programming. :p

I've got no experience with Unity, but it seems best suited to a hobby game dev project I'd like to try out. I want to make a city builder in the vein of Dwarf Fortress (obviously not as complex) with the roleplaying gameplay of King of Dragon Pass. I recall the Rimworld devs once saying that Unity does not play well with the management of 100s of objects, so does anyone have an idea whether this is accurate? Also, is Unity really suited to a project such as this? I'd hate to start on it only to realise a few months down the line that it's actually not suitable at all and then struggle with the headaches of porting it.
 
In my limited experience, Unity can certainly deal with 100s of objects, but as always, it depends how complex the objects are. Objects that consist of a lot of triangles will make any framework and ones graphics card struggle.

I know Pillars of Eternity (https://en.wikipedia.org/wiki/Pillars_of_Eternity) is done using Unity, since I am busy playing that; and I think it is in the same line as the games you are mentioning.
 
Oh, nothing that complex. I'm going to use simple, non-animated 2D sprites for everything. Sort of like an ASCII rogue-like game, but with a tileset instead of ASCII characters.

The concern comes in if I implement things like tools, weapons and armor for individual characters. It won't ever be on the level of Dwarf Fortress where every character's clothes is broken down into individual items of clothing like shoes and pants and headwear, but it might still get quite intense in prolonged gameplay sessions.
 
You may want to consider Game Maker. It and a whole suite of plugins were available on the Humble Bundle recently. Unity may be overkill.
 
I have unity and I am also a noob at programing. It's a big learning curve when u start. I would suggest get it and take a few days to work through the tutorials. Unity have 3 or 4 tutorials of small games and after completing this u should know if its for u.
 
Yes, I agree, certainly do all the tutorials, and only then decide if you want to use it for your game. If you jump into your game before doing the tutorials, it is going to take much more effort in the long run. And as cguy says, also have a look at Game Maker and decide what is best for your game.
 
Hmm, what language is GameMaker in and does it handle large-scale projects well? Further along the line my game is going to have to simulate off-screen factions and events (this is where the KoDP influence comes in). And also possibly a global economy because I intend to make the game more economy focused with NPCs coming into your village to trade constantly and world events influencing the prices and demand of certain things.

I don't mind the learning curve that much. I expect it to be a year before I have even the most basic systems in place anyway. What's nice about Unity is I learn C# as I go along, so I can carry that knowledge over into the working world as well. I've never really looked at GameMaker (or RPGMaker), but I know they've got a pretty bad rep among players in the gaming community.
 
Zoopy said:
Hmm, what language is GameMaker in and does it handle large-scale projects well? Further along the line my game is going to have to simulate off-screen factions and events (this is where the KoDP influence comes in). And also possibly a global economy because I intend to make the game more economy focused with NPCs coming into your village to trade constantly and world events influencing the prices and demand of certain things.

I don't mind the learning curve that much. I expect it to be a year before I have even the most basic systems in place anyway. What's nice about Unity is I learn C# as I go along, so I can carry that knowledge over into the working world as well. I've never really looked at GameMaker (or RPGMaker), but I know they've got a pretty bad rep among players in the gaming community.
Click to expand...

It has its own scripting language (looks, vaguely C-ish). It has been used for several successful titles - I suggest looking at what was done with it online, and seeing if anything fits. The idea of using a "game maker" is somewhat offensive to a lot of hard core developers, but more often then not, these guys never finish what they start, because they're too bust reinventing the wheel and don't really grok the level of work required to acutally polish and ship a title.

My take is that unless you are by some objective measure a legendary coder of some sort, then using the tool-set that does the most for you is probably best - that may be Game Maker (or some other specific type of game "game maker"), or that may be Unity or even UDK - as long as you have to do as little work as possible. Also, it always makes sense to prototype what you want to do, so before you even consider, what tool-set the final product should use, first figure out what is best to prototype your game.

I found a show reel:
[video=youtube;WuU1tEF1xYs]https://www.youtube.com/watch?v=WuU1tEF1xYs[/video]
 
I've been using a lot of these since I'm working on my own game projects, so here's my take.

Unity
It uses what it calls GameObjects to represent all items you see on screen. So for example any model on screen will have a GameObject, and attached to that you have components, say a mesh renderer, a physics component etc. These GameObjects unfortunately aren't very light on resources and take time to instantiate, so once you move past a certain number you run into trouble. Drawing for example 100 is ok, especially if they don't move, but 1000 is a problem...it also depends on your output device, e.g. a phone vs a PC.

Second option is to create your own meshes and attach them to GameObjects, so if you're spawning cubes for example you can attach a large number to one GameObject (in a single mesh). These are a lot faster to create, but then you have to worry about updating them. Usually a Unity GameObject uses proper camera math to rotate objects and render them...but if you combine items into a mesh and adjust them individually you need to manually alter the vertices...and unfortunately you can only stream so many new vertices to the GPU per frame.

Then there's a 3rd option where you use OpenGL commands directly in Unity using e.g. Graphics.DrawMesh. Using these you don't have to worry about updating vertices since you pass in a rotation etc. Performance is also a lot better, you can probably do 5000-10000 simple object easily (as in simple blocks etc up to a low few hundred vertices).

In Unity 5.5 they're hopefully adding Graphics.DrawMeshInstanced. With that you can specify up to 1023 (as per last doc I saw) instances per mesh that will be drawn on the GPU...so you're going to be doing 100k-10m small objects (as long as you can have multiple instances of the same mesh).

Overall: Unity is really good as a 3d tool/starting engine. It has a great asset store and a ton of people using it, so it's easy to pick up and learn. However, if your project is just a tiny bit weird or different it tends to fight you; and not just let you do what you want.
Unreal is also an option, however its harder to pick up and doesn't have the same size asset store going for it. With it you can write code in C (although overall it feels a lot schleppier to me than Unity's straightforward C# class layout). But its far more powerful than Unity and you have access under the hood (although that isn't really a bonus for a solitary developer just trying to make a small game). It also has its blueprint system, which is a visual tool for constructing code (same as Stencyl below for 2d).


So you really need to decide if you want/need 3d, or if 2d is ok. If you're going 3d then go for Unity, else if you're ok with 2d, then look at any of these.
GameMaker :
+ One of the biggest 2d engines out there
+- Very good on tile games, less so for custom non-tile games
- Uses its own custom language
- Might be a bit restrictive on output targets last time I checked (that you need to spend money on to buy - everything else here is pretty much free)

CocosSharp : (Or alternatively any Cocos2d-x binding you want)
I'm currently using this for a 2d project. It's basically a more modern version of MonoGame which itself replaced XNA
+ Has a lot of utility classes that handles all the basics such as image loading, sprites, clipping, animation (+a binding for Spine), etc.
- Doesn't come with a frontend, so it's all code based

Defold :
+ Publishes to 6 targets
+ Large user base
+ The engine used by King etc for their games (its their engine)
- Projects are managed online
- Uses Lua for language...not my thing but if you're into that its a bonus

Godot :
+ Decent userbase
- Custom language (until next version when they'll increase C/C# etc support)
- Editor was buggy for me

Stencyl :
+ Large userbase
+ Can write code on frontend using visual blocks, really great for young kids
- Uses Haxe for language

There are many others (of varying sizes) such as Duality, Wave Engine, Oxygine, Panda, Isogenic etc. In general I don't recommend them due to their smaller user bases, making finding help with issues more difficult.

So like I say I'm using CocosSharp since I was looking for a 2d C# engine...if I had to choose one with a frontend I'd look at Defold and then GameMaker (Defold first because I can re-use the Lua code and get a lot more help overall on coding issues). If you want 2d, C# and a frontend then look at Duality/Wave Engine.
 
Last edited:
Thanks for all the advice! I've decided to throw together a proof of concept in both Unity and GameMaker and see which one does it best. I've got both downloaded but I started mucking around in Unity and it is surprisingly less difficult than I thought it would be. Not to say the learning curve isn't steep, but I threw myself at it and after struggling and struggling with basic things I frequently get these "aha!" moments where concepts just click. So far this is what I want to accomplish for the earliest of early alpha versions (proof of concept, if you will):

-Very basic world generation
-Spawning villagers with movement
-Building placement (just placement, not blueprints for villagers to build- yet)

I've accomplished the first two in Unity. On starting the game a 100x100 map is generated out of 32x32 tile prefabs. The borders have collision blocks on them to prevent gameobjects moving out of the game world. This is obviously not ideal at the moment because that equals 10000 gameobjects (albeit very simple ones), but I've found some tutorials for creating and destroying gameobjects as they move in and out of the camera view which I'll use if I later decide to go with Unity.

Next up I created a villager prefab and wrote some code to instantiate several villagers at game start. It randomly selected a sprite from an array and then assigns it to each villager it instantiates (a bit unnecessary in a proof of concept but it was easy enough to implement). I broke my head a little against the next one, but I wrote code to make the villagers move around on their own. Very simple, they just pick a random direction then move for a second, and then wait for 5 seconds before starting again. Later I can learn to only do this when they're idle and dynamically create a boundary in which they can move around. Also, I'll have to learn pathfinding which I've heard is a massive bitch in Unity.

Today I want to see if I can implement very simple building placement with collision boxes so villagers can't move through them. I have a feeling it's going to be a bit tough getting it centered precisely on top of each tile without overlapping, but we'll see as I go along. Before I get there I need to implement a mouse cursor.

And that will be it for Unity, at the moment at least. Once I've got that down I'll try and mock up the same thing in GameMaker and see how it differs between the two.
 
Good start.

You don't want to create/destroy GameObjects when moving in/out of the camera, that's a very expensive operation.
Unity does frustum culling so shouldn't render entities that are off camera, but you can verify by checking the rendered objects on the top right gizmo when they move out of view. It works but can be wonky sometimes, and it also depends on your physics etc setup.

The nicest thing about Unity is that there are a lot of people developing for it (and they're often on the beginner level), so you'll always find answers to your questions.
 
Pho3nix said:
Why no MonoGame?
Click to expand...

Sorry, I didn't see your message until today.

There's no real reason not to use MonoGame. I'm using CocosSharp at the moment (which I mentioned), which is pretty much the same thing. At first I had though it was a rewrite/upgrade of MonoGame, but it turns out its a bit of a port of a fork etc, made by Xamarin.

I imagine they work very similarly, since CocosSharp basically wraps up MonoGame, box2d, lidgren.network, SharpDX and then the main Cocos parts.
 
animal531 said:
Sorry, I didn't see your message until today.

There's no real reason not to use MonoGame. I'm using CocosSharp at the moment (which I mentioned), which is pretty much the same thing. At first I had though it was a rewrite/upgrade of MonoGame, but it turns out its a bit of a port of a fork etc, made by Xamarin.

I imagine they work very similarly, since CocosSharp basically wraps up MonoGame, box2d, lidgren.network, SharpDX and then the main Cocos parts.
Click to expand...

Thanks. Been looking to jump into this and Mono was going to be my platform(pun intended :p )

Will look into CocasSharp thanks :)
 
You guys weren't joking about the learning curve on Unity. It's a bit like running up a brick wall, but I'm getting there piece by piece. The biggest shock for me (and it probably shouldn't have been surprising at all) is how many Unity devs avoid things like polymorphism and inheritance/derived classes, all of which university courses tend to put a heavy focus on. It's been an information overload but all in all I think I've learned more about programming in the last week from Unity tutorial videos than I did in 3 years of university.

I'll stick with Unity for now because I find Quill18's video series on city builders to be really informative. He's focusing on a space-station city builder which is very different from what I want to do, but I've been learning tons from him. Specifically the way he separates his data from the visual layer has been really great to see, because it differs a lot from what I originally did and showed me how flawed my approach was in the long term.
 
Zoopy said:
You guys weren't joking about the learning curve on Unity. It's a bit like running up a brick wall, but I'm getting there piece by piece. The biggest shock for me (and it probably shouldn't have been surprising at all) is how many Unity devs avoid things like polymorphism and inheritance/derived classes, all of which university courses tend to put a heavy focus on. It's been an information overload but all in all I think I've learned more about programming in the last week from Unity tutorial videos than I did in 3 years of university.

I'll stick with Unity for now because I find Quill18's video series on city builders to be really informative. He's focusing on a space-station city builder which is very different from what I want to do, but I've been learning tons from him. Specifically the way he separates his data from the visual layer has been really great to see, because it differs a lot from what I originally did and showed me how flawed my approach was in the long term.
Click to expand...

I think the main reason for that is because Unity treats code as scripts (which you attach to objects) etc., so developers get used to writing these little snippets (that are heavily tied into each other via GameObject/Component lookups).

The guys that build libraries (such as for PathFinding) usually have much better layouts.
But even then, you often still need shortcuts to make Unity work properly/easily, so you sometimes tend to do some funky moves.

The other nice thing about Unity is the amount of developers, its really easy to find someone with a fix for almost any problem you're going to come up against.
 
Just made the switch to Unity now. Using it in an asp.net API project. So flippn easy to work with!

Create the container
C#: 
public class UnityResolver : IDependencyResolver
{
    protected IUnityContainer container;

    public UnityResolver(IUnityContainer container)
    {
        this.container = container ?? throw new ArgumentNullException("container");
    }

    public object GetService(Type serviceType)
    {
        try
        {
            return container.Resolve(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return null;
        }
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        try
        {
            return container.ResolveAll(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return new List<object>();
        }
    }

    public IDependencyScope BeginScope()
    {
        var child = container.CreateChildContainer();
        return new UnityResolver(child);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        container.Dispose();
    }
}

Register the container and good to go!
C#: 
      var container = new UnityContainer();
      container.RegisterType<IAuthorsRepository, AuthorsRepository>(new HierarchicalLifetimeManager());
      config.DependencyResolver = new UnityResolver(container);


C#: 
      private IAuthorsRepository _repository;

      public AuthorsController(IAuthorsRepository repository)
      {
            _repository = repository;
      }
 
Last edited:
Oops!!!

Couldn't figure out what all all the Cocosharp and Godot was all about, thinking maybe this was prehistoric Inversion Control lingo :X3:
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X