Monster Racer Rush
Select between 5 monster racers, upgrade your monster skill and win the competition!
4.23 / 5.00 3,881 ViewsBuild and Base
Build most powerful forces, unleash hordes of monster and control your soldiers!
3.93 / 5.00 4,634 ViewsOkay, I know I've tiptoed around this subject in past threads, but because I tiptoed around it, I never got a clear response. Now, it's time to focus. Now that I have a fairly decent grasp of object interaction, I really need to start putting a game together.
What I need to know, exactly, is how to actually put all these pieces together. What is the best, yet simplest, way of building a simple game. How does one go about creating level hubs, levels, menu screens, game over screens, and all that stuff?
This is how I assume things will have to play out from the moment the game starts:
From my doc class I will add a main container, then I will add a container to handle all of my intro stuff (on Newgrounds, presented by Barzona, etc..), after that, I will remove that container from the main container and add my "game container". From that point, I will add all of my other classes to the game container, particularly one that will control switches between levels. I'm going to include a picture to help understand my slurry.
Really, it seems like everything will boil down to a lot of container control. Is that how this thing is usually done? Am I right in assuming that as long as all of my classes are added to the main container, everything in the smaller containers will be able to see them?
I just want to create a good, working system that has a main menu, an upgrade menu, and some kind of level select screen. maybe even cut scenes and an ending. Once I have that, I can start filling it up with all the little things that make games wonderful.
Think of it like a bento box. I need to know how to create the box so that I can start to fill each compartment with yummy food. This is going to require bigger thinking than I've ever had to do before.
The way I do it is via managing states. Your states will be intro, main menu, main game, and whatever else. They would all implement some interface, IState, which has common methods. StateManager and all its friends are just public vars that you can access from any class that has a reference to the main engine. The states are not public.
Engine (doc class):
instantiates state manager
instantiates any other managing things (fade manager, etc)
ENTER_FRAME
RENDER
if you use something like my key helper class, that goes here (stage-related things)
IState (interface):
init() creates anything that needs to persist even when the state isn't active
dispose() removes all that stuff, basically gets it ready for the gc
enter() adds everything
exit() removes everything
render() what to do when rendered (doesn't matter so much with movieclips)
update() loop
sprite to add and remove ("container")
StateManager:
pass the engine as a parameter
inits all states
has a swapStates method where you specify which state to go to next
swapStates exit()s the current state and enter()s the new state
handles transitions between states (by throwing in a fade or something)
GameState (example):
pass the engine as a parameter
init: instantiates the container sprite
dispose: removes the container sprite
enter: adds the sprite to the engine (you should have a reference to the engine: engine.addChild(this.sprite)), also adds a CLICK listener
exit: removes the sprite and CLICK listener
render: blits if using bitmapdata
update: main game loop
This is the skeleton of the source code. Ask questions here since I'm sure you will have some, and I'm sure everyone else reading this will as well.
At 9/2/13 11:34 PM, MSGhero wrote: Lots of stuff.
Man, my brain is fried. I get the gist of what you're trying to do, but I have no idea what things with ".enter", ".invalidate", ".update" do. You certainly have a more advance coding structure than I'm able to fully comprehend, but I'll try.
I assume each state will be named with a string and that is where I'd start adding new states, like "inGame", "upgradeMenu", "etc...". Is that what I need to be doing? This is all about activating, and reactivating these gameStates, right?
Really not sure how the rest of the game would connect to this engine yet.
Sorry that I don't get it too well. haha
At 9/3/13 06:12 PM, Barzona wrote:At 9/2/13 11:34 PM, MSGhero wrote: Lots of stuff.Man, my brain is fried. I get the gist of what you're trying to do, but I have no idea what things with ".enter", ".invalidate", ".update" do. You certainly have a more advance coding structure than I'm able to fully comprehend, but I'll try.
.invalidate is a method of the stage which makes the render function go
.enter is what you call to turn on your state
.update is the equivalent of ENTER_FRAME, except we told you to only use one enterframe
I assume each state will be named with a string and that is where I'd start adding new states, like "inGame", "upgradeMenu", "etc...". Is that what I need to be doing? This is all about activating, and reactivating these gameStates, right?
Pretty much
Sorry that I don't get it too well. haha
Took me 2 years to come up with that, so give it some time lol
Wow I've always wondered the same thing as Barzona and man...... my brain is fried too by everything
MSGhero just put up...
No wonder you, MSGhero, can always help me out with my questions....you've been at this for awhile haha
I have so much more to learn.....welp, time to go back at it.
Just wanted to let you know that by sharing knowledge like this helps everyone eager to learn on the forums and not just the individual who is asking the question :)