How "correct" is your programing in your games?

News & General Discussion
1

This is just a simple question, if people from SeriousGames or any other “major” Unity developer (i.e. works on “big” Unity projects) could answer, it would be great.

If one was to develop things in a nice “organized” and “design patterned” way, we should separate the visual object from the data object.

For example, if I have an inventory, I would have the InventoryGui - the Unity GO - and a Inventory - which had the actual data of the inventory. It is more “correct” to separate the logic from the representation.

However, I’m getting filled with classes! Specially when doing Gui stuff, where I have a deep hierarchy of objects to create the Guis (One for the background, another for the title, another for each of the objects, etc, etc).

So basically, how do you organize your programing? If you mix things up (i.e. the Inventory has the data and visual representation), does this create a heavy game?

For example, if every character has a inventory, but only two are shown at a time, how do the other 300 inventory GO drag down in terms of performance (assuming they aren’t enabled…)?

Regards,
Afonso

2

I find the the “correct” way to program anything is to code as little as possible (within reason), and keep related things in one or a couple of files. So if you’re spewing out dozens (hundreds?) of classes doing almost the same thing, that can’t be right :slight_smile:

Use the fact that you can compose functionality by putting multiple behavior instances on a game object, and that you can have public variables that are setttable in the inspector.

As for having hundreds of GameObjects, that seems a bit extreme. But generally GameObjects are extremely cheap if they’re not rendering and not having enabled scripts with Update() or FixedUpdate() functions on them.

d.

3

Good question.

One of the things I’m wondering w.r.t. Unity is the degree to which, with a large project, I may be forced to mix “code” with “data” – even if some of that code is generated by content tools.

Experience has shown me that mixing code with data is almost always bad.

Consider that I might want to build a tool for managing the objects a character can get in my game. Each of these objects is going to have a model, a texture, a 2D representation, and a bunch of properties.

One way of doing this would be to drag each model into the game, build the material for it, link it to the model, add the 2D representation to the game as another texture, and then write a piece of code that lives … somewhere … which implements the properties of the item (e.g. its name). If I want to put a “box of ammo” on the ground somewhere in an alien complex, I drag the object prefab with its attached code onto the ground … etc.

This seems (and I base this on experience) like a disaster waiting to happen.

What I’d like to do is have a directory containing a bunch of models, images, and one or more text files. The text simply tabulates object properties and links model to material to properties to 2d icon. When my game loads, it loads the text file, creates an internal table, and builds stuff on the fly as needed.

The worrying thing for me is that the latter (better) approach seems to me to be very hard (comparatively) to do in Unity, while the former (worse) approach is deceptively easy (in the short run). Macromedia Director had (has) the exact same problem (loading text from a file required a partially unsupported XObject whose API changed from version to version and which wasn’t documented for most versions of Director).

I can just see folks replying – oh, you can do this with .NET.

Edit: one thing I’ve considered is writing a utility that generates JavaScript from the directory of objects and either a text data file or uses the JavaScript itself as the data file (essentially a similar approach to JSON – the data is code).

4

I tend to think of the various components such as the mesh, the texture, the scripts, etc. as individual “objects”. To me, a prefab that you drag onto a scene is merely a convenience object that uses aggregation. I can also load one at runtime. Mixing data with code is up to me. I can keep my data as different objects (i.e. scripts). The texture “object” has its own data which I can query the texture for and ask the texture to manipulate. I can swap any piece at runtime via other scripts.

You can do this also. I have built stuff on the fly, but I generally prefer to use prefabs as part of the process since they tend to represent functional entities. I find laying out things is sometimes much easier at runtime via code.

I think Unity makes using both relatively easy. I find a blend works best for me.

What is interesting to me is that I can tell I think about the issue in fundamentally different terms, but I cannot figure out how to effectively express it.

5

Concept solution:
Since its a royal pain at the moment (I haven’t found a clean solution) to load in objects dynamically, there is another solution. Warehouse.

Ok, what I mean by Warehouse is that your world is infinate in size, literally. Your game zones can be made so large, then your game objects can be ‘moved’ around. So, lets say you have an ammo box with random ammo. You place the box in the game at some arbitrary location, location 1000,1000,1000 for instance.

Now, you have code that when the box gets ‘activate’ it randomizes its loot. When its ‘picked up’ you then ‘move’ the box back to its warehouse location and deactivates it. Out of sight, out of mind.

