Game Design UML, Looking for suggestions

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
So I took a stab at a puzzle game based on Pokemon puzzle league
I got it working, but i thought it was poorly designed so i changed it. a week later I got it working again
But thought the design was poor again.

So I stayed up last night till 2AM working out all of my concerns. But before i recode it again
I am looking for feed back on the UML.

Any Suggestions would be great. Or thoughts.

Thanks

Note: the diamond means theirs one instance of it) and in all cases i made them private.
ex: Game has one instance of Keyboard called keyboard (private)

Updated PDF (Again)
 

Attachments

  • PuzzleJS_v1-3-1.pdf
    318.5 KB · Views: 625
Last edited:

tom_mai78101

The Helper Connoisseur / Ex-MineCraft Host
Staff member
Reaction score
1,632
For one thing, please make clear of your UMLs where the head of the arrows (lines with diamond-shaped heads) are pointing exactly on the boxes. There are some arrows drawn confusingly, such as one where the line goes through the diamond. Which direction is the arrow going? And there are some arrows whose heads are perpendicular with the side of the box. Does that mean arrows, whose heads are pointing vertically, are different from the arrows pointing horizontally? Or they are on the same path?

For the DataTypes, please put a short description for each of them.

A shortened list of some thoughts. There may be more, but I'll wait until you update your UML:
  • What is BlockAttacks? "Attacks" is a verb, or a plural noun?
  • What does Effect do? I do not see anything that Effects can be used on
  • What is the purpose of GravityInstance? I know puzzles and gravity go together, but for what purpose?
And show what a sample puzzle looks like, so at least those who are looking at this PDF can know what to expect in order to give you the feedback you need.
 
Last edited:

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
Thanks for the feed back!
Updated UML
http://puzzeljs.azurewebsites.net/ (Space to switch blocks) This is a very old version but only stable one at the moment.

Clarification:
  • GravityInstance
    • Updated UML
  • Effect
    • Good Catch
    • Updated UML
  • BlockAttacks
    • Added Functions for Block Attacks
    • This was never thought though before as its a phase 2. So I mostly flushed it out. Expect for how there handled in the game file. That will come at later date.
    • The game is based on Pokemon puzzle league and should play in nearly every way the same.
Please Advice.
 

Accname

2D-Graphics enthusiast
Reaction score
1,462
First of all, the way you present the diagrams is not a good format. Try an image instead of a PDF to use more screen space.

Now to your diagrams: They show too much stuff. Stuff that isnt needed. You need to think about your intended audience and the information you try to convey. Do we really need to know that you have 6 private variables of type boolean in your Controller that are used for various buttons? Nobody is going to read that. The information is overwhelming and so we are not even going to bother. Keep it precise. Think about what kind of feedback you want to get and what information is important for us. If you want feedback on your class strcture then only show us your classes.

