Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have drawn usecase, activity and class diagrams for “Crafting System” for my game.
I am bit confident in activity and use case diagrams but I doubt in class diagrams. Do you find any mistakes in it? or suggest any improvements?
Crafting Mechanic:
Crafter could be either an NPC or building thorough which player interacts to craft. Upon clicking on the crafter a window will be opened.
Hmm. If we look at a crafting process in a very abstract way this may work. What I’d miss here are the directional (aka one-sided) dependencies in the class diagram; for example the crafting process may not now anything about the crafter. Same goes for the items.
In a more detailed look at this you will have to split up some compound classes. For example, the crafting process is likely going to be split into at least two classes, if not even more. The reason behind this is that you’d like to keep the data (“recipe”) split from the actual process. This will not only make things easier with the actual implementation, but also gives you a means to provide actual recipe items to the player.
Which brings me to another point: If you have some kind of item tree, your ConsumableItem and CraftableItem are more like interfaces with the same parent. Infact, I honestly fail to see why you would make any difference between these two, because you may have mixed up classes and roles here (which are described differently in UML).