You need a zone heartbeat code, attaching such code to terrain is cool. On a timer, it triggers the respawn of the box, the box returns to ‘spawn’ position from ‘home’ position, randomizes its loot, etc.

Your warehouse is literally that, a warehouse of game objects ready to be activated. They have 2 sets of 3d locations stored in them, the xyz of home position in the warehouse, and an xyz position of spawn, which can be dynamic based on last death spot of creature.

On pickup, return to home, on creature death spawn at death location. Or you can ‘copy’ the object with all of its properties, and leave the ‘original’ at home position, then when picked up, destroy the copy.

Make any sense?

6

Why not just use prefabs for all of that? Would be a lot easier, and you wouldn’t have to worry about Unity bogging down with all the junk in your scene. (even with some complex culling design, they would still be managed realtime by the engine)

Write a “Warehouse Controller” script if you like where you connect all of your prefabs. Just don’t put them all in the scene…That’s entering scene management nightmare territory. :wink:

EDIT: Also, when you need to make a change you just drag a fresh prefab to the proper slot in the inspector. With your idea you have to find the damn thing in your scene or the hierarchy, delete it, then place a fresh one and then set its position properly. :shock:

-Jeremy

7

I whole heartdly agree. This is exactly what prefabs and the ability to drop prefabs and other game objects on references exposed to the inspector solve.
And they solve it in an extremely clean, practical and very easy to use way.
This technique also scales extremely well.

A simple example: spawn a rocket from a missile launcher.

var rocket : Rigidbody;
function Fire ()
{
   var clone = Instantiate (rocket, transform.position, transform.rotation);
   clone.AddRelativeForce(Vector3.forward);
}

Look at the code there is nothing in the spawning code that requires it to be something specific, there are no hard coded paths.
So i can hook it up to a big rocket, a small rocket. The rocket can have a particle system attached or not, sound or not. Or instead i can just hook it up to a space cow. The point is that you are not hardcoding any data, you simply expose a variable and from the inspector you can assign the data you want it to work with. Even better by exposing it as a rigidbody you expose a constraint, since thats what the script requires.
In the inspector you will then only be able to assign rigidbodies.

Thus the code is generic and reusable. And in the inspector you can hook it up to the right prefab in no time.

The component system also makes reuse of code almost happen naturally.

So please just start using Unity and stop thinking about text files.

And if you insist on walking down the wrong direction, reading files using .NET is fairly simple, and with Resources.Load you can easily hook things up dynamically.

But seriously, try the right way in Unity in a big project first.

8

Yes Prefabs are fantastic. In our game I’m using heaps. So basically lot of my code is reusable… typed once and reused on the various GOs. All because of prefabs.

Also using the “Resources” folder approach is good for randomly generated data for the game. Just be careful what you put in there… :wink: As I found out the hard way… when I players were coming out as 100mb+ monsters!

Cheers.

9

It should be noted that most of the code in the Big Bang Brain Games is the same across 6 different games. And they are fairly dissimilar. Definitely use Unity to your advantage. Try to use its strengths, and it really pays off. :slight_smile:

Cheers,
-Jon

10

Generally in Unity, when something seems complex, there is a painfully easy way to do it that is in hiding. Once you have used Unity for a while, it gets easier to uncover them. :wink:

-Jeremy

11

It’s very difficult to tell whether something is actually complex or something Unity handles with brilliant efficiency in some not immediately obvious way. The lack of non-trivial examples doesn’t help.

For example there’s no real examples of abstract, persistent data handling. (I go into a scene, pick up an object, go to another scene, I still have that object. I pick up another object. Return to the first scene, the object I picked up is not in the scene.)

Now add the possibility that the object I picked up was randomly selected from an arbitrary pool of possible objects, including objects added to the pool after the scene was created.

OK now I quit the game, start it again, and it remembers where I am and which objects I picked up.

I’m sure Unity can handle all of this, just not sure how easily, and I have a checklist of things I am trying to figure out how to do (I actually have a design document). I’d like to avoid .NET if I can ;-).

I don’t think I’ll be able to avoid text i/o to implement conversations and quests.

I assume this can be done, effectively, in code when instancing something, and hope that I can do something like query Unity to get a list of available prefabs fitting some criteria. (E.g. I want to give a random bad guy a random gun with random ammo – not knowing in advance what the ultimate lists of bad guys, guns, and ammo will look like.)

