I’ve finished prototyping my idea, a fairly simple racing game. I have a scene that demos all the gameplay. But I don’t have a game. I’d like to find some resources on constructing the full game. Here’s a little diagram of what I want to do.
I think this is called The Game Loop? Don’t laugh! Not sure if that’s the jargon for this topic, but I’m new to development and that’s what I’m gonna use
So I’d like my Game Loop to work like Trails HD. But how in the world do I get this stuff to communicate with each other? Keep in mind I’m not looking for exact answers for each task (I can google search that later), but handling the complete package.
What I’m thinking is a Main Game Scene that needs variables:
Character
Level
Vehicle
Once these three variables are chosen then the option to play is available.
These variables would be populated from a series of tables? I need to be able to keep levels and vehicles locked based on player progress. Which would be medal count in my case.
Now how to do I handle playing? Loading and saving results? Can I create a custom scene as the game runs? I was thinking about having a scene per level, but not sure if that would work. Can I send data from one scene to another? That would be great since I would need to send race details back to the main scene. If a scene was an object that I could attach scripts that could work. Or do I set up a script that instantiates everything needed for a race?
To sum all this up:
I’m just not sure how to proceed with the game. What is a game? Is it a bunch of scenes that the player loads? Or is it a series of global tables that the player chooses from? Then a script makes a scene based on the chosen values?
What are some things that I need to read? How should I start?
You have the idea of the tree right… well there is no wrong really. But yah, you are heading in the right direction in terms of concept but yah, to actually make a game, you need to know a whole lot more than how to draw a diagram.
It took me a year and a half before I could actually professionally release a title.
Are you planning on doing all the scripting, modelling, level design, graphic design, sound design, and project management yourself? If so, then research each of these roles.
Yes I’m doing this myself. I’ve been using Unity for about 6 months now and this is probably my 4th prototype. The first 3 were a little to ambitious and complicated. Hell I could work on AI forever and not get anything done. So I’m taking one level from an old favorite of mine and fleshing it out. Like I said I have a demo scene with all the gameplay working. Got a couple annoying collision problems with invisible walls affecting physics (not real deal breakers though). And just need a checkpoint system for when you crash, which isn’t too much work.
Maybe my question was too vague. I understand making a scene in Unity. I understand making a menu to launch scenes. That’s really the simplest way to make this game loop I was talking about. Load menu scene, select level, load level scene, when level scene is complete load menu scene again.
Now if I want to be able to change my character in the same level scene before loading how would I do that? Like I’m thinking I need to instantiate gameobjects from outside the scene?
no. the elements of your diagram are more like different scenes or levels. the game loop is permanently processing what is going on in your game (ai, movement, kollisions, rendering, loading) and is hidden by unity. you simply use game objects and utilize functions provided by unity to do all this. for example when you need an object constantly moved you put a script on the object which contains an update method and translates the object. update is called by unity every frame.
thats your task to find out as there are several possibilities. look up application.load, dontdestroyonload, static + singleton for a start.
usually you have an array of prefabs to choose from.
then look up playerprefs + system.io for permanent storage. put a requirement on each of these and when populating the display for the player only allow those meeting the requirements.
usually you have some kind of manager handling the high level stuff and calling lower level classmethods for doing the dirty work.
if you use manually designed levels that would be best way. if you create them procedurally or load them from another format (xml, binary) you can have one trackscene which is adjusted to reflect the actual data.
have an object (manager) dontdestroyonload so it persists during scenechange. keep in mind that you should initilize such objects in a scene which is only loaded once or it checks if the object exists and deletes one or you end up having several of these objects causing confusion.
you cant attach scripts to a scene but you can attach/instantiate objects with scripts to a scene.
do some tutorials. read some books. look some video tutorials. if you lack such basic knowledge you should do study to gain it before even starting your game. otherwise chances are something important wents horribly wrong.
Thanks for the reply exiguous. Looks like a can of worms, I’ll be doing some more reading based on your suggestions. A lot of the books I have explain building the scenes in unity. Creating scripts for characters, AI, shooting, particles, animation etc. Nothing that really explains putting it all together.
What you might try doing, is mocking up all your screens, menus and options in something like PowerPoint. This will help you figure out how many scenes you need, the graphic elements and objects in each scene, how the user interacts with all of these graphic elements/objects, and what happens when they do. Jot down local and global variables in each scene. You should be able to outline everything that needs to happen in each scene “on paper” and THEN figure out your options on how to do these things in Unity.
This is the process I’ve been using for years. Start with exactly what the user sees on the screen and then work your way backwards to figure out what you need to do to make it happen.
then also make an prototype for the structure without real content or gameplay. just use placeholders for everything. they can later be filled with your content when you know what is required where.
i also tend to create the coarse structure of the project first (scenes, scene transitions) and fill it then successively.
but you should also consider that having scenes with dependencies on each other makes testing of single scenes more difficult. fe when you have one which creates the dontdestroyonload objects this is the one to load when playing in the editor and you should initialize the stuff you need there and automatically load the scene to test after that so that you dont need to manually click through character generation and track/car selection when testing your scene with the track.
To store variables all the time make one empty gameobject and assign a script that will not destroy the object when another level loads. This way you have a manager object that controls all “global” stuff. You gotta be careful you don’t want to reset or kill this object.
Next you assign scripts to it that actually store the variables. Like you store a PlayerSettings.cs(js) and in it have fields like
string name = “this und that”;
int gender = “m/f/other :O”;
and so on
You do the same for scores and stuff. You could either use the same script or make a new one for organization sake.
When saving/loading game just dump/read the info from a text file or xml or whatever you choose.
This is assuming it’s singleplayer as storing all this data locally in mp game can result in faking score and stuff if you care about that.
Then you make a new gameobject that stores purely level data like time and stuff. Or if you want, you can store each racer’s time and lap in their own object. Alternatively you can have one object and store all data in array, but it’s a bit harder to manage and I am not sure bout performance gain/loss.
When the race ends simply pass the score data to your world manager.
That’s how I do it and it seems to work. If anyone has a better way, do tell.
I’m a big advocate of having an object or two which exists throughout the life of the application for storing information. Whether it’s a static that extends Object or extends MonoBehaviour (which obviously extends Object by way of Behaviour and Component) is up to you. There are probably many MonoBehaviour-derived classes out in the wild which should have extended component.
To be honest I would say that this project could also be a bit too complicated if you are just starting out. I would recommend making a very small scale game for start to finish, just to get experience of making all the elements and understanding how they fit together. I know I had grand plans with my few first prototypes as well, and with each new project was smaller and smaller in scope, as I discovered just how much work goes into a game.
Think “state machine”.
Each of your modules (Race, Character select, track select) are a state and you have to manage conditions to switch from state to state.
Everything can be done in one Game Logic script.
The game loop is the main overall computing-feedback mechanism, this can be schematized like this :
-Get Inputs (buttons, mouse, …)
-update my logic
-draw my stuffs
Every games are based on the same “get inputs”->“process”->“output something” mechanism.
In Unity Engines, all is based on callbacks functions called by the engine, but this is the same. (OnGUI(), Update() …)
The loop nature of things comes from the modern 3D rendering pipeline, that needs to draw stuffs again and again, even if it does not change
Great replies everyone, thanks a lot. This is starting to make sense. Finally I’ve realized what the topic is, how to store data between scenes and accessing that data. Getting excited. I also tend to think out load, so if I start rambling I’m sorry, but I don’t really have anyone to discuss this with other than here.
I think I’m gonna start out making a couple persistent game managers. One for the tracks and one for characters. Gonna keep it simple, then start adding more to each like keeping track of best times etc. Right now, just keep it so that it stores the game objects. Then probably have one scene that can interact with the data from those managers, displaying it for the player in different menus. So the only combinations I’ll have is level and vehicle, with those things chosen load the scene and play.
The thing I’m curious about and need to experiment with is interacting with this data from within different scenes. You all have already given some examples that I’ll have to research. So basically I can have a scene per level. Then inside that scene I can have a script that interacts with character manager the spawns the character from the character manager script and be ready to race. Or maybe the best thing to do is keep the menus inside the level scene? hmmmm…Each level scene would have the vehicle select inside it and you would have to choose them before the level begins. If I can figure out how to write this to the player prefs this would save the default selection for every level. The player wouldn’t have to reselect their favorite picks for each level. But they would still have to go through the menus for each level, which could work.
Very interesting, thanks again for all the replies
Just another thanks to everyone. I’ve got three persistent managers now that keep track of what track and vehicle is chosen. The third is a GameManager that checks to see if the managers exist and control instantiations of elements. Loading different scenes while accessing these managers was alot easier than I thought. Just had to make a script in each scene that querys these managers and loads the correct information. Also got my checkpoint system working really good and a countdown timer and level timer working.
The only thing left that I need to do now is when a race is finished is to save the player name and time to the player prefs. Maybe eventually saving those results to a server but that can wait till later. Found some resources online so this shouldn’t be too bad. It’s like anything, once you figure it out the first time, you find all kinds of applications for it. But I think once this is done I can start putting effort into art and making this thing look pretty.
Again, thanks everyone for their time, I love learning this stuff.
