Hi! I have a little question, in Aqua Rush i have a single game mode and i was planning on adding a new one. How would you manage this, would you duplicate your gameScene and make the proper modifications or add a lot of if's to the main game to handle each game mode?
[Design question] Gameplay modes
(8 posts) (6 voices)-
Posted 2 years ago #
-
It depends on how different the modes are. If you can modularize your code enough, you should be able to have two different game scenes that pull the necessary reusable code in, but that can be difficult. The alternative is like you mention - lots of if's, which can get messy and hard to manage.
Posted 2 years ago # -
I would think it depend on how "clean" you want your design to be. If it is a "one off" I guess you can go with "ifs".
You can also duplicate you game scene as you mentionned.
If possible, (it depends on your design), I would think that the cleanest way would be to make a class with all the common parts and calls to methods for specific parts and then sublass the parts. ie:
- initLevel:
{
/* Common stuff */
....
[self setup_mode];
/* common stuff */}
and have a subclass "mode_normal":
- setup_mode { duration = 120; max_death = -1; }and a subclass "mode_survival" for example:
- setup_mode { duration = -1; max_death = 1; }Posted 2 years ago # -
It depends on how you've done your code and how organized it is. You SHOULD have a hierarchy of classes and stuff, it's normally what I try and do so as to provide me with reusable code (for instances like this).
If you have a GameScene, then what I'd do is create another class and call it like GameSceneModeTwo and subclass it with GameScene. Then it'll be really easy to make the necessary changes and instead of running your first scene, you'd simply run the second scene.
Posted 2 years ago # -
Do it the OOP way - create GameScene class which has all the code and member variables that will be common to ALL of the game modes you're going to have. Then, for each mode, subclass GameScene and add whatever code each specific mode needs.
Edit: Sorry, didn't realize ob1 had already suggested this above.
It truly is the best way to do things, though. Even if you have to go to some extra work right now to take existing code out of your game classes and put it in a superclass, it will save you tons of time in the future if you ever want to add more modes.
Posted 2 years ago # -
Thanks! I have been thinking it over and i will go with the method proposed by ob1, (thanks lindgrenM anyway ;) ). As you say, initially i was going to add some if's around, but later if i decide to add another mode it will be a real mess.
Thanks guys,
Pablo
Posted 2 years ago # -
Just to add, the method of copy/pasting (duplicating) everything in a new class might seem compeling at first, but I becomes a total pain when you eventually have to fix bugs later that happen to be in the "common" code.
Posted 2 years ago # -
What I did for this is created a "GameLevelController" singleton class that is actually just a separate CocosNode that is actually added to the GameScene. That object contains nearly all the game logic (besides the logic that exists in the way smaller game actors behave). It is a little funky, besides the GameLevelController actually creates the GameScene with the proper values, and then adds itself as a child of the GameScene! This is so the GameLevelController can use the Cocos schedulers.
This structure paid off later when I wanted to add new 'game modes' and all I had to do was subclass the LevelController and override only the methods that had changed logic.
It was also a bit cleaner since my actual GameScene class only contained stuff that was more related to the 'drawing' of the game, such as the background animations, HUD display, etc...
I'm not saying that's a great way to do it, but it worked well for me.
Posted 2 years ago #
Reply
You must log in to post.