(When we built Prince of Destruction we ended up making every darn thing scriptable. A door was a scripted terrain tile. This is a very flexible solution, but I’d love to avoid it.)

Edit: actually, making stuff scriptable is soooo useful. E.g. World of Warcraft’s entire UI is scriptable via LUA. How might similar things be achieved in Unity?

Another Edit: I’m thinking I might need to give concrete examples. Let’s suppose I’m writing an epic fantasy game (I’m not, but close enough). In it there will be 50 “arc” quests and 50 “mini” quests. Mini quests will be random (“A wants you to kill B for reward C”). There will be 25 kinds of critter, and 20 or so significant NPCs. Any NPC (significant or otherwise) belongs to one of 5 factions. So if NPC A gives you the “A wants you to kill B” quest, B will be from an opposing faction.

Items will be rated in terms of “level” and “value”. So if you – at level n – are asked to kill an NPC of level n+3 the reward will be an item of your level but high value, or of higher level but moderate value.

All of this screams out to be database driven, whether the database is SQL or just nicely formatted text or XML or whatever. If there’s a “right way” to do all this entirely in Unity, I haven’t the first clue what it is. Building each of these game objects as a prefab doesn’t seem viable. Building a single prefab of each canonical type (e.g. an “NPC” object) which assembles itself from available assets and properties on demand seems more viable, but I don’t yet know enough to (a) know if this can work, or (b) know if there’s a huge gotcha (e.g. it needs to contain every possible relevant geometry).

12

It looks like resources.load will do a lot of the things I need – especially in concert with rigorous naming conventions.

Again – I’d love to have someone explain the “right way” to do what I’m talking about.

13

I find placing items in editor such a drag, I would rather write it in code (or a text file), that way I can reload the level/certain parts of the level. Though all my things are prefabbed, which makes calling and placing them easy

14

@david When do you have time to code anymore? (GRIN)

David

15

hi, i spent some years making games with ogre and when i switched to unity it was shocking at first! people were crazy, binding scripts to objects parts like writing a wheel script and then drag-drop it to the wheel gameobject. it was frustrating and i gave up unity twice before i found a way to use it differently. i put a dummy gameobject that lives across all scenes which runs your code. there is only one class that derives from monobehavior and this acts like the main function. All scripted prefabs are loaded at runtime using a factory class and there is only dummy versions of the prefabs in the scene. I destroy the dummies and put the actual prefabs at runtime. This is how i generally work. It is easier to seperate code and data this way i think…

and i remember a young friend telling how wonderfull unity was. i remember him putting all the gameobjects in the scene(hundreds) behind the camera and place them in front when necessary :slight_smile:

16

@tasadar

You sir, are doing it wrong.

I’ve used all sorts of engines, I even created HeroEngine (see: SWTOR), so I know a thing or two about engines and paradigms. Unity is a component based system, and trying to make it NOT a component based system is just asking for the path of most resistance.

Once you learn and embrase component-based programming, your productivity soars.

David

17

QFT. That’s how I work. I think many people get all caught up with trying to make the perfect code structure with maximum re-use and it just doesn’t work for games. Instead, build up a library of often used functions that are black box and fire and forget. Keep them all in a Utilities file or such :slight_smile:

And I’ve used just about everything on the planet. But it is neither here nor there. It all depends on the scope and if you’re the sole programmer or not. Spending a long time making it all component based is asking for trouble when you’re doing a simple platformer for mobile. Tools for the job and all that :slight_smile:

18

Sometimes you just don’t have the choice to have at least a persistent core framework. Unless you don’t care about some memory optimizations (caching across multiple levels, for example).

19

the heavy part is not the coding, its designing a clean and reusable base. Well at least in my opinion

you might have a look into this book.

20

The correct way to program in games is to keep your code as tiny as possible (and simple as possible). A good balance between tiny/simple! Over complicating your program will simply make you a bad overcomplicated programmer. If you want to improve your skills, just get over-complicated code and simplify it! Or implement different algorithms/techniques inside Unity. Learn, how to solve complex problems (by abstracting possible solutions) and then write it down, simple and tiny. :smile:
Also, a good clean coding organization (naming conversion, etc) is welcome!