I’m a programmer working on games. I just graduated from college a few month ago, and in particular my speicilisation is game programming (computer science branch), so I know a fair amount of stuff regarding programming games (architecture, coding, and stuff). Having been working on my own game engine for a while (a 2D side scrolling game engine) I decide to switch to unity which offers more potential and can save a lot of work.
PROBLEM IS: I have no idea about how unity works, excecpt for the claim that I hear from someone saying I still need to write a lot of code, which is fine for me. But I don’t know where to start.
Apart from that. I have a 2D game engine written on my own in C++ that’s already playable (features level loading and other manifest stuff, simple AI and physcis, operatable player by input, simple animation system using sprites, OS message handling, DirectX graphics, etc). And this is exactly what hesitates me from switching: I don’t know how much overhead there is and I don’t want all my previous effort to go wasted. Afaik, unity supports C# but not C++, it will be a lot of work to port all these code into C# (I don’t plan to use Unity Pro now so by compiling C++ code into .dll is not an option). Despite all that, I don’t even know anything about unity so i don’t know if my assumption is plausible.
So my question is. Is there a fast way of starting Unity with the possible usage of my exisitng C++ code? (I could bare porting these into C# if I really have to) I’m only making a 2D side-scrolling game so it doesn’t have to be that complicated. But I do plan to use lighting with my 2D textures. And what’s the estimation of overhead for switching?
It’s a pretty widely scoped question, but I’ve come the same route, so maybe it helps if I cover those “A-ha” moments I’ve had
First, as a C++ programmer, likely the engines you know are code-first and if you want map editors with instant feedback, you have to write that for your game. Unity isn’t totally different, but it already comes with an editor and puts it in front of everything else instead of confronting you with the code first.
It helps if you know component/entity systems (<- good google keyword) like Artemis. In short, in an classic engine, you’d have classes like
Wolf derived from each other. In a component/entity system, everything is a
GameObject, the wolf would have a
ModelComponent, and a
The typical workflow is this: first you start a new scene and create lots of
GameObjects by adding 3D models, lights and stuff to it. Then, when you want something to move, you attach script components to the
GameObjects - classes derived from
MonoBehaviour that you write in UnityScript or C# and which have a
void Update() method where you can put your code to react to input, other
Any public variables in your components become editable in the Unity inspector and are automatically saved in the scene. Most importantly, you can create public variables to hold other objects (
GameObjects or components directly) that you can then drag-and-drop onto the inspector window and these references will be saved with the scene, too.
Another important concept are prefabs. You can pick any
GameObject you’ve built in the editor, no matter how many children and components it carries, and turn it into a prefab. Prefabs can then be instantiated into a scene as often as you want. For example, you could create bullet with a
Damage component and model, turn that into a prefab, then in
Gun component create instances of the bullet whenever the player hits the fire key.
It only gets better from there with custom inspectors & editors, Mecanim and PhysX. You just have to re-learn your approach to object model design if you aren’t used to component/entity systems, that imho is the biggest hurdle for a programmer.
C++ to Unity C# is a pretty big switch - they are syntactically similar but totally different in design principles and architecture. C# is a .NET language that has a very different approach to memory management when compared to C++, plus a zillion other differences really.
If you’ve already built an Engine, don’t consider trying to port it - there would be little point - you’d be fighting the opinionated nature of the Unity Framework. That said, you will find so many useful things in Unity that it is certainly worth building games in it and extending the framework that exists to encompass your techniques. It would be a decision to start again though in my opinion.