How "correct" is your programing in your games?

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

 

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).

 

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.

 

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?

 

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. ;-)

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.

-Jeremy

 

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.

 

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.

Cheers,
-Jon

 

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. ;-)

-Jeremy

 

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).

 

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.

 

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

 

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

David

 

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

 

@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

 

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

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

 

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).

 

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.
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

 

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.
Also, a good clean coding organization (naming conversion, etc) is welcome!

 

i dont see how it breaks unitys component based system. the different thing im doing is trying to seperate codes from assets. in code i generally use both inheritance and composition where necessary, unitys component system is there and functional.

for ex. a soldier gameobject(prefab actually) is only an asset that is instantiated as a member gameobject of my soldier class. what people generally do is to drag-drop a behaviour class to a gameobject and setup public variables to be configurable from editor. i personally do not like that approach and try keep everyting private/protected and use xmls or script itself for configuration.

 

This thread is 5 years old....

--Eric

 

This post is from 2007. That's why.

 

I feel identified by this! I always tend to over-complicate my scripts!

I guess I felt that if my scripts are like ten pages long, then I'd be more pro! But stuff starts to get really complicated, and it'd be a lot better to be organized, a script should not do ten things at a time, right? Better to have ten working reusable scripts, than one single script long as hell that you can't on anything else, and it gets tougher and tougher to work on it as it gets bigger!

 

If the forum had like buttons, this would get liked. You can judge pretty fast who knows what they're talking about by what they've finished and got on sale.

 

The reusable code for most games is the bit we refer to now as "Unity".

Everything else is tailored to the specific game you are making. Aside from considering the possibility of a sequel or two, I don't see the advantage of making my code particularly reusable. All it has to do is fulfil the following:

1. "Does it work?"

If "yes", then I move onto the next question. If it doesn't, I'll go in and keep hitting it with BBEdit until it does work.


2. "Does it need any further optimisation?"

Nine times out of ten, the answer to this is usually "no". 90% of the heavy lifting is being done by the game engine itself—the part we call "Unity". For the remaining 10%, I'll put in the effort of making it play nice with the fourth dimension.

3. "Does this code need to be made more generic?"

If I'm working on a game that may spawn a number of sequels, it's worth considering this, but I do not agonise over it. I can type fast and was once able to rattle off a complete ZX Spectrum or Atari STE sprite engine in assembly language, off the top of my head, in about 30 minutes. A design pattern is a design pattern and one of the key advantages of design patterns is that you tend to repeat them. Often. So you remember them often too. After 30-odd years (off and on) of programming, I have a lot of standard recipes in my subconscious' cookbook.

4. "Is it well documented?"

In my case, the answer is invariably "yes". I'm a stickler for that as my short-term memory sucks. In fact, my entire conscious memory sucks. (I've even failed to recognise members of my own family on occasion. That's how bad it is.) I hardly ever do any conscious work though; even this post is coming straight out of my subconscious. I'm reading it for the first time as I type it up.


Here are some rules I don't follow:

1. "Is it elegant?"

I tend to go for readability. If the code is not a bottleneck, I'll write it to be as easy to follow as possible. I have a terrible memory, so this goes hand-in-hand with my documentation rule above.


2. "Is it fully generic and reusable?"

Rarely. Games are often one-offs, and even sequels tend to be similar enough to their predecessors that designing fully generic, reusable code is a waste of time. Make it as reusable and generic as it needs to be. Then stop.

Besides, the only thing that has to be reusable is that bit that already is: the game engine itself.

 

What is your goal? My goal is to finish a product. I want to get something running quickly and put it in front of my users asap. I don't want to create awesome systems that sit on my desk and rot.

What's a system? A large, overarching mechanic. Systems are teh debil. But alas, sometimes I gotta have 'em. Systems have infinite variety, such as: connecting levels together, saving/loading user data, database connectivity, etc... So, when I must have one, I make it, but I keep it simple. I never add things I 'might' need in the future.

Suggestions:
* avoid systems
* write simple code
* build only what you need
* use Unity's component architecture (aggregation vs inheritance)
* focus on working software. ALWAYS

@David - Agree.
@Hippo - Agree.
@nsxDavid - Agree.

Good luck,
Gigi.

 

More than anything I find the best solution is tocode small. If you work in small manageable chunks you will always be surprised at the number of things that become reusable.

I don't formally document anything, but I do code out of my way to make sure everything is readable. Working this way has allowed me to return to code that is over two years old and understand it easily.

Fighting the component architecture is also the biggest hurdle you can put in front of yourself. Learn to use it. Once you understand it and can leverage it with prefabs productivity will increase ten fold. I know this from personal experience.

 

THIS. unfortunately to me this is still a far off dream

 

I think the Unity Optimizing Performance video where he shows various applications of Boid's flocking algorithm outlines what's "correct" in Unity.

Taking the same code from 1.5 FPS to more than 50 FPS using nothing but code. It wasn't the shortest code snippet that worked the best, sadly.

It was more of cutting down on repetitive inner loops by selectively activating components using triggers to define a scope.

 

Can you share the link?
Gigi.

 

Edit:: found it finally http://video.unity3d.com/video/3272748/unite-07-performance buried deep in the interweb

Searched everywhere and cannot find it. Can't believe I didn't bookmark it. I can tell you the guy giving the lecture was named Joachim Ante, and it involved the boid algorithm for flocking birds.

The initial example had every bird checking every other bird. He gave the birds triggers so they only checked birds nearby and cut down the amount of inner looping bringing it from 1~fps to upper 50 fps range.

 

