koobas.hobune.stream
Starting the Project
So I have a pretty solid plan of what me and my design partner on our game want on a pretty high level but soon (very soon) we want to take all our design documents and actually write some code. You see, I have experience with lots of languages and APIs including Flash Actionscript 3 and C# XNA Framework. However, what I want to know is how to start the coding of my project. Specifically, I want to know:
1) Where is the entry point of the game code?
2) How I can write my game logic code (say for game state managers, networking, and all other non-gameobject code) and how to integrate it with Unity?
3) Is there any tips or pointers people can give me about writing the meat part of the code with Unity 3D (ie. like how people found helpful in the designing the layout of their besides writing up design docs and UMLs)?
Now I know this may sound trivial and stupid but I am new to Unity 3. I think their engine fits our needs so we're going for it (as opposed to XNA or UDK). The help on coding seems all over the place (except for the API reference guide). I want to make our project design fit this engine in using what has been developed and then adding what we need. I do come from a computing science background and I am well versed in C# and .NET programming.
You should look at at least one of the example projects. Also this is a general discussion question that should be asked on the forums; it doesn't have any specific answer. The point of UnityAnswers is specific answers to specific questions.
I'll try to answer a few of these questions and give you a little bit of advice on my typical workflow. Unity allows for so much flexibility when it comes to OOP design. It is one of the many things that I love about the engine. There are a few quarks when it comes to updating certain parts, but nothing too difficult. I've had my share of nulls!
When creating a game, you can set the first scene (usually the start menu) in the build settings. The scenes you want to include in the game will be numbered 0 to whatever. Make sure scene 0 is your atart.
As for game states, I'll expand on two parts. The first, switching from scene to scene, is pretty easy. You simply make some button or code call Application.LoadLevel("nameOfScene"); Usually best to set this in a function since you might need to pass through some variables. As for game states, such as a paus, cutscene, and so on... I set up an empty game object in my scene and usually put in a class that has a bunch of globals that will be used all over. I'm big on enums so I usually put all of my states in a static enum. Make sure to set it to static. Another useful thing I usually put in there is Physics overrides, such as keeping the enemy from colliding with itself.
My advice for code is to take the time to learn the docs. Start with something small, and try to find the answer in the docs. Before you build anything play with the engine and build yourself a hello world or pong. You'll never memorize all of the code that unity has built right into it, but you can become better at learning how to look things up. It sounds kinda strange I suppose, but it's worked well for me... Maybe too many days browsing through javadoc...
I hope that helps you get started in the right direction. Oh, one last thing... When I am prototyping a level, I usually build my assets with prefabs. Learn those. It is easy to swap things out down the line by working this way.
Good stuff.
I'll throw in a little nugget I learned recently:
If you have a script that is used only to hold data, you might want use a ScriptableObject in s$$anonymous$$d.
ScriptableObjects are awesome: they hold serialized data and don't need to be attached to GameObjects. You can create multiple instances of the same ScriptableObject and store different data in each one. You can then store those instances in your project (and on Asset Server).
If you've ever lost all the values stored in a script and had to re-wire them from scratch after a re-import, that's a good reason to use ScriptableObjects (they eli$$anonymous$$ate this problem).
(this is more @ChefZweegie than the OP)
