I have created an online game which is written in object oriented programming and node.js . after clustering I decided to make these clusters stateless and save game objects in redis . How can that be done with keeping my game Class untouched ? Simply to save Game Objects with it's methods and props in redis and use those game object methods to update and read those game objects properties . I Have read about ORM but I guess i have to change my game Class to acheive this?
Related
I would like to know the actual representations of game objects in Unity in terms of OOP languages.
I'll state this sentence and I want to know whether it's correct or not:
The game object that is found as a part of the hierarchy of Unity is nothing but a single object whose field members are variables that are referring to yet other objects that are called "components"
A second question:
Supposing this was correct, that these objects are actual objects in terms of OOP i.e. they are "instances of classes" , when do they get instantiated and when are they garbage collected ( usually ) ?
The main building blocks of Unity games are "GameObjects" and they work according to the "object composition" which is one object-oriented programming principle. However, in my opinion you shouldn't consider them as classes which can be derived/inherited/overrided but like containers or groups for classes written in C# or JS working together in one, physical object in OO way.
GameObject are instantiated during scene launch or when you try to instantiate them via code, for example:
Instantiate(myGameObject, Vector3.zero, Quaternion.identity);
They are garbage collected when you:
switch to another scene
quit game/application
call Destroy(instantiatedGameObject);
I want to use SQLite database to store the scores of the games created with cocos2D framework. I use a singleton class controller called GameManager to control my application. To load the Scores I have a ScoreScene class which inherits CCScene and that class is called from GameManager, then when ScoreScene loads and from ScoreScene ScoreLayer class is called which inherits CCLayer class. I temporarily stored the score variable in GameManager and it is accessed from everywhere.
Now please help me and point out any weaknesses in my design and also help me in how I can implement SQLite database and store the score from GameManager class to the database.
The GameManager singleton seems to take the responsibility of managing common data and actions globally, right? Just be careful if there are multi-threading cases. I think your design is OK to use.
For SQLite part, you can refer to Apple official documentations if you want to use it via Core Data:
Core Data Programming Guide: Persistent Store Features
Core Data Programming Guide: Using Persistent Stores
Or you can use it via C interface directly. Some references:
http://klanguedoc.hubpages.com/hub/Tutorial-on-Creating-an-IOS-5-SQLite-Database-Application-IOS-5-SQLite
Use CoreData or SQLite on iPhone?
I just got into using singletons and I just want to evaluate if I'm using it correctly. I've read that singletons are evil. I've only started with game dev't so things like unit testing and multithreading doesn't reach me yet.
I separated the logic of my game into different modules. Each module has a singleton and non-singleton classes (eg. data model). I'm using the singleton as a mediator so it can interact with other modules. This allows me to work with other people since it's in manageable pieces and I only need to expose the helper methods of my singleton. He doesn't need to know how I implemented it.
Am I doing the right thing?
Examples:
In a traditional japanese SRPG game (like FFTactics), the cells/grid for the tilemap has its own module. The character interacts with the singleton of this module.
All my sprites are generated by an AssetManager (a singleton) which autoscales the sprite depending on the resolution-availability and resolution of the device. This is done just by a calling a method in the singleton.
I definitely don't agree that singletons are evil. They are sometimes overused perhaps but on some occasions are just perfect for the job. In some applications it makes sense to have some kind of general data manager. The singleton pattern is used extensively in the SDK itself (app delegates, shared managers, default centers and so on). Most often these are not "pure" singletons, as in you can access a shared instance but can also create new instances if necessary.
The question you need to ask yourself is whether it would be useful to have access to a single instance of a data manager from anywhere at anytime, if it isn't then a singleton is probably not needed. If you are going to be using singletons in multi-threaded environments however, you do need to worry about race conditions (can one thread modify a resource while another is accessing it), the documentation has good explanations on how best to achieve this in Cocoa.
You could easily do that with an instance too.
Let's say you have a GameMap class and a Tile class. The GameMap represents a 2 dimension grid of Tile objects. (This is your FFTactics example).
GameMap *gameMap = [[GameMap alloc] init];
NSArray *theTiles = gameMap.tiles;
The instance of the GameMap owns the grid of tiles, and creates the tiles when the game map is created. No singleton needed.
You may say "but I only have one GameMap at a time, what's the big deal?". What about loading saved games, or loading new levels? Well that becomes as easy as:
// In whatever class object owns the game map
self.gameMap = [[GameMap alloc] initWithSaveData:saveData];
In conclusion, create an instance of a class that has code to manage other instances of things. Keep as little global as possible and your code will be more scalable and maintainable.
I’m fairly new to OO. If I have two classes A and B that need to exchange data, or call each other’s methods, I need to be able to access an instance of class B from class A. Should I maintain the address of the instance object in a global variable? Should I appoint a (singleton) master class, and make (pointers to) instances of A and B properties of the master class? (AppDelegate comes to mind.)
Is there a straightforward by-the-book way to implement this? Somehow I‘m missing some "best practice" here. I’ve looked through Apple's examples, but didn't find an answer.
EDIT: Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
We're talking about an Audio Player here. 1. When the user selects a song, the UI displays its waveform by creating a viewController which creates the appropriate view. 2. When the user hits play, the UI displays a timeline while the song is playing by overlaying a new view over the waveform. Now, the latter view needs some info from the waveform display viewController. Right now, I'm storing a pointer to the viewController in an instance variable of my appDelegate. This works, but feels extremely strange.
Should I outsource the info that is needed by both classes to some third entity that every class can access easily?
Classes aren't simply departments of code. They are templates for the creation of objects, which you should think of as actors in your program, doing things within their areas of responsibility (which you define—you decide what each object does) and interacting with each other.
While you can handle a class as you would an object, classes generally do not talk to each other. Most of the time, you will create and use instances of the classes—which is what we normally mean by “objects”—and have those talking to each other. One object sends another a message, telling the receiver to do something or changing one of the receiver's properties. These messages are the interactions between your program's objects.
Those weird expressions in the square brackets are message expressions. Nearly everything you'll do with a class or object will involve one or more messages. You can send messages to classes the same as to objects, and classes can send messages just as objects can.
In Cocoa and Cocoa Touch, you typically have model objects, view objects, controller objects, data objects (such as NSString, NS/UIImage, and NSURL), and helper objects (such as NSFileManager). The classes you'll write for your application will mainly be model, view, and controller objects (MVC). The model represents (models) what the user will see themselves manipulating; the view displays the model to the user; the controller implements logic and makes sure the model gets saved to and loaded from persistent storage.
For more information, see Object-Oriented Programming in Objective-C and the Cocoa Fundamentals Guide.
Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
Controllers create and load the model, and load the views, and pass the model to the view for display. Certain controllers may also create other controllers.
It's good to keep a straightforward tree-like graph of ownership from a single root of your program—typically the application object—down through controllers to leaf objects in the models and views. If two objects own each other, that's a problem. If an object is not owned by anything outside of its own class (a singleton), that's usually a problem as well—a sign you need to think some more about where that code belongs. (Helper objects are the main exception; most of those are singletons. Again, see NSFileManager for an example. But they are few and far between.)
Further situation analysis require more information. At first place you should more specify the relation between classes and what exactly do you mean by exchanging data.
Singletons should be generally avoided. If you want to exchange information it is usually sufficient to provide for example instance of the class A to the instance of the class B by some method or constructor. The instance of B is then capable of calling public methods (and accessing public properties) of the instance of A.
A little bit of "best practices" can be learn by searching up "Design Patterns".
You should decide if one class can be an object of another class (encapsulation), or if one class can inherit from the other class (inheritance). If neither of these is an option, then maybe you could make one class (or some of its members) static?
Thanks for your contributions. Additionally, I found information on this page very useful. It lays out MCV considerations for cocoa in a hands-on way and practical language.
Following SRP and KISS principle I designed an object with properties only, but I need methods to work with the objects. What is the best way to separate entity object data and entity set object methods?
Currently I created the following objects:
Pet Entity object
Attribute Name
Attribute Age
Pet Entity Set object
List of Pet objects
Pet Engine object
Method LoadPets of Pet Entity Set
Method GetPetByName of Pet Entity
Method GetPetsByAge of Pet Entity Set
Is this the best way to design the objects?
I'm developing in .net
Thanks.
You've implemented the Anemic Domain Model antipattern. Classes should implement the methods that they need, that doesn't break SRP, but IMHO SRP is way over rated anyway.
The general idea is to keep the methods close to the data they operate on. The construct that combines data and operations is known as a class.
Seriously, why do you think it's a good idea to separate the data from the operations? That's the opposite direction to where we've been going for decades!
Use a functional language with support for pattern matching. Since you're on .net, F# is the obvious choice.
This works well for message oriented systems where you have mostly stateless nodes which transform messages then pass messages to other nodes. In these scenarios, you don't care about mutating the data in the message nor about the identity of message; you care about advancing the processing in each node and sending out more messages.
You're not doing object oriented design, and object oriented languages do not support this paradigm well - they tie a mutable bag of data to an object with identity, rather than creating a reactive system of message transformers.
In effect, this requires you to take the dual of the system - the messages in a reactive system correspond to the method and arguments in object oriented systems. Roughly, the state which is in the fields of the objects of an OO program is kept the call stack of a reactive program, and the state which is the call stack of the OO program is kept in the fields of the messages in the reactive program.