Does everything have to be gameobject based?

Questions & Answers
1

So, I’m coming in Unity from extensive Director/Shockwave Lingo programming, with a little bit of ActionScripting in Flash.

After running through a bunch of tutorials, I’m will to try and start a simple “figure out how it works” project. However, there is something that I can’t wrap around my head, or otherwise I just can’t find the answer to.

Typically, my programming flow usually starts with…at the very beginning of the program, load in all the data and initialize all of my needed variables and such. Then I have all of my software which then creates or commands the graphic entities to their thing.

For example, let’s say I want to create a simple “find words on a grid” game. The first thing I would do is load in an external file of possible words into a data array variable, then I would have a bunch of functions where I would feed a list of letters to search for a possible word. Then there would be a bunch of functions that would create letter tiles and set the tiles to various statuses (stati?), such a selectible, what letter is it, etc. The letter tiles would have behaviors that would interpret those external functions, and take in mouse clicks or other inputs from the player.

Anyway, the issue I’m having is that the functions that handle the database of words, and the search for word functions would be “standalone” kind of functions and mehtods…things that I wouldn’t want to attach a visible GameObject. In flash, I would instantiate these thing at base root level of the game…in director, these would just be floating global functions.

But everything in Unity seems to be tied to a GameObject of sorts. Is this true…or am I missing something? I’ve played around with ScriptableObject, but then again, the only way I could create it is by having the camera instantiate it – thereby linking it to the camera. Does something as simple as keeping track of a gamestate need to be attached to a gameobject in some fashion?

3

Static methods can be called on scripts that are not attached to any game object, so anything you implement static, you can just access through the script's class name without having an instance.

However, you should note, by building it that way you lose the ability to view or modify any variables from the inspector, since static variables can't be inspected. As a result, it's often best to just have an instance attached to an empty gameobject, as cj suggested. If it's just a library of functions, with no internal data of it's own, then the all-static approach can work fine!

:edit: ptdnet took this answer in a different but equally useful direction, though note that if you're using unityscript, the class matching the file name is implicitly created and always inherits from MonoBehaviour, but that doesn't stop you from defining additional classes inside them which inherit from anything or nothing, and using those classes from other scripts.

2

Everything does not have to be a GameObject. For instance, my game data is always in a plain old class…

public class GameData {
   public int score;
   public string playerName;

   public void SaveGameData() { ... }

   // blah blah blah
}

There’s no reason for this object to have a Start, Update, a translation, an animation, etc. so it’s not a GameObject or a MonoBehavoir.

That being said, most of the code in your game is going to be directly involved in moving players, blowing stuff up, etc. So your code will be attached to those objects like Players, Bullets, Booms, Trees… all of which are going to be GameObjects of some type.