Optimizing a framework by suppressing request bombing (loops, Update), and replacing it by event triggering, is exactly why I can't see Components as the Alpha Omega of a solid game. I doubled my framerate by turning Update() to Event triggers and Coroutines back when I was learning Unity 3 years ago too, so I could see the concrete difference.

The problem with Components when you want to only rely on Event triggering inside a complex framework is that you have to connect them all (or make several GameObject.Find() at runtime, which is worse). So for big games, this can lead to endless, conditional, over-specific declaration functions in each Component. Plus, for behaviour management, good luck with maintaining 100 different scripts for 100 different objects.

As opposed to a core system (based on DontDestroyOnLoad), you don't need to redeclare your system data on each instantiation anymore, and keeping track of stuff is just as easy as creating a set of data dictionaries.
There are surely some clever ways to make a very complex game only with components, but imho it's far, far easier and more intuitive with a core MVC structure. Once this structure is in place, Components can be used for secondary gameObjects of course.
Components are good for small tasks, occasional behaviours, but when you start to search for deeper game mechanics and persistency, you just can't rely 100% on them.

All in all, persistent framework is king in certain situations, while components are queens in others.

 

A simpler version of my explanation below.
My 4 general rules of coding:
- tiny
- simple
- clean
- reusable (but only when it really needs).

 

The problem is that unless you already set in stone your whole framework (or unless we're talking about super simple games), you never know when you'll need to re-use a class
Maybe it's only my personal experience that leads me to believe that, but in all the optimizations I made (and I tried a lot), I always found myself packing up several duty classes into bigger, inheritance based ones.
Which each time greatly served the other points :
- tiny (merging similar duties into one),
- simple (putting all the critical, complicated stuff inside a base class, and then derive it to fancy experiments, makes much more easier maintenance/bug tracking)
- clean (derived classes are always cleaner, as they need less code to look at)

edit : lol sorry I wasn't clear, it's late here and I need some sleep : the point was that I see the "reusable only when you need it" a lot, but as it's nearly impossible to predict 100% when a class merge could be useful at some point, I'm personally searching for reusability whenever possible, even if not needed (and when it's possible, of course).

 

@n0mad,
Yes,
Reusable code is always good, but unique behavior doesn't even need to think twice if can be reusable (it's not).
That's what i mean by "only when you need it (or when you'll get real advantage of it)". Before start coding, you always create some sort of pseudo diagram, right (in your head or paper)? Once, you have the basic structure of your program, you'll have an idea if it needs to be (or could possible became) reusable. At this stage, you can predict a bit better but nothing stop you from change it later on if that simple behavior needs to be shared by other objects. That's why starting simple is always better than starting complex (it is very hard to implement re-usability and/or improve it later on).
Cheers,

 

In my experience, components are both good and bad.

They're good because they allow for quick and easy use of the Decorator design pattern, meaning that if you know what you're doing, you can create complex objects and turn them into prefabs very easily.

They're bad because they encourage amateurs to do everything using components.

I'm less than a month into Unity, and I've built an entire weapon system, item system, and third person shooter framework for my game, in about two weeks at nights when I come home from work, for about 2 hours a day.

All my weapons start out from an Interface, which then is applied to a base class (abstract) and then actually gets used in a real base class that can be instantiated (like base ranged weapon). These classes are then inherited from by the real weapon classes like "Pistol" or "Shotgun", which implement special one-off behavior by overriding base class functions.


Now, if I were to look into most Unity tutorials, they would have told me this (in a really long, annoying, unskippable video... seriously, more text less videos for scripting please):

"Oh just grab the weapon mesh, put it in the player's hands, then put the muzzleflash in front of it, a rocket behind your player, and boom you have a shooter!!"

Problem is, this shooter is all composed of gameobjects that are being rendered and being held in memory at all times. So you take this approach, which works great when you're dealing with one guy, or two guys. Then scale it up into a full blown game, and you start seeing issues.

I've seen "inventory systems" in unity that attach all inventory items to the player using game objects in the scene. Then people try to use this nightmare system to turn it into a large scale RPG and they will have no idea what they're in for.


I think its important for people to understand programming practices and learn the "right ways" of doing things, so they know when applying them is important. Sure you can do things a lot faster by taking shortcuts, but if your end goal is an MMO, I'd strongly suggest not making everything into an in-memory game object and hiding it in the scene like someone suggested earlier.

Complexity does not mean bad. There is good complexity and bad complexity, its up to the programmer to figure out where good complexity ends and bad complexity begins.

 

As we're basically saying the same thing in both our posts, I'd just add that by experience, even what would look simple games do also need this philosophy. Not only MMOs
You could think that a fighting game is goddamn easy to code (which was what I thought when I started), and in theory it is, but in the long run I just realized it was a nightmare to work only with components, even with such a simple genre (or maybe it's because I took the mmo approach with customization, idk).

In short, I'd say that any game that needs persistent data across levels can't make it without a non-component system framework.

 

You're right, I just went with the most "popular" and glaring example I could think of

 

@Rico21745,
Agree with you.
That's the problem when you give people so much flexibility (Unity), they can over abuse it and get in trouble very easy. Specially for beginners.

 

Fair enough

 

I didn't read the rest of the thread, but here's my two cents:

No programming design principle is more important than DRY: Don't Repeat Yourself. All the others, like separation of concern and inversion of control, are nice to have, but not necessary, and if it's going to cause more work than it will save, just skip the design and make it work.

"Good" code design can be a barrier to rapid iterative development, which is necessary for a truly good user experience. My advice is to just code what you need until you find yourself writing the same code over and over, or until you're annoyed that two separate things (i.e. presentation and logic) are too tightly coupled, then refactor.