Next up: Naming conventions.
How you name your classes is certainly up to you and you should give them a name that will make YOU understand what these classes are supposed to be doing. But! If you want outside help it is important to stick to naming conventions. This will help others to understand your code more quickly. Conformity carries additional information. If everybody sticks to the same (or a similar) naming convention, there will be fewer misunderstandings and less confusion.
For example: After looking at your architecture it appears to me that you are trying to implement a form of MVC (Link: https://en.wikipedia.org/wiki/Model–view–controller) concept where you divide your classes in View (audiovisual representation + IO + configuration), Control (a bridge between user input and application logic) and Model (the data, game rules, game logic, etc). This is a good idea and often very helpful for simpler games like these.
However, your naming makes this architecture hard to see. Your "Game" class is something one would expect to find in the Model level, but here it is the central piece of the View level tying Asset-Management, Renderers and IO together. Your "Controller" class is not part of the Control level but instead an IO class and also part of the View. Your "Puzzle" class is some kind of fat Control and Model hybrid (which could also be interpreted as the Model-View-Adapter pattern).

I hope this can help you a little bit.
 

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
First of all, the way you present the diagrams is not a good format. Try an image instead of a PDF to use more screen space.

Now to your diagrams: They show too much stuff. Stuff that isnt needed. You need to think about your intended audience and the information you try to convey. Do we really need to know that you have 6 private variables of type boolean in your Controller that are used for various buttons? Nobody is going to read that. The information is overwhelming and so we are not even going to bother. Keep it precise. Think about what kind of feedback you want to get and what information is important for us. If you want feedback on your class strcture then only show us your classes.

Next up: Naming conventions.
How you name your classes is certainly up to you and you should give them a name that will make YOU understand what these classes are supposed to be doing. But! If you want outside help it is important to stick to naming conventions. This will help others to understand your code more quickly. Conformity carries additional information. If everybody sticks to the same (or a similar) naming convention, there will be fewer misunderstandings and less confusion.
For example: After looking at your architecture it appears to me that you are trying to implement a form of MVC (Link: https://en.wikipedia.org/wiki/Model–view–controller) concept where you divide your classes in View (audiovisual representation + IO + configuration), Control (a bridge between user input and application logic) and Model (the data, game rules, game logic, etc). This is a good idea and often very helpful for simpler games like these.
However, your naming makes this architecture hard to see. Your "Game" class is something one would expect to find in the Model level, but here it is the central piece of the View level tying Asset-Management, Renderers and IO together. Your "Controller" class is not part of the Control level but instead an IO class and also part of the View. Your "Puzzle" class is some kind of fat Control and Model hybrid (which could also be interpreted as the Model-View-Adapter pattern).

I hope this can help you a little bit.

"Now to your diagrams: They show too much stuff.... Stuff that isnt needed. intended audience"
I Agree i still want the full spec. but it may make more sense. to not show the private functions in most of these classes, and most of the var are close to meaningless to a user who would read it. My target audience is in employer in a job interview (this is gonna be a key or a project like this in my portfolio)...But that said, I should also be reasonable with this is i want it to be useful.

"Next up: Naming conventions."
I am trying to stick to JavaScript conventions, I will add a lint style checker later on.

"Next up: Naming conventions."
MVC Naming conventions
Keyboard and Controller...I could change it too keyboardController, joystickController
would something like that be better?

MVC- Correct that was my goal
Game = Project
Puzzle = Model
View = Display (should i change display name to View?)
Keyboard and Controller and gameloop = Controller

Hybrid? Do you mean the fact that they can both utilize from the same classes?
I assume your referring to "Renderers and IO together"
Display can only look at the data passed to it and display it. it cant call any other functions.

I see this game loop as my Controller.
I could have a class called something like PuzzleModel
and then puzzle.tick would return it.
and then i would pass PuzzleModel into display. Would that be in improvement?
(Below is current)
Code:
 this._gameLoop = function () {
        setTimeout(function () {
            requestAnimationFrame(this._gameLoop);
            this._keyboard.run(); //Has access to puzzle public functions
            this._controller.run(); //Has access to puzzle public functions
            this._puzzle.tick();
            this._display.render(this._puzzle.getBlocks(), this._puzzle.getSelector(), this._puzzle.getBlockInc(), this._puzzle.getScore(), this._puzzle.getLevel());

            this._stats.update();
        }.bind(this), this._interval);
    }.bind(this);

It sounds like It would be much more helpful if i put the code up. In process of changing to this uml, in the code. Ill shove it on gitup tomorrow or Saturday.

Thanks for the feed back gave me alot to think about.

edit*

"central piece of the View level tying Asset-Management, Renderers and IO together."

I saw game as a controller. but your right it does more then control it loads up all the assets and holds the higher level data.


Game
  • Model
    • Puzzle
    • Images
  • View
    • Display //Only has access to Images
  • Controller
    • keyboardController
    • joystickController
Game has access to drive these in a game loop.
Is the issue, that Game...holds all the stuff together in one together package?
I still dont get it... hmm ill reread a few more times. maybe after i sleep ill understand more


I looked at the image on wikiepida and its not how i remember mvc...

I thought it was... Controller calls model does stuff, gets data back, controller then calls view and sends it the data. I styled it much like ASP.net MVC with out the naming convenstions
 
Last edited:

Accname

2D-Graphics enthusiast
Reaction score
1,462
I think you are mixing something up about the MVC pattern. The View is not just the rendering. Your Display class is of course part of the View, but input, file loading, sounds, game loops, networking and all that stuff is ALSO part of the View. The View is everything that is platform dependent. Think of it in the way that Model and Control could be reused in a completely different enviroment and the View is what is needed to play the game on your platform of choice.
For example: When you port your game to the PS4 or the XBox or the Game Boy or any other platform, the View is th only part that you should have to change. Control and Model can work everywhere. Thats the reason why many people dont really know what to put into the Control classes and that is why the Model-View-Adapter pattern is emerging where Control is lost and its functionality is put in parts into the View and in arts into the Model.
What the Control does is tie the Model together and make it easier to use. It can also do some utility functions like Logging, Encoding and Decoding of data (not the actual reading / writing of files, but the interpretation). The Control is often very slim, depending on the Project.

Edit:
Here I made a simple example Class Diagram that shows how some puzzle game could be made. Not necessarily yours. The levels are color coded for your convenience. All green classes belong to the View and do IO, Game Input, Rendering and Asset Management (Images, Sounds, 3D-Models, etc). The Control is blue and defines what comes next (the GamePhase's) and how to encode / decode the files (from UML or binary or whatever is used). The Model is red and contains the game logic, rules, data, etc.
I hope this helps.
ExampleUML.png
 
Last edited:

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
First off Thanks a ton so far.
  • Agree and Understand
    • View Makes Sense. And I will make the change.
    • Reduced View of UML is very helpful Will add one like this in the pdf. (I still want the full uml, but it can just sit at the end, ill add page numbers that focuses)

Ok From here on i am still a little confused is this about right?
  • [View]
    • GameManger [Public]
    • InputManger
      • calls Keyboard and calls JoyStick (maybe better named keyboardController?, even though its part of the view and doenst call game)
      • Determine what "Game Inputs" were pressed [Not key w pressed, or key arrow up pressed, or joypad button 17 pressed], only Up in Input manger
  • [Model]
    • Game
      • Has Public Functions available for controller to call.
  • [Controller]
    • GameControl
      • has stubs to connect to GameManger And Game [This pointless? its just a class that has 2 things in it. I dont understand this]
    • GamePhase
      • Looks at the input received from GameManger and may call a game function here
      • Calls GameControl.Game.Tick()
It doenst make sense that the lose condition is in side of gamePhase does it? all game logic is in game.



Now If I were to swap out the view, the game would still fully function
with no changes needed. Correct?

I am thinking something like this. is this closer to what you are suggesting?
Code:
Project{

var Game
var GameManger
var GameControler

function Setup(){...}
function Tick(){
    GameController.Run()
}

..in another file...
GameController.Run() -> {
 
   if(GameManger.InputManger.LeftClicked)
      Game.Puzzle.Left()
}

Or

..in another file...
GameController.Run() -> {
   if(GameManger.InputManger.LeftClicked)
      Game.Left()
}
}

 

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
I tried to cut it down i felt it was still useful to show all public functions (not counting constructor)
Anyway please advise.

Spent much time trying to understand and improve.
I want to code but i want to make sure i got this figured out right first.
 

Attachments

  • PuzzleJS_v1-3-1.pdf
    318.5 KB · Views: 506

tom_mai78101

The Helper Connoisseur / Ex-MineCraft Host
Staff member
Reaction score
1,632
My target audience is in employer in a job interview.
I'm curious to see how employers would read this. Wouldn't they be concentrating on what functionalities does your game do, or what experiences did you learn from making this game?
 

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
Every Job Interview I have had, before i got there they looked at my online portfolio a link on my resume.

They all looked at every project i put on it, and some downloaded applications. I know this because they talked to me about it.

The Goals of this project are
  • Improve GitHub skills
  • Improve JavaScript skills
  • Improve Design Pattern skills
  • Improve documentation skills
  • Use SignalR In a Project (For networking)
  • Improve resume by having more code they can reviewer
My Most important goal is to make sure next time I go to a interview, that I have a project thats to the best of my ability in my spare time.

Note: I picked JavaScript because i am in my SR year of collage, and my capstone is a game in JavaScript. I have learned a great deal from it, and am only half way. I would like to practice those skills.

"I'm curious to see how employers would read this. Wouldn't they be concentrating on what functionalities does your game do, or what experiences did you learn from making this game?"

I will add it to my online portfilo, with a some info a screen shot and a link to github. as well as the documentation link right there

Its my guess they could care less that I make a game. But they do care, that I have passion, and that they can see how I went about a project. Code > Words

I also realize that there needs polish on the documentation. But I am trying to make sure i got the general setup right. So far the help has been Great.
 
Last edited:

Accname

2D-Graphics enthusiast
Reaction score
1,462
It definitely looks more refined now. Names are better and the roles are more clear. However, you probably already noticed that your Control level is a little bit empty. Of course it might be that your GameController is actually a pretty big class that does important things in which case its fine. But if your controller really is something that could be removed without a big problem you may want to think about abandoning MVC and instead going with the Model-View-Adapter pattern instead. Sometimes you have to realize that a pattern you chose was not the best choice for your given application. The MVC pattern is mostly designed for big application software (or larger games like SC2). A small puzzle game might not need MVC and make its use seem forced. But in the end its your choice.

By the way, in your UML diagram there is an edge from Support to Puzzle that is bugged; it goes through the Support class and makes its methods harder to read.
You might also want to remove those diamond shaped boxes (aggregation) at the end of relations (edges). These usually define a part-of-whole relationship between objects. These relationships are often very very difficult to actually implement and dont really help much. We usually discourage our students from using them. Not saying they are wrong, just that they dont give much additional information, require more knowledge to understand, and are difficult (or impossible depending on programming language) to implement. So to sum it up: not worth it.
 
Last edited:

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
First off, Thank you! This is very helpful.

I think mine is MVA but just mislabeled as I didn't realize whats what it was.
  • Does Model-View-Adapter pattern allow the adapter to send datatype values from the model to the view?
Model. Has a data class called block. and it has row, col, color.
can the adapter, ask the model for blocks, and then pass it to the view? I assume yes (even though it means the view, has to know what a "Block" is, to be able to deal with it)


  • "You might also want to remove those diamond shaped boxes (aggregation) "
Reviewed my HW from my UML class and it looks like when i used Astah some times i used no diamond, some times diamond, and some times filled diamond.

"
Association (Line)
A relationship between the members of two classifiers. For more information, see Properties of associations on UML class diagrams.

Aggregation (Diamond not filled)
An association representing a shared ownership relationship. The Aggregation property of the owner role is set to Shared.

Composition (Diamond filled)
An Association representing a whole-part relationship. The Aggregation property of the owner role is set to Composite.
"

https://msdn.microsoft.com/en-us/library/dd409437.aspx

Association Example
Doesn't implied that the object has in instance of it with in it. only Aggregation and composition do that.
Using the link above as an example, look at menu and order. That shows an association. (neither of them have a var holding an instance of the other)

Aggregation Example
Using the link above, shows that the menu contains a list or an array of menuItems. so it contains a var called menuItems of type list or int.

Composition Example
Using the link above, shows that the order contains a list or an array of orderItems. so it contains a var called orderItems, and it also lets you know that orderItems do not exist on there own, they exist only as a part of Order. (There is more to composition, then my def here, and i do mis use it time to time, so i tend to avoid using it)

This is also how i learned in my UML Class using Astah (http://astah.net/)
I would create uml diragams in class, and it would allow me to export to C#, or java ect. and it would do the same behavior from the link above. (it didn't do anything different between aggregation or composition though, but thats good to know)

So my association in my case between controller, and model is correct as my controller does not hold an instance of it. but there related. (but the uml is out of date, cause i am passing in the an instance to tick, of view and model)

So I could be wrong, I think I got a C in that class but After reviewing i think i am right.
In my case some should be filled diamonds. I was never great at filled vs unfilled even if i know the difference.
You do sound much more knowledgeable on the subject. If you can point my to source that says other wise I am willing to read, and study to make sure i am doing this correct.

  • I change my code to reflect hte uml, and ended up having to make some changes to it, ill update it soon.
Also I am just going to tie in the data types to the diagram instead of have a page full of them , and page full of enums. as many of the data classes, are only used in one class. and never outside of it.

Ill put a link to the source code too after its back in a fully running state. hopefully today. (it will be on github)
 
Last edited:

Accname

2D-Graphics enthusiast
Reaction score
1,462
About UML:
I am not saying your use of the Aggregation is incorrect, but I am saying it might still be better to use plain relations instead. There are 2 main arguments against using the Aggregation: 1) It is very difficult to actually implement it. If you explicitly go for aggregation in your UML diagram one would assume that you put much effort into implementing it too. But implementing Aggregation correctly can be time consuming and difficult depending on the used language. It might also turn out to be a bad idea later on and you restrict yourself unnecessarily. Reason number 2) is that its harder to understand for your audience. If you show the UML diagram to somebody then this person has to understand what a regular relationship is, what an aggregation is, and what the difference is. If the person doesnt know you have to explain it. This takes time during the presentation and distracts from what is actually import. You have to know which level of detail is the correct information for what kind of an audience. If you intend to show this diagram during a job interview then I would argue that this is actually too much information and it reflects rather negatively instead of positively.
Might be that I am wrong though. Perhaps the person interviewing you will know what aggregation is and be positively surprised by you using it. It can go both ways. When we do projects at the university we discourage our students from using Aggregation for exactly these reasons. In case you dont know, I am teaching software developement and programming at my university while I work on my master degree. We do lots of UML and MVC software developement.

About MVC, MVA, etc:
Patterns like MVC and MVA (and all the others) are not all that clearly defined. Its hard to say when to draw the line and stop calling something MVC and start calling it MVA or MVP. There is always people who use it differently. When I look at descriptions about what MVC is on the internet I am sure I am going to find several sources that explain it slightly differently. So it is best to ignore the details (which may differ from source to source) and concentrate on the important things they have in common, namely:
1) Seperation of Concerns - Separating the code into User Interface (View), Application Flow and Monitoring (Control) and Application Logic and Data (Model)
2) Portability and Stability - Being able to port the application to another platform by writing a new View, adding Multi-Threading, Logging or other control mechanisms to the Control or adding additional functionality by augmenting the Model
3) Maintainability - By sticking to a tried and true format with known naming conventions it becomes easier to explain the inner workings of the application to other developers and to continue work on the application after a longer period of time without having to study your old code too much.

