3 replies to this topic

[Aurioch]

Hello again everyone

I've been silent for last few months and stopped my project due to various things (one of them becoming lazy after getting stuck at one point).
Few days ago I resumed working on it... and oh boy, working(!) features are starting to snowball one after another. Now, while progress is going on, I started to think about future improvements and several (higher level) questions appeared. Done with C# + XNA.

Please ask if you need any code, I currently don't know what to offer except for whole project. Also ask if there is anything unclear or that is not easily understandable, it's a bit hard to put in words what I exactly want.

This is how it looks currently:



Summary: metal tiles (and currently bricks) are indestructible, water is unpassable by tank but bullets fly over it, grass obstructs vision, blue tanks are AI controlled opponents, orange and green tanks are Player 1 and Player 2 respectively, 2 collided bullets disappear, non-allied tanks are destroyed when hit by allied bullet and instantly respawned.
Moving is restricted to 4 directions only; tiles and hitbox' are simple rectangles (a*a for tile and tank, a*b for bullet). Tiles and tanks with their bullets have their own separate class; each type of tile and tanks are stored into separate arrays.

So, the questions are:

1) Well, this one was quite hard for me to put into words. I already rewrote most of the code once (moved tanks and tiles to separate classes etc) and apparently I'll need to do it again - better right now white it isn't cluttered. Are there some tips on improving interactions between elements, adding new classes, detecting useless/redundant code etc. - in short, tips for writing a good code? I want to make that this project performs efficiently while having as much readable and adaptable code as possible.

For example, how can this:

// Definitions
public void MoveTank(bool HorAxis, int direction, bool cancel);
bool Collision(Rectangle Object, bool Projectile, string Direction, bool playerOwned);

if (Keyboard.GetState().IsKeyDown(Keys.Left))
{
   Tanks[0].MoveTank(true, -1, false);
   if (Collision(Tanks[0].TankHitbox, false, "Left", true)) Tanks[0].MoveTank(true, 1, true);
}
else if (Keyboard.GetState().IsKeyDown(Keys.Right))
{
   Tanks[0].MoveTank(true, 1, false);
	if (Collision(Tanks[0].TankHitbox, false, "Right", true)) Tanks[0].MoveTank(true, -1, true);
}
else if (Keyboard.GetState().IsKeyDown(Keys.Up))
{
	Tanks[0].MoveTank(false, -1, false);
	 if (Collision(Tanks[0].TankHitbox, false, "Up", true)) Tanks[0].MoveTank(false, 1, true);
}
else if (Keyboard.GetState().IsKeyDown(Keys.Down))
{
	 Tanks[0].MoveTank(false, 1, false);
	 if (Collision(Tanks[0].TankHitbox, false, "Down", true)) Tanks[0].MoveTank(false, -1, true);
}
		  
if ((Keyboard.GetState().IsKeyDown(Keys.Enter)) && (Tanks[0].BulletLaunched == false))
{
	 Tanks[0].LaunchBullet();
}

be rewritten into something better and more clear? (Answer on my mind: using switch instead of multiple if..else)

2) Can you recommend me some AI algorithms which could be useful for this? Current one is somewhat recreated by observing original NES game of the same name (some people may better know it under name of Tanks) which still needs to be fine tuned. It uses chance system of changing directions (almost 100% chance to keep current one, if collided with something selects between other 3 directions equally) which gives somewhat chaotic movement.

3) I need to implement destructible brick wall. My idea is to split a tile hitbox into 16 equal pieces and process collision with 2 or 3 closest adjactent pieces. Is that good solution, will it tax processing power and memory and do you have other suggestions?

Thank you very much for reading

Edited by Aurioch, 15 October 2012 - 07:21 PM.

[Aurioch]

OK, shameless bump.

This time I have more concrect questions. I hope that someone can answer, either with idea, pseudocode or C# code.

For questions 2 and 3, I provided source code. I hope it is readable enough :/ Comments about code appreciated.

