31 replies to this topic

[Reclusiarch]

Update 8/17/12 : bug fixes...
Update 8/13/12 : lobby screen, chatting, more server debugging...
Update 8/10/12 : networking updates, localized player positions, bullets, and aim tracking with mouse
Update 8/8/12 : changed tanks graphics to something more "cute", add tred animations
Update 8/6/12 : startmenu, gamemenu, simple networking server/client added

programming this in XNA 4.0, I love World of Tanks so much I decided to create my own Tank Game. Sorry, It is not much of a game at the moment only been working on this for a couple of days. Since it is top-down I am thinking the maps will have a topographical "overlay" to show height differences, going up hills will reduce tank speed and going down hills of course will increase it. The 1st priority is checking for line of sight.. right now the tank's target is where ever the mouse is, so I will have to place some dummy tanks in there pretty soon..

Edited by Reclusiarch, Aug 17 2012 - 22:18.

[PTwr]

Which XNA version do you use?

[Reclusiarch]

XNA 4.0.

[Unholy_dude]

y u no use nice code

[PTwr]

In 4.0 there are few new in built shape classes that are useful in collision. As for line of sight, maybe Ray versus rotated Rectangle? Should be possible with just those new classes.

Edited by PTwr, Aug 01 2012 - 08:33.

[_Ruffles_]

[fmbtank]

_Ruffles_, on Aug 01 2012 - 08:39, said:

lol & +1

[PANTHER1421]

keep us updated!!

[dzik86]

_Ruffles_, on Aug 01 2012 - 08:39, said:

Great gif

[Reclusiarch]

Mulling over the problem of simulation going uphill and downhill from the top-down perspective...Its not a very visually obvious effect but it should be "felt" by the player driving the tank. i think the best way to do this is to campare a location in front of the tank with a location near the rear of the tank - if that locations value is greater than the rear value then the tank is going uphill, if it is equal then its a flat platue, and of course if its less then the tank is going downhill...

[PTwr]

Reclusiarch, on Aug 01 2012 - 09:03, said:

Mulling over the problem of simulation going uphill and downhill from the top-down perspective...Its not a very visually obvious effect but it should be "felt" by the player driving the tank. i think the best way to do this is to campare a location in front of the tank with a location near the rear of the tank - if that locations value is greater than the rear value then the tank is going uphill, if it is equal then its a flat platue, and of course if its less then the tank is going downhill...

Exactly what I was thinking about.

Map made of two bitmaps, black and white height map ( easiest to create as you operate on just one color ) togehter with full color ground. Height map doesn't have need to be same resolution as ground, 25% should be precise enough if you want to conserve memory. Dividing full coordinates by 4 can be achieved swiftly by bit shifts.

Don't forget to make opposite effect if tnak is going in reverse. :>

Do you have friction implemented already?

edit:

To make it more precise you could check spots where each track ends and begin its contact with surface, then select higher/lower ( depending if forward/reverse ) point from front and rear pair to compare.

another edit:

How do you make tracks effect? Lazy way of creating temporary object for each skid or some smart trick?

Edited by PTwr, Aug 01 2012 - 09:35.

[Reclusiarch]

PTwr all good ideas, the cool thing is I dont even need to draw the heightmap - but it will be loaded by the game to compare pixels. I need a clever grayscale height map. I am thinking this could be an easy approach;

1st some rules: Dark tones = higher elevation, Light tones = lower elevation

consider position Front - we take a sample of the heightmap and check its color value and we get (128, 128, 128) = pretty dark gray. Then compare the position of the Back and we get (133, 133, 133). If you load those values in photoshop you will learn that higher numbers = lighter tones. we can then take 128 - 133 = -5. Now modifiy our speed by this value. Taking our 12km/h speed down by 5 is pretty harsh - so maybe soften it up a little

///Pseudo Code!	  
private void ModifySpeedOnSlope(Color Front, Color Back, float Speed)
		{
			Speed = Speed + ((Front - Back) * 0.25f);
		}

Edited by Reclusiarch, Aug 01 2012 - 09:50.

[PTwr]

///Pseudo Code!

