Jump to content
  • Advertisement
Sign in to follow this  

Class diagram for tank game: feedback please

This topic is 2911 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello Experts,

I am working on a game for the iPhone / iPad (I would like make it for android in the future). I would really appreciate some input on two aspects: the game idea, and my class diagram that I have written.

The game is a 2d side scroller where you control a tank. The player can build their tank by finding various blocks on the ground or blowing them off enemy tanks. There are dozens of different types of blocks you can pick and the player can customize their fighting style by using these blocks. The goal of the game is to destroy enemy tanks and reach the end of the level. The tanks can be outfitted with armor, weapons, and special blocks. If the cockpit of the tank is destroyed the player loses (and if you destroy an enemy cockpit he loses) so you want to protect that while attacking the enemy tank. The weapons can be ordered to attack a certain block on an enemy tank; this makes the game more strategic than action oriented. You can attack the cockpit, destroy the enemy's weapons, destroy the treads, or take out the generators (which shut down all nearby weapons).

The game will be split into several stages where the player fights different tanks (sometimes more than one). Occasionally the player will run into a town where he can buy and sell blocks to further improve his tank.

I think this game will be very fun on iOS. What are your initial thoughts?

Class Diagram:
I wrote up a class diagram that will be the blueprint of the game. I've only created two games before; I wasted a lot of time and made many errors because I didn't plan. This is my first project where I made a class diagram so I wanted some input on it. I'm sure it can be improved and I would love to have some constructive criticism.


The green line indicates inheritance.
The black line indicates ownership. The classes on top own the classes underneath
I hope it's clear enough

Thank you for reading

Share this post

Link to post
Share on other sites
Well, for starters you're going to want more than a class diagram. Try tracing out paths the player can take through the menus and the game itself.

About the class diagram itself, you seem to have weapon types: gun, turret, ram, etc... as independent classes. I'm not seeing that they have any new functionality or data. If that's the case they shouldn't be classes at all, rather they should be instances of the Weapon class. You also have values of .3, .2 assigned to fields that specify an integer as a data type. Integers can't handle decimal numbers, those should be floats or doubles.

For the MobileArmor class, you have blockGrid as a type double array. On face value I read that as being a one dimensional array of doubles, it would be better to call it a 2d array, or an array(array(whatevers)), showing that it's an array that contains arrays that contain whatevers. In general it would be more helpful for you to specify what the expected contents of each array are.

For Level.blocks the datatype is specified as an array, but I presume that the number of blocks on the field of play are going to change often throughout the game, and (at least from my understanding) you are never going to need to access those blocks randomly, rather iterate through the whole collection to draw them or see which are close enough for a player to pick up. If that's true you would be better served using a linked list or similarly dynamic data structure. Arrays don't lend themselves to resizing very well.

That's all I can think of for now, hope it helps.

Share this post

Link to post
Share on other sites
Ugh... The diagram is a monster one :)

There are two things, design (game) doc and tech doc. These are separate things. In design doc you put the things about the feelings of the game, balance, players impression. In the tech doc you put how to code it. There is no point putting things like damage of a weapon or amount of HP in tech doc. Programmers don't needed it, it is not important to them, it can be changed anytime without any coding.

I strongly recommend spliting the designer and coder part in your doc (even if you are both designer and a coder).

And then post the design doc here and the tech doc in the programmers board (designers won't give you much input on coding dilemmas).

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!