koobas.hobune.stream
How can I start unity fast with my C++ engine
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?
Thanks
A lot of the things you implemented for your engine are already in Unity, so I don't think you will have to port a lot of code. Almost all code you write with Unity has to do with the semantics/operation of your game, not the underlying architecture.
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
Actor,Enemy,Wolfderived from each other. In a component/entity system, everything is aGameObject, the wolf would have aModelComponent, and aWolfAiComponentattached.The typical workflow is this: first you start a new scene and create lots of
GameObjectsby adding 3D models, lights and stuff to it. Then, when you want something to move, you attach script components to theGameObjects- classes derived fromMonoBehaviourthat you write in UnityScript or C# and which have avoid Update()method where you can put your code to react to input, otherGameObjects, etc.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
GameObjectyou'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 aDamagecomponent and model, turn that into a prefab, then inGuncomponent 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.
Thanks for the info! Actually I was co$$anonymous$$g from java first then moved into C++ so I know fairly well about the stuff you mentioned. I also get the idea of component/entity system, it's like a multi-layer inheritance thing as I used to read the source code for half life 2 and that's what they did. So we are basically writing script code in this case? Seemed like a lot less work than builing one from scratch like what I was doing.
Also, can you build 2D game with the 3D editor? I still want to use the lighting and possibly some tweak with shading on 2D texture as well.
Yes, it's more or less script code you're writing, though of course the scripts are first class citizens in Unity and you've got a full program$$anonymous$$g language with threading, sockets, using existing class libraries, etc.
I intentionally didn't write much about the 2D part of your question because I've never tried 2D. Lots of people seem to be using Unity for 2D games and there are kits in the asset store, but I don't know how well they interact with Unity's lighting or if they bring their own lighting system.
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.
You can buy massively high performance 2D plugins to Unity for a few dollars too - it hardly makes writing one worth it except for the experience of doing the work.
@whydoidoit I have pretty solid skill with java as well, is C# similar to java in terms or memory management? Also, if I try to start again, what will be the good source for me to look at providing I already have program$$anonymous$$g skill and is only making 2D games?
Yes now C# is much more similar to Java in terms of design principles and memory management - yep.
Well there are a bunch of tutorials out there - worth Googling - I don't have an immediate go to source for that. I strongly recommend using 2D Toolkit anyway - and they have some good tutorials.