// hMap is one fourth size of full map to make stuff lighter and less prone to glitching on very detailed map. Of course that requires full map to be in power of 4 sizes to allow smoth divide oeprations.
private float MakeAngle(Point pos, ref array[,] byte hMap)
{
	float dif = hMap[pos.rear.X / 4, pos.rear.Y / 4] - hMap[pos.front.X >> 2, pos.front.Y >> 2]; dif = 0 flat, dif > 1 = downhill, dif < 1 = uphill
	// now scale it, maximum difference is 255
	dif /=255; // slope of 168 will turn into +/-0.66 with + being downhill and - being uphill
   // translating difference into our angle where flat = 1, so dif = 1 = downhill changes into angle = 2 = down.
	dif+=1; // +0.66 turns into 1.66 so we gain 66% more speed, -0.66 turns into 0.34 so we lose 66% of speed gain.
	return dif;
}
private void Accelereate(ref float speed, float angle, flaot maxAcc, int direction, float climbingNormalizer)
{
	// climbingNormalizer will be some variable to buff or nerf effect of slope on acceleration.
	// direction = 1 for forward, -1 for reverse, 0 for engine shut down
	// angle in  floating point form where 1 = flat, 0 = vertical take off and 2 = falling down, so basically, flatt = normal acceleration, uphill = reduced, downhill = increased.
	speed+=maxacc * angle * climbingNormalizer * direction;
}
private void Physics(ref float speed, float friction)
{
	// friction is rather lack of friction, with 1.0 being a no friction sliding on ice and 0.0 would be getting caught by magnetic trap. In such game and default XNA timer 0.01 should be good for testing.
	speed*=friction.
}

Edited by PTwr, Aug 01 2012 - 10:42.

[Reclusiarch]

I've got it working by measuring the color of the gray scale and adjusting the speed - but I am getting unexpected results. the problem is when you need to compare color data on a texture in XNA the only way is to gather the color data into a uint[]. This turns into a really ugly number like Color (138, 138, 138) >> 4287269514, and if we are comparing it to another Color (201, 201, 201) >> 4291414473. Now remember the higher the number means higher elevation. If we do this 4287269514 - 4291414473 we get -4144959, still a very large ugly number and no way useful to apply to a speed of like 12km/h.

I could take that number and divide by like 100000 to make it more managable but taking our speed and subtracting a concrete value is pretty messy and if that value is high enough my tank can't even accelerate fast enough to get up the hill (which is useful in some cases). So instead I am going to find out the % difference of the two numbers and use that to modiy the speed, so if the hill is 20% higher, the speed can be modified to be 20% slower. I have found out that regardless of my color the 1st 2 numbers in the uint is always 42.

4287269514 / 4291414473 = 0.999.... 0.99 difference is not very useful. ... so take the 42 out...
87269514 / 91414473 = 0.95 its a little better

87269514 is 95% of 91414473 since its less than 100% we are going uphill, if it over 100% we are going downhill.

.95 * Speed;

hardly seems like a difference - but i guess I'll need to test it

Edited by Reclusiarch, Aug 01 2012 - 11:49.

[PTwr]

The value you get is 32 bit pixel information composed of Alpha, Red, Green and Blue.

Simple pro sollution:

using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Explicit)]
struct UglyNiceColor{
  [FieldOffset(0)]
  public byte Alpha;
  [FieldOffset(1)]
  public byte Red;
  [FieldOffset(2)]
  public byte Green;
  [FieldOffset(3)]
  public byte Blue;
  [FieldOffset(0)]
  public int fullColor;
}

then

....
UglyNiceColor Color;
Color.fullColor = BigUglyNumberFromTexture;
...

and then operate on

Color.Red
Color.Green
Color.Blue

How it works:

I made "union" where four bytes uses same memory cell as one int, writing value to this int will result in assigning its bytes to each byte specified in Union in order specified by FieldOffset.

It looks like this:

[-----full color--------------]
[alpha][red][green][blue]

all in just 32 bits.


edit:

Sollution above will work but it is not neccessary if you will extract color in better way.
Show me code you use to extract color and I will try to make it better.

edit #2:
I believe it is uint (unsigned integer) not unit (something totally different).
Fact that all numbers starts with 42 is just due to fact that highest byte is used by alpha channel, and as you do not use one it is set to 255 ( no transparency ), thats why every pixel on your bitmap will start with 42.

Edited by PTwr, Aug 01 2012 - 11:32.

[Reclusiarch]

@PTwr: oops you are absolutely right I mean uint.. lol [editing now]

Ok its definetly working now... its a subtle difference of numbers but you can definetly visually notice it when you are controlling the tank. I may tweak it some more and exaggerate it slightly more to make hills a tougher climb. One thing for sure is that I need to use a map with very wide and gradual hills. If anybody has a nice smooth grayscale map I can borrow post a link.

Edited by Reclusiarch, Aug 01 2012 - 11:48.

[PTwr]

Just make oval gradient in Word and copy it to paint, simple yet working neatly for tests.

[Reclusiarch]

small updates.. srry no images to post cause there is not much to see - but i have startscreen and menus and setting up server/client system for multiplayer.

Edited by Reclusiarch, Aug 06 2012 - 09:50.

[PTwr]

Yey, keep me up to date. :>

[wildybill]

must dominate this game. release now! :D