Other > Game Development

Shrugger! Unity!

<< < (3/71) > >>

x4000:
Unity supports C# via mono, but you can't use something like wpf or windows forms -- those are not opengl/directx based (both run in software mode, not hardware-accelerated).

Shrugging Khan:
Awwwright! So I now have working but horrifyingly inefficient procedural world generation (It generates a flat plain and a featureless tower, with semi-random colours. Go me!), and a day-night cycle with weird colours.
So far, so nothing at all yet. Questions!

1) I originally tried to make large structures out of uniform small cubes, but that quickly left me with over 10000 cubes to generate, and caused Unity to crash.
Now, I'm considering two options: Using larger gameObjects (pillars, walls, whole buildings) for all larger structures, with small blocks only where necessary, or using procedurally generated polygons instead of cubes (I don't even know if that's possible, or if I have the geometry skills for it).

Is there another way, perhaps, to simply increase the resource efficiency of the original, quasi-minecraft-style block system? Like only generating the world one area at a time rather than all at once, only rendering those cube faces facing the player (and within his FOV), or some obscure coding trick I'm not aware of?

2) I'm trying to instantiate a bunch of critters with AI scripts attached to them. This seems to be simple enough using addComponent to add the script, but I wonder if I should do it differently. Is this method good enough, or am I being an Idiot and there's much better ways to do it?

3) For things like creature attributes, NPC equipment and whatnot - what's the best way of storing that data? Right now I'm just using int[, , , , , ,] arrays, but I can't imagine that that's the best way to do it.
The same question applies to the previously mentioned world generation array, in which I store block coordinates and types. Is that even a good method?

4) What's the best way to write down things like enemy types, items, skills etc.? Just right there in the scripts, or maybe with something like XML files? I have no buggering idea how that even works, but it'd be nice to know what angle to aim for.

x4000:
1. Yes, you just need to have a disconnect between how your world is generated versus how it is displayed.  IE, generate your cubes however you want, in terms of knowing what they are and where they are, but this is your own custom code and has nothing to do with Unity GameObjects or whatever.  Then whatever cubes are in the view, use reusable Unity GameObjects for those.  Depending on your draw distance, hopefully you're not seeing thousands of those.

2. No idea, never have used AI scripts or addComponent, sorry.

3. Object oriented programming with custom properties, for sure.  Or are you using Javascript?  I can't recall.  JS really is inferior for structured data...

4. Up to you, really.  Mostly we put it in the code because it's quick to do and quick to access, and we don't really want those things being externally changed.  But some things we do read in from external files, like particle effects or whatever.  It depends on the specific use case, honestly.

Draco18s:

--- Quote from: Shrugging Khan on August 02, 2013, 04:19:28 pm ---1) I originally tried to make large structures out of uniform small cubes, but that quickly left me with over 10000 cubes to generate, and caused Unity to crash.
Now, I'm considering two options: Using larger gameObjects (pillars, walls, whole buildings) for all larger structures, with small blocks only where necessary, or using procedurally generated polygons instead of cubes (I don't even know if that's possible, or if I have the geometry skills for it).

--- End quote ---

Separate your visuals from your procedurals.

Minecraft essentially has a 3 dimensional array of integers that it uses to hold the world information.  Each integer refers to a complex block class, which is instantiated once.

The visuals are a lot of rendered face, but only the visible ones.

Shrugging Khan:
I'll have to get back to you about the visual/procedural issue (I get your points, but the actual way to do it eludes me still).

Regarding Object Oriented Programming for NPC attributes and the like, can anyone give me some basic pointers? My OOP-Fu is rather weak, I'll admit. It's my general failing, to rely too long on simple tools where more refined ones would be more appropriate...hence my using simple arrays instead of something sensible.

What do I need? Basic C# scripts, or a different format? Classes? Methods? Properties? All of that stuff is quite a mess in my head, so if someone could give me a brief overview of what is needed, I#d be much obliged.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version