Standard Object Structure

I think I'm comfortable with C# enough now that I'm ready to start getting a basic 'framework' going for a project, and my goal is to use the editor as little as possible for the sake of more practice with the code, and to make it a little more.. 'pro.' (and plz tell me if thats the wrong ideology)

I'm wondering though about actual design of the game itself. I know I want a multiplayer component, players, scores, etc. but my question is how should I structure the whole thing. At first I approached it from working with the GUI, then handing things off from there, but I think I would run into problems down the road. I guess what I'm saying is I know how to do some programming but I don't know how to construct a game? If that makes sense. Are there any resources out there that can tell me more about programmatically structuring a game vs. "Here's how you make a terrain, click on..." sort of documentation.

Thanks for any replies.

 

Here's what I do. First, I figure out what your game is going to be like ex. RPG, FPS, RTS, etc then creating the controllers for your characters and creating simple gameplay with your scripts and primitives, or models if you have them. Then I put the models together and add the animation controllers. After that I add the GUI and the other things of that nature. Then Unity does the rest . I hope that is what your question was about and that I answered it ok.

PS I don't look at the Unity editor as unprofessional because if I figure a great tool like Unity is going to waste if you don't, and I think your professionallity (made up word) should be judged based on the quality of your games, not how you made them.

 

Thanks Peter, thats actually tremendously helpful.

And yea you're right, Unity's editor is in no way unprofessional. I guess I just want to be able to separate some things I know I'd rather code by hand vs. be locked into some things with a scene file (if that's even possible) Obviously the larger goal in the long run is to produce something commercial.

I imagine though that if I say wanted to dynamically generate terrain on the fly, I would need more hard code behind that on a global scale vs script it per scene. Or.. something like that.

I come from a limited Torque background where a lot of things have a very rigid structure to how you do them, hence the question.

I want to try my hand at a small turn based game, so based on what you suggested I'll start with Player objects first, then gameplay, etc.

 

Not necessarily. Unity provides you the ability to change terrains and almost every other detail. To generate a terrain like that you would just need to attach the script to your terrain in the scene. Here's the page on terrains. If you want to change them procedurally than you want to change the heightmap. It's not just terrains either, you can modify almost every game object at runtime.

http://unity3d.com/support/documentation/ScriptReference/Terrain.html

Check out the terrain data in paticular.

 

One more question on this. Do I have to worry about GameStates?

Do I have to get that low-level or can the literal start of the game at execution be a menu on the fly. I know this is possible, but is it wise?

 

Unity will do all that for you. Just put the first scene you want loaded in build settings and Unity will load it for you when your game starts. You don't have to worry about any of that stuff. All's you have to do is create each scene with scripts, models, etc. and Unity will compile all the information. Then call Application.LoadLevel() from a script and load the next. It's that simple. Isn't Unity great ? If you do want a variable to carry from scene to scene you can use the static keyword.

Does that help?

 

Again, wonderful. Thanks Peter.