I think your current model does that pretty well already. Whenever you are unclear about a design decision just think about these aspects and you are probably going to figure out what the best course of action should be.


On the internet you will often find a graphic like this to describe the MVC pattern:
350px-ModelViewControllerDiagram2.svg.png


But I personally prefer to explain it to my students more like this:
MVC.png

because I think it shows the way in which the levels interact with each other better.
The Model really doesnt interact with either the Control or the View directly. It is supposed to be complete in and of itself. It does its thing without giving a fuck about who is controlling it or using the data it provides.
The Control takes active control of the Model and makes sure it is used correctly. The Control can also do some additional utility tasks that may be useful.
The View is what is interfacing with the OS and the User. It is what you will actually get to see of the application. The View needs to know the Control and the Model to present these to the user. It also has to actively use the Control and Model level (I would personally discourage the View actively using the Model but sometimes it can make sense).
The idea of this is that you can take away the outer layers one by one and the inner layers would still function on their own. Then you can replace the outer layers with different implementations without having to rewrite the inner workings of the Model and/or the Control.

I hope this helps.
 
Last edited:

rover2341

Is riding a roller coaster...Wee!
Reaction score
114
too much information

Understood. And Agree, that if i showed this to my current boss [Not CS Major], or co workers they would be confused. even if i put a key on the top.
I am working on this with two other senior CS majors as ASU, and they were also confused about how uml works.
Key should be useful, and understood quickly.

(More lose in restriction, and can save time coding)
(Higher clarity)
(more text, if i show all public vars)

Original Design Pattern

What I was doing at First (from my first uml Model - ViewController)

Model - ViewController (not sure offical name, but this is pretty much what it was)
* Model
* View And Controller are mixed

Major Difference MVC vs MVA

MVC
* Model can directly call at least one part of the view

MVA
*Model Cant Call View
*View Cant Call Model
*Adapter can pass back data from the model to view (even if its an instance of a data class defined in model)

Final UML (Ill post later today)

1. Puzzle JS Title Page (with image)
2. About
3. Overview [public functions, and public vars only, constructor(s) not shown]
//I may be showing to much on overview, but I think its fine.
Axing the rest of the UML pages.

Final Thoughts

1. Use Design Patterns
2. KISS
3. Showing Less Data, on UML is often more useful.
4. Using more advanced techniques (at least compared to just a line) in uml is often not understood by the audience.

K Thanks a TON.
Ill post the final one here, and the github like later tonight.
I think I got more then enough help from you. I learned alot.
 
Last edited:
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Members online

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top