Wars


Minecraft somehow also uses OpenGL so I'm glad it runs at least fluid. ^^ To be honest, Minecraft performance got better over time. I even try some shader addons now, the Water has cool reflection effects for example. This of course really drops the FPS but the good thing is, high res Texture Packs seems to not drop the FPS on my PC. But usualy, I use standard textures and no mods at all. Game runs good on fullscreen (that means 1920x1200 in my case :D ) But I still wonder how good MC could perfrom if it was written in "solid" C++ or similar. ^^""


Whatever. I try to make a new mountain for WARS by the way, this time pre rendered in 3D with Blender so it gives nice shadings and the perspective is matching to the Buildings. :) But I still test it, I'm not sure if I get it good enough to make it in the Texture pack.


EDIT: and here it is! :D Finaly with all new Mountain, done in Blender and finaly with Trees in correct angle also done in Blender. (The old Pixel Art Trees may look good enough but they don't fit anymore to the rest of the graphics imho )

sprite_sheet_Fusi.png
 
Last edited by a moderator:
:D


You can see what I did today from the git history :)


I know you were joking around, but adding bots would be quite a huge task. On the other hand, wars-gamenode is quite easily interfaced with by external programs through the gamenode interface (over websockets), so even external bots are a possibility :p . This could be a bad thing if leaderboards were added, though :D
 
I guess I missed your updates, I'm busy with Minecraft. :D


However, the solution for the top border "cut off" units is nice. Simple but it works. Maybe it would look even better with the right background (grass or water or whatever) but for the Moment it is ok. The team colour frame also is nice.


Now that you've added these Borders and "power map" I would like to ask, what exactly indicates this. The movement range or shooting range or terrain ownership or just the firepower of each unit? I've never got completely into this.


I also think about animated water (for the distant future) without drawing every shore tile new. Do you think it is theoreticly possible to separate the water to a new layer? So the animated water layer would lay under the terrain tiles and we don't have to include water in the terrain tiles itself. This way, only the water tiles have to be animated, the terrain above still can be static, even the (partly transparent) shore tiles too. :) This way, you easily could change the water graphics without even touching the terrain graphics. ^^


Just an idea, I have not tested this, it still would need a redo of the shore tiles, thank god I have everything in separate layers in Photohsop. :D
 
Last edited by a moderator:
I guess I missed your updates, I'm busy with Minecraft. :D
I was too up to a couple of days ago :) . Now I've pretty much gnoe through the new stuff in 1.8 so I can concentrate on coding again :D

However, the solution for the top border "cut off" units is nice. Simple but it works. Maybe it would look even better with the right background (grass or water or whatever) but for the Moment it is ok. The team colour frame also is nice.
Yeah, it was a quick fix. I played around with different colored backdrops but that one somehow worked best.

Now that you've added these Borders and "power map" I would like to ask, what exactly indicates this. The movement range or shooting range or terrain ownership or just the firepower of each unit? I've never got completely into this.
Both are based on a "power map", and give a rough picture of the power and control distribution in a game. The power map is composed by calculating the attack options for each unit and dividing the unit's value over those tiles. Say you have an infantry unit on an open terrain. That infantry unit can attack units in tiles on a diamond-shaped area of diameter 4. That makes 1+3+5+7+9+7+5+3+1 = 41 tiles. An infantry unit with full health has a value of 100% * 100 credits = 100 credits, which is divided to the 41 tiles, which gives the player owning the unit 100/41 points in each of those tiles. All of the units are processed like this and the cumulative values for each tile and each player determine what the power map and borders look like. Each tile is considered owned by the player with the highest value in a tile, eg. the player that could direct most force to the tile. Borders shows areas of control based on this information, while power map also provides the values (relative to the highest value in a single tile) by assigning different shades of the player color to tiles. It actually so far seems to work quite well in showing the game situation.

I also think about animated water (for the distant future) without drawing every shore tile new. Do you think it is theoreticly possible to separate the water to a new layer? So the animated water layer would lay under the terrain tiles and we don't have to include water in the terrain tiles itself. This way, only the water tiles have to be animated, the terrain above still can be static, even the (partly transparent) shore tiles too. :) This way, you easily could change the water graphics without even touching the terrain graphics. ^^


Just an idea, I have not tested this, it still would need a redo of the shore tiles, thank god I have everything in separate layers in Photohsop. :D
It's possible. The easiest way would probably be just to tile an animated water tile as the canvas elements background image (so it's behind the actual canvas element I'm rendering to) and replace the water tile in the sprite sheet with a transparent one. It's not a very elegant solution, however, but it is easy to implement.
 
