I am attempting to create a framework where I can have multiple events all use the same room.
For example, the player triggers an event and the event builds the room with the passed in variables.
I am having trouble making the room dynamic. I want the room and the objects in the room be reusable for every event. This includes the buttons as well.
Is this possible to do?; OR
Do I have to create separate rooms for each unique event I wish to create?
The game is mostly menu based (like the game "Long Live The Queen") if that helps.
To answer simply, yes it is possible.
There are a lot of cases where I have been able to fit a lot of stuff into a single room in Game Maker. Here are a few ways to achieve this "dynamic" game creation:
Files and Scripts. You can use a single room to hold a variable number of levels by storing walls, floors, player positions, events, etc inside of a file. You can make a script that takes the filename (your "passed in" variable) and then let it simply create all of the instances inside the level for you in that room. You can also have a function that cleans up the room to prepare for another level to load. The side effect though is that your uniqueness is limited to what information can be stored in those files. You can store menu options and text dialog too if you wish.
"Unique" Objects. Game Maker is an IDE. There is nothing stopping you from making new objects in the editor for a unique case and then adding a handler in another object to create it on demand. You have to manage switching between them though.
Make a "manager" object. It can handle all of the events of something happening in-game (and in that room, for that matter). Plus also it can be used by objects to store non-global variables before being destroyed. For instance, if a character dies, it can set a variable in a manager object to "true", which would trigger a boss to appear.
In terms of manipulating object events dynamically though, unless you are running something like Game Maker 8, that is no longer possible. I say this because prior to GameMaker:Studio, object, sprites and others can be created dynamically in game via functions like "object_add()". Of course, these are obsolete and can no longer be used. Nevertheless, there are always ways around it.
Related
I have a simple game, breakout clone.
There is gameplay layer, menu layer. I can call menu during play just fine, can use next level button ( it makes new gameplay layer with next level and transitions to its scene). But what i want is at the end of level, when I killed all blocks I want that menu to pop up so player could click next level. But the provlem is that i store blocks number in gameplay layer, so when they reach zero i get certain property turned to true. But when i try to read that property from menu when level ends, i can't, because my gameplay layer is already deallocated since i transited to menu.
Tldr; how to change level with button?
I think your question is about Game Architecture. There are lots of trade-offs regarding how you choose to architect your game. This is something that I have thought a lot about as I have created Cocos2d games.
The comment by Shailesh_ios will work. But if you want to create a more complex game you should consider designing the game in a way that neatly organizes the different modules and components in your game so that they are easy to use and support. As your game gets more complex it can become very messy if you add loads of functionality to the AppDelgate. To stay organized and keep your sanity when updating your code, I suggest creating a centralized game manager service in your game.
Create a Centralized GameManager Service
--For all centralized services that your game will need, one thing that has worked good for me is to create a game manager class that is a CCNode or NSObject subclass. This class is made into a singleton. I then create separate classes for things like GameCenter, OpenFeint, In-App Purchase, player preferences, local scores and achievements, physics world manager, game audio, game state, etc.
Add class instances as modules to the GameManager
--These classes are all then owned by the GameManager singleton class and can provide services to the game components that need them. Since these classes generally use very little memory there is no need to constantly be creating and destroying them each time a scene changes, which just wastes CPU cycles and battery life.
A note of caution
--Be careful though, because it is easy to abuse the global singleton GameManager class by adding things to it that don't belong in it. Any centralized service that may be requested from various game components could be considered to be added to the GameManager. By adding to the GameManager, I mean coding each module in its own class and then have it be created and owned by the GameManager.
Examples--
For example, your custom local scores and achievements class could be setup to store a players scores, persist them to a file or NSUserDefaults, and make that information available to any game component that needs it.
The custom GameCenter or OpenFeint class would take care of authenticating the player and then as a service provide submitting scores/achievements, downloading scores/achievements, presenting the built in GameCenter/OpenFeint UI for leaderboards and achievements, etc.
This way you can focus on designing your game and have the basic services a game needs available from anywhere within your game.
I have a rather large application I'm trying to make in Visual-C++, and I am now trying to add undo/redo functionality.
Having a rather large amount of events (button clicks, label text changed, etc.), I would like to find a way to undo/redo without adding code to every function.
For Instance, I would like a class that can read every event done and store it automatically. Then in my undo/redo events, I can just get the latest action stored.
If that is not possible, I would not mind some other way.
Any help?
Declare a class that represent two operations - undo and redo.
Also create two vectors of that class.
For each operation you want to apply undo/redo, push an instance of that class into the undo vector. There should be as many derived classes as there are opreations you want to undo.
For example, if a button click paints the background to green, you create a class instance whose undo metdho paints the background to the previous color, and its redo method paints the background to green, and stuff it into the undo vector.
When you undo - you pop the last class instance and call its undo method, which will paint the background to the previous color. Then you push it to the redo vector.
When you redo, you pop the redo vector for the class instance at the top and invoke its redo method, them stuff it back to the undo vector.
There are some corner cases (boundaries), you'll tackle them when encountered.. :-)
Do all of your events pass through a queue of some kind? by default in c++ there is no queue like this (there is a windows os level event queue, but that is likely managed already and unusable in c++-cli and you did not indicate if this closely mapped onto your problem), there may be some other construct I am unaware of.
If you have some central queue, then it is just a matter of capturing events as they pass through and knowing how to undo each action. If no central queue is present then I see no other way easier than changing each undo-able function to create an undo object of some kind and storing it in and undo queue of some kind.
In a pure .net or a C++ environment without a large central work queue I would make a class that is and undo entry, that implements a method/member function to undo and another to redo/do the work. But for just undo functionality, this could be just a .net delegate or a c style function pointer, and a list of arguments. If you make an action undo/redo class it could be a template or generic that stores pointers/delegates to the the do and undo functions, and a list of arguments from when it was originally called.
These can be run to undo the actions that have been done. They will be inserted into a queue container of some kind, the kind of container doesn't seem to matter as longer as it preserves order, your should pick the best std, .net or other container for your application. You can discard older ones when you no longer need them. When executed the entry last inserted into the queue must be removed to preserve consistency.
If you also need redo functionality, then your queue of actions done must be iterable, and it would be easiest to use the class that was and action had a method/member function that could undo/redo the desired actions. You would have and iterator, pointer, index or marker of some kind indicating how far back you have undone. Every time an undo is requested you must move the marker backward (earlier chronologically) and execute the undo command at that point in the queue. If a redo is requested then the current item indicated executes its redo instruction and then the iterator is advanced forward (chronologically) through the queue, or ignored (I presume) if you are at the forward-most item in the queue.
If you wanted to go off the deep end, which you have no way indicated you want to, you could center you app around the action queue. You might not need to change you functions implementing this approach. Your user interface (I assumed, could just as easily be your API) functions, insert actions (which support doing and undoing) into a queue, and then command the queue to do. You would not have to change your existing functions if their side effects are known and reversible. However, you would need to change all the callers to make actions instead of directly calling, and you would need to write counterparts that do the undoing.
I've tried to achieve something like that in a small experimental library: https://github.com/d-led/undoredo-cpp. It contains an implementation of a TransactionStore similar to what CodeChords man suggested. You might need to really add functionality to each of your undoable objects, and also take care of object lifetimes, in case your actions involve object construction or destruction
I should find another interest because this one is taking the life out of me quickly. Seems like a lot of people are confused about the intricacies of MFC code, including me. I have an MFC Dialog Box application that creates several dialogs that you navigate to using the typical back or next function. Along the way you collect data via radio group buttons, list boxes and various other controls. For the most part I understand how to get a handle on the data by using the m_ variables provided by the AFX maps throughout the code for each distinct dialog. At the end - and sometimes during - the data collection/selection process gathered by dialogs, I need to do things with what has been collected. I may need to take the data from one dialog and modify the next based on the previous. It seems like when you move through the dialogs the data from the last is lost unless you save it somehow. I know that there are dozens of ways to do this and I have toyed with several of them, from object passing, to creating new classes, new structures, global variables, pointers, whatever.... My concern is, I need a data structure of some sort to stay up and active in memory long enough for my user code to do something with it. That is the problem I think, I don't know in MFC how to deal with this. I have currently decided to go with a struct called dlg_DataHandler (to house collected data from each dialog) with a few test members in a .h file. It has been typedef'd as a pointer. I am creating a variable of this type and setting it = new dlg_DataHandler, but the data isn't getting passed around like I want from dialog to dialog. One thing that I wonder about is, I don't know exactly where to place the "new" statement for creating the variable. Its as if data is not flowing to and from the structure as it should. Anyway here is some of the code:
// file1.h
typedef struct dlg_DataHandler {
int var;
char* String;
int RepetitionRadio; // radio button data
constructor here
} *dlgDataHandler;
extern dlgDataHandler DlgData;
//*****************
// file2.cpp
dlg_DataHandler DlgData = new dlg_DataHandler; // not located anywhere in peticular just in the code since I DON'T KNOW where to put it. DlgData->member gets loaded in the dialog .cpp files to try collect data, but it doesnt seem to be passing data across the different windows.
Put the variable in your main application class (the one derived from CWinApp) and call new in InitInstance(). You can then use AfxGetApp() to gain access to the application instance, and so your variable, from anywhere else in the code.
Sorry for the ambiguous title. What I am wondering is what is an efficient way to alternate rendering between lets say a main menu, options menu, and "in the game."
The only two ways I've come up with so far are to have 1 render function, with code for each part (menu, ...) and a variable to control what gets drawn, or to have multiple render functions, and use a function pointer to point to the appropriate one, and then just call the function pointer.
I always wonder how more professional games do it.
Try to use state-machine / strategy OOP pattern. Game application is in different states and renders different things and reacts on keyboard/mouse input differently when you are playing and when you are interacting with menu.
Well this is a bit more complicated if you want to do it right.
First I create a CScreen class that's the base class for all the screens. It's an abstract class( use pure virtual functions) that has 2 functions: Render and Update. Then I derive it in more screens that I need such as CMainMenuScreen, COptionsScreen, CCreditsScreen, CGameScreen etc. Let each of these classes take care of their own stuff. In each of them you have the interface and then when press for instance the options button in the main menu screen then you change the screen to COptionsScreen. For that you have to just keep one variable CScreen screen somewhere and on every frame call screen->Update() and screen->Draw() remeber to adjust if you do not use pointers(tough I'd recommend this)
If your controls are represented as classes then a polymorhic API render would solve the problem. Depending on the object ( menu types) the corresponding rendering happens.
class UIObject
{
public:
virtual bool render() = 0;
~UIObject(){}
};
class MainMenu : pu{
public:
virtual bool render()
{ //rendering for main menu
}
};
class OptuionMenu
{
public:
virtual bool render() { //render for option menu}
};
Games that I've shipped, that have sold lots of copies, have had a state machine and used switch statements to choose the appropriate functionality. While ostensibly less flexible than an "OOP" state machine, it was far easier to work with than the OOP designs I've subsequently been subjected to.
It actually may be appropriate to have only one render function, but that function shouldn't know specifics about what it's doing. It'll have 3D and 2D passes (at least, for a 3D game, since even those often have 2D UI elements), but it doesn't need to know what "mode" the game is in.
The magic happens in the UpdateMainMenu or UpdateGame or UpdateInGameMenu functions, as well as the Start and Stop functions associated with switching states. Choose which with a switch statement on an enum and use it two places, switching states (one switch to stop the old state, one more to start the new one) and updating.
As I write that my alarm bells go off that this is a perfect opportunity to use OOP, but from experience I would advise against that. You don't want to end up in the situation where you have a million little states that are coming and going; you want to constrain it to the major "run modes," and each of those modes should be able to operate on data that tells it what to display. E.g. one state for the entire in-game menu, which "loads" data (usually, "updates its pointer to the data") to indicate what the behavior of the current screen is. There is nothing worse than having a hundred micro classes and not knowing which one triggers when, not to mention the duplicated logic that often arises from such a design (game developers are very bad at reducing duplication through refactoring).
In web development, when we want to pass something between different pages, we might use the Session to save the data. But in MFC, what can we use to store these things?
Thanks!
Typical MFC Applications will have a Document-View-Frame architecture. Data is stored in the Document object, and accessed globally. You can access it anywhere via AfxGetMainWnd().
AfxGetApp() will also get you a pointer to your main application, which is another good spot to store data if you're not using a Document View architecture. If there is a lot of data, you can construct a class to hold the data, then add an instance as a member variable to the CWinApp in your project.
Another option, which I don't recommend but I have seen, is to have the dialogs themselves as member variables in the CWinApp, and then each dialog can reference the other. Basically, the user clicks 'ok', but then the dialog disappears, but is not deleted. This means all the data they entered is still accessable via the dialog variable.
There are a ton of ways to share data between dialogs. You may need to be more specific about your needs.
Store it in a global variable.
Store it in thread local storage (TLS).
Have one Dialog send a window message via SendMessage() or PostMessage().
Things get more complicated from there.