1) I plan to add proper main menu screen, game over screen etc. I've downloaded Microsoft's Game State Manager project and currently I'm examining it, but can still someone tell me general idea about it? It WILL take some time until I get a hang how to execute it from Microsoft's code :/

2) In my own class, can I somehow access declared variable of another class without passing it by reference? To be more precise (check source code), I'd like to update status of one of the Tanks declared in main class from my Player class, calling Collision method from Game1 class. Should I declare new variable of class Game1 inside Player class to handle that?

3) How (if possible) can I save some settings (like keyboard keys for controlling tanks) without using .txt file?

Also, I offered current version of the game for playing Feedback is appreciated. Is the game fun/good in its current state?
Also, you'll notice level1.txt in folder. Try editing a level a little with Notepad.

There are 2 problems with it:

• On Victory and Game Over, it's unable to restart (don't know how to perform it. Call Game1.Initialize again?). To restart, simply run whole program again.
• ... after short thinking, I decided to not tell about this one. Just know that I know about it and I've fixed it already. See what happens when one player runs out of lives.

Also, for test purposes, F1 and F2 has their own functions as well. Just use them before one of players loses all his lives.

Attached Files

•  Battle City source.zip   7.46K   28 downloads
•  Battle City.zip   701.6K   41 downloads

[j-locke]

This is without having checked out your source code yet, so bear with me.

1. Game states handled like MS's Game State Manager are based on the object-oriented programming concept polymorphism. It allows you to create a base class (GameScreen) and then build a manager that knows how to use GameScreens. Each of your screens (MainMenuScreen, GameOverScreen, etc) inherit from GameScreen. What this allows is for your manager to be capable of managing these screens even though it knows very little about the inner details of them. The manager doesn't care what each of these screens does, as long as it has the pieces (methods) that the manager expects.

This idea allows the manager to have a list (or any grouping or collection) of GameScreens and know that it can call certain methods (because the fact that they either ARE a GameScreen or INHERIT from a GameScreen (which means they are a GameScreen)) means that they provide an implementation of the methods in GameScreen (they may have a default implementation provided by GameScreen itself or they may provide their own implementation). So even without knowing anything about, for example, your GameOverScreen, the manager knows that it can call .Update() or .IsActive() on it because to be in this listing it either is a GameScreen or inherits from one.

Getting a good grasp of polymorphism is a big leg up in understanding the concept(s) involved there.

2. There are ways for you to get access to the variables of another class. Exactly HOW it should be done is more a question of design. You should not create a Game1 variable in the Player class. A Player shouldn't need to have a Game1 to function. Your example mentions handling collision. That is function that would be better handled in your Game1 class (the class that knows about the players and the enemies; the things that can collide) than in your Player class. Inside both the Tank class and Player class, you could have a method named something like .GetCollisionRectangle() that returns a rectangle that tells what area of the world or game board that that Player or Tank is currently occupying. Then the game could check those collision rectangles to determine if there is a collision.

3. In order to save settings between game play sessions, you will have to persist or serialize that information somehow. Be that in a .txt file or a database or .xml file or .json or whatever other format you'd like to use or make up. But as for the base idea, yes, you have to save that information out to somewhere when/before the user quits the game and then load it back in when the game starts back up.

As I mentioned before, I haven't downloaded yet so I can't provide any feedback on the game's current state.

Good luck.

[Aurioch]

Thanks for answers

For 2 and 3, yeah, I already implemented that (or plan to implement in case of saving settings), I was just wondering if there's better way to do it.

About Game state management, I was examining Microsoft's example with having Your explanation in mind, so, if I understand correctly, I need to do this:

• Create base ScreenManager class based on DrawableGameComponent which will have a list of GameScreens and take care of proper updating
• Create abstract GameScreen class with appopriate properties and overridable methods which will be used as a basis for all screens
• Create a new class for each part of the game, inherit GameScreen class and override its methods as fits
• In main Game, initialize ScreenManager and pre-load everything needed

So much work XD I'll need about a week to make it work... after that, adding new game screens should be easy :/ I even wonder if I should start new project and just copy what I can into that new project.
Oh well, time to study more on my own since I won't learn about this on college :/