Both are based on a "power map", and give a rough picture of the power and control distribution in a game. The power map is composed by calculating the attack options for each unit and dividing the unit's value over those tiles. Say you have an infantry unit on an open terrain. That infantry unit can attack units in tiles on a diamond-shaped area of diameter 4. That makes 1+3+5+7+9+7+5+3+1 = 41 tiles. An infantry unit with full health has a value of 100% * 100 credits = 100 credits, which is divided to the 41 tiles, which gives the player owning the unit 100/41 points in each of those tiles. All of the units are processed like this and the cumulative values for each tile and each player determine what the power map and borders look like. Each tile is considered owned by the player with the highest value in a tile, eg. the player that could direct most force to the tile. Borders shows areas of control based on this information, while power map also provides the values (relative to the highest value in a single tile) by assigning different shades of the player color to tiles. It actually so far seems to work quite well in showing the game situation.
Sounds...complicated. :blink: Maybe some ingame infos/help could make this more clear, so Players can benefit more of this function. Ingame tips and info in general would be a nice Idea for future updates, so we don't have to look into the table sheets to see terrain infos like movement costs or defense values and such stuff.

It's possible. The easiest way would probably be just to tile an animated water tile as the canvas elements background image (so it's behind the actual canvas element I'm rendering to) and replace the water tile in the sprite sheet with a transparent one. It's not a very elegant solution, however, but it is easy to implement.
Yes, something like that. Maybe the land/sea transition on the shores don't blend that well with this method anymore but it should still look decent if smooth transparency can be used for the shore tiles . ^^
 
Sounds...complicated. :blink: Maybe some ingame infos/help could make this more clear, so Players can benefit more of this function. Ingame tips and info in general would be a nice Idea for future updates, so we don't have to look into the table sheets to see terrain infos like movement costs or defense values and such stuff.
Well, yes, the actual mechanic is complicated, same as the border determining algorithm in civilization games is complicated. You don't need to know (or think about) how the algorithm works to take advantage of it. Just think of it as something that tells you how area control is distributed in the game. I use it every now and then to identify weak points and follow the concentration of power of other players to identify possible surprise attack vectors.


Unit/terrain info is something I've thought about every now and then, but haven't figured out a solution that would well work on both mobile browsers and desktop ones with radically differing resolutions.
 
Ok, the new MongoDB backend is live at the test server. It is likely to have bugs at this time, even severe enough to crash the server process. Seems very fast though. I tried a stress test map with 900 units and a turn change only took 400ms. Typical requests are under 100ms.


People on the test server, try stuff out and report back if something works incorrectl or crashes the server or something. This backend will be the first (only for now) one meant for actual deployments, so I'd like to get it as bug-free as possible :) .
 
Added password hashing, needed to wipe test server database.


Stuff left until 1.0 and a more open beta:

  • Add game statistics viewer
  • Implement leaving games
  • Implement game event list limiter
  • Add manual
  • Add info page
  • Add pagination to map- and game lists
  • Add filtering to map- and page lists
  • Go through the entire client interface and prepare for any kind of input
  • Implement smart last line of defense exception handling
  • Move all server configuration to configuration.js
  • Seek and destroy the multiple connection spawning bug
  • Add logging
 
Well, I have SOME logging for performance analysis and stuff, but that item means more complete logging :) . I do have a logging system in place.
 
Just to inform anyone following this thread, I am making progress, but the flu I'm having is slowing me down a bit.


The roadmap items left until 1.0 are now:

  • Add manual
  • Add info page
  • Add filtering to map- and page lists
  • Go through the entire client interface and prepare for any kind of input
  • Implement smart last line of defense exception handling
  • Move all server configuration to configuration.js
  • Seek and destroy the multiple connection spawning bug
  • Add logging
 
Started on the map list filtering today, working fine in the "create game" view. Next I'll duplicate this success in "my maps" and add game list filters to home/join/spectate views. After that I plan on adding the info page and manual (mostly copied over from wars-django, unless I get bitten by the writing bug :p ). When those are done the actual content is ready for 1.0 open beta, but I still need to do some smarter handling for malicious, erronous or exceptional input and work on deployment stuff like configuration and logging. Almost there!
 
What about transferring games that currently exist in Wars-Django? Will that be painful, or even happen at all?
 
I also guess that many maps have to be updated to the new graphic features like Bridges. ^^


The old WARS already has alot of maps and some of them are looking surprisingly familiar for me, I played Span Island pretty often in Advance Wars, nice little unequal map. :)
 
Current games can not be transferred, at least not without several days' work. I'll run both versions in parallel for some time so people can finish their games in wars-django before moving. When the wars-django site no longer sees any traffic and no turns are being made, I'll replace wars-django with wars-gamenode (if it has proven to be ready for it).


Maps can be exported/imported between the two, but some should be revised to take advantage of the new features. I for one will bring all my maps (which make up majority of wars-django's maps anyway :p ).
 
Back
Top