We want a chair class for a game.
How can we create this class so that it can work in another game too?
And by considering the solid principles.
Imagine for example, that we have 2 games: one is a poker game, another is a grand theft auto like game. In the poker game the class should have an id, playersited() : player , state : full , empty , reserved. I can think of these properties right now. But in the second game, the chair doesn't necessary need an id or a playersited() function. So how can I design this class that can be reused in another games?
You are looking for a generic game object that you could reuse in different games, but which might have different properties and different functions depending on the game.
Simple UML answer
If you're only looking at it from the UML perspective only, this design issue is simple: draw a class GameObject, put in it the properties and operations that you want to be common. Then in the model of your different games, just create a a specialisation using inheritance: PokerObject and GrandCloneObject in which you'd add the game specific properties and operations.
But this apparent simplicity would hide a lot of difficult points when you start to design links with other classes (reusable or not), and even more when you start to look at their interactions.
Limitations of such a generic design
In addition you want a SOLID design. The LSP will then reduce the reusability by forcing you to keep the reusable interaction between objects to rely only on common part.
If only 10% of the design is then really reusable in the end, and 90% is game specific, you'll gain no advantage and just make the code more complex by splitting classes artificially. Here I'd joint #kigiri's comment: "JUST DON'T"
A better approach
But if you're looking for is something really reusable at a higher scale, there is a solution if you look not at a Chair, "Weapon", "Item", but at a higher level of abstraction.
And here, I can only recommend you to read Mike McShaffry's Game Coding Complete book, that will introduce you a very powerful architectural pattern called the Entity Component System.
The Idea is to abandon deeply nested class hierarchies wiht very specific classes, but prefer a very flat model with:
Entities: these are the main objects used in the game, whatever the game is
Components: these are owned by the Entities, and represent either properties that an entity can have (e.g. LivePoints, Force, ...), or behaviors that the Entity shall have (e.g. renderFixedObject, soundWhenClicked, etc..).
This design allows to develop highly reusable objects allowing to add game specific components on the top of reusable entities and components.
Related
So, I have designed a use case for a student online system. The issue is that some of my base cases are subdivided into many included cases. For instance, to generate marksheet as a staff, my included use cases are: select student, select course, select module, select semester
In my class diagram, should i have methods for all of the smaller use cases or just the main one like generateMarksheet?
In short
No, that's not how it works.
Some more details
There is no direct mapping in general
Use-cases are about the requirements from a user perspective. So it's about the problems to solve. Typically they represent high level goals for the user such as Manage students or Subscribe to courses.
The classes of your system are about a technical solution that meet these requirements. In general however, there is no direct mapping as you describe: the behavior of the system emerge from the interaction between many classes within the system.
There are some methods to link both worlds
If you want a link between both worlds, you may follow the unified process that was promoted by the founding fathers of UML:
You start with your use-cases
You create an ECB class model for the analysis, in which you show a control class for every single use case, a boundary class for every association between a use case and an actor, and an entity class for every domain object that you can derive from the narrative.
You then think a little more about boundaries and controls, to see if there are some overlaps, or even reuse.
Then you think of designing your system. But the level of detail will be much higher. You'll end up mapping your own solution classes to the analysis classes for the purpose of traceability: for every class you can find back the use-case(s) to which it relates. And conversely.
But this approach has lost traction in an agile context. And also because solution design is often heavily influenced by architectural models chosen (such as MVP, MVVM, clean architecture,...) and these have a different logic than ECB (despite some apparent and misleading similarities), so that this analysis step is not adding sufficient value.
Morover, agile methods try to avoid a big up-front analysis that is required for a rigorous ECB approach.
I am designing my game with Entity/Component concepts of GameplayKit in iOS 9, for ShootComponent, should define bullet/missile as Entity?
Reason for Yes:
separate logic from its parent, e.g. playerTank or enemyTank;
if not, TankEntity need distinguish whether its bullet collide with other Entities or itself.
Reason for No:
it is not actual entity in logic world, which is fired by my tank or enemy turret;
bullet always be shot and disappeared, so game need add/remove it now and then;
For your comments pls.
Finally decided to define bullet/missile as entity, so it acts as entity in contact test, rendering and other components.
I would have add it as a component for the entity using it.
So you will be able to make any entity fire bullet or missile.
Keep in mind that your entity should only act as a simple reference with no logic in it.
First lets read Adam Martins original description of his terms. It appears Apple got the idea of entities and components from Martin:
Entity: The entity is a general-purpose object. Usually, it only consists of a unique id.
Component: the raw data for one aspect of the object, and how it interacts with the world.
System: "Each System runs continuously (as though each System had its own private thread) and performs global actions on every Entity that possesses a Component or Components that match that Systems query."
Martin is just defining terms for doing compositional design, which is an alternative to inheritance that is more recombinable and flexible.
So entities are what you might recognize as instances of a class, but classes have been stripped of all their data and methods, which has been moved out into components - and the entities just delegate to the components.
So your missile... it would be an instance of a class in normal OO terms - an object, right? And a missile can behave in a variety of ways... it can seek out an enemy, it can fly straight ahead, it can speed up, etc. It also has properties that indicate if it's hit an enemy, properties for its total damage, health, and so on.
So the missile is an entity while these various methods / data would be components of the missile entity.
Martins approach is interesting, and there hasn't been as much focus on compositional design as there has been OO (for what reason I don't really know), so I can see why Apple would adopt it for a game framework like this.
But his ideas don't seem very well fleshed out. For example, usually in compositional design there is a delegation hierarchy, where objects will keep delegating up a chain until some data or method is found. At the top there's one meta-object that everything delegates to. In this way objects are both components and entities - they act as both the delegating and the delegated to. But Martins terms don't support this... his model is flat - there are only entities, and then components that can be added to them, but no delegation between entities and no meta-object.
Maybe he felt this flat design was appropriate for game development. I have my doubts... you seem to want some kind of hierarchical structure of objects. I would look for a way to mix in inheritance, or setup some kind of custom delegation hierarchy where objects could act as both entities and components. You might look to see if this is possible within that framework, or if it isn't just write your own.
I'm starting to develop a board game in C++ using OpenGL.
Before starting, I want to draw the UML diagram, as shown bellow.
The game has:
A board that contains a desktop, a footer and the points of both players to show.
Pieces to put on the board
Followers (soldiers)
Mouse events
A set of rules that the players must obay in order to play
Something like The Risk, of Monopoly, etc
I'm not an expert in UML, so by looking at what I've written so far, do you think the UML (arrows and relations) is accurate with the description?
What would you change, and why?
Hard to tell without knowing the game (use case). Generally you seem to over-use aggregation. Also I miss the basic properties/methods of the single classes. Those are general observations.
Some detail observations:
The model does not differentiate between the game and the technology.
What for it this Object? It seems rather pointless. You'd better be off designing the game logic first: what are those Pieces and what can they do? Think of a better name (my dictionary suggests Token, Meeple, PlayingPiece). Things are only what their name is!
What are the Rules? I don't see any rule class at all.
Create a 2nd diagram/layer where you can concentrate on technology in a later stage.
I'm modeling an app which will let users look for real estate properties. So it's going to be a website where users will be able to look for rentals and sales on houses, flats, castles, grounds, shops, parkings, offices. According to that, I'm hesitating in the class diagram. Should I generalize all the type of real estate properties, written above, from the class RealEstateProperty or should I just associate to it a class TypeOfRealEstate, knowing that the type "Ground" for example can be as well a real estate property as the ground of a property like a House or a Castle. Also a parking can be a real estate property as well as a parking of a House.
Anyone has an idea of what's the best way to do that ? Thanks in advance.
It depends of what features of different RealEstates your system has to implement. A class's features include attributes, methods and associations.
If all your potential RealEstates have same features, for example ID, type, price, date and responible agent, and you don't need to firther differenciate among them, than the associated type will do the work. Model RealEstateType as an Enum (or even class, if you expect to add new types) and associate it to a single RealEstate class.
If different RealEstates, on the another extreme, need to have different features, you will need to inherit those from the base abstract class. For example, Ground have an attribute "area", while building has "number of floors". Even methods can be different, or associations.
Following your example, you would like to link Ground to House. This is much cleaner in the second version - just an association between Ground and House class. In one-class version, you would have to link the RealEstate with itself and add spacial restrictopns (very "ugly" design).
In summary, try to think about the features of different RealEstates and make your RealEstate hierarchy based on their differences.
You can end up with a single class or several dozens of them. :) Try to keep this hierarchy as simple as possible (less classes), but enough to mark their different features clarly.
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.