Game rewrite for Unity

Scripting
1

I’m a complete Unity beginner, but with a few years’ experience of C++ and GPU programming. Alright, I was toying with a new game idea and wanted to try it out in raw C# code. Before I knew it I had some 5000 lines of code and a little component-based engine that I was quite happy with.

At that point I realized I had to switch over to Unity or I never would. So now I’m in a bit of a quandary: I don’t expect two rival component based architectures to simply work alongside each other, so something has to go.

Since I cannot derive from GameObject (which would do the trick in my case), it seems I have two options:

  1. I could relegate my GameEntity class (which is analogous to Unity’s GameObject) to MonoBehaviour, turning it into a component, while I keep my components out of sight. This seems to destroy much of Unity’s flexibility as a game engine.
  2. I could turn my BaseComponent class into MonoBehaviours, more closely mimicking the CB architecture. I like this option, but my problem is this: what will I do with my GameEntity class? It seems that I’d have to scrap most of what I’ve written so far, since quite a bit of code is coupled with the Entity and related classes.

Alas, I need Unity for the graphics and UI.

Thanks, I appreciate your help.

2

Wow I respect GPU programmers.

I’ve programmed with C# for a few months now.

The way I understand Unity, your script is another component of the Game Object. Unity is pretty powerful as it is I don’t see why you would need to implement these classes. I’ve never made too many deep classes in unity. I’m satisfied with keeping the scripts small and by function.Some of the developers get upset when they can’t modify your class because you’ve passed them a DLL file.

Every new C# class inherits from Monobehavior by default. A complete rebuild might help you learn unity inside and out.

Seeing that if you’re a GPU programmer, there is a special area to write shaders, the game studios I’ve worked with really could use some shader experts.

Most of us programmers use the Unity Reference from the website to guide us.

Hope that helps.
TY.

3

this is not correct. this only applies to unityscript (don’t know about boo). a c# script has to be explicitely derived from monobehaviour.

i call my non monobehaviour classes nameclass, and my monobehaviour derived classes namescript. this way i can easily spot the difference. only scripts (inherited from mb) can be added to gameobjects as components. that beeing said why don’t you leave your classes as they are and link them to the representing scripts? i have lots of starsystems, planets etc but only one starsystem can be viewed at a time. so i have stars, planets etc represented by plain classes and i have scripts for star, planet to represent the entities in unity, display them to the user, recive clicks etc… there is no need to keep all gameentities as game objects all the time (think of overhead and limitations).
when a star system is loaded i spawn a prefab with the corresponding script for each class inside. so for the starclass i spawn (with poolmanager, equals instantiate) the starprefab with the starscript. the starscript gets a reference to the starclass and calls an initfunction to adjust visuals (size, color etc).
so you have the possibility to link your non mb classes to mb scripts. but i don’t think that is clean. from personal preference i would go for a complete rewrite to utilize unitys paradigms.

when your code is in c++ you can only run it from unity pro (native plugin dll). if you don’t own pro and don’t want to purchase it you need to port it anyway.

4

What does your GameEntity class do that GameObject doesn’t?

If the answer is “nothing” then you could try just renaming symbols in your present codebase - rename GameEntity to GameObject, BaseComponent to MonoBehaviour, etc - and maybe use extension methods to add functionality that isn’t present. Then you should just be able to bring your component classes into Unity and have them ‘pick up’ Unity’s GameObject instead of yours.

5

Thanks for the replies. Since I asked the question I’ve actually started working on the conversion and so far it’s been easier than I expected. I’m changing my components into MonoBehaviours and that looks good.

About the only thing I’m missing about my GameEntity class is that I could subclass it to add some component management in it; so I could have, say, a Tank class that made sure that it had components of a certain type, etc. Of course now I could do it by means of helper classes, but that was efficient, clean and convenient. Well, unless I’m missing something (which I probably am).

Has anyone tried wrapping a GameObject in a MonoBehaviour? Does that work well?

6

Extension methods might help. I’ve added, for example:

    public static string GetFullPath(this GameObject go)
    {
        if (!go) return null;
        string result = go.name;
        while(go.transform.parent != null)
        {
            go = go.transform.parent.gameObject;
            result = go.name + "/" + result;
        }
        return result;
    }

That allows me to call ‘gameObject.GetFullPath()’ as if the GameObject class itself had implemented it.

It’s not clear what you mean. Like having a component on your GameObject that does the extra work sounds fine to me.

7

Ha, the powers of C#! OK, coming from an austere C++ background I had no idea that kind of thing existed. Thanks for teaching me something new. But, my basic idea would have been a clumsier version of that.