Wars


Damn, Fusion, you're good! Keep it up!
I'll try it but I wish some other people with more GFX Talent would join uns here. The only reason why I'm doing this is because nobody else want, so old Fusi have to do the Job once more. :lol:


@ B-ZaR: this is a long roadmap for such a little Game. ;)


I'm still experimenting with Blender and the best possible light setting for the Units. Stuff looks pretty different when you resize from 480x480px to 48x48px. :D Here 2 pix to compare, which looks better from the lightning:


tankcompareodzi.png



The left Tank has the "right" lightning from top left to bottom right, like the Buildings and Landscape tiles have. The Light of the 2. Tank goes from bottom left to top right, this makes it brighter but kills some contrast, some details look better, some worse. What do you think?
 
Last edited by a moderator:
I like the one on the right better, at least compared to the bright colors of the tiles.
 
@ B-ZaR: this is a long roadmap for such a little Game. ;)
Well, there's a lot to do to even catch up to wars-django. Beyond that there's some things I've planned for a long time and some great ideas I've received since I put the public server up. Some of the ideas also will make it easier to user wars-gamenode as a base for creating more similarly structured games. There's no license yet, but I'll GPL it once I reach 1.0.

I'm still experimenting with Blender and the best possible light setting for the Units. Stuff looks pretty different when you resize from 480x480px to 48x48px. :D Here 2 pix to compare, which looks better from the lightning:


tankcompareodzi.png



The left Tank has the "right" lightning from top left to bottom right, like the Buildings and Landscape tiles have. The Light of the 2. Tank goes from bottom left to top right, this makes it brighter but kills some contrast, some details look better, some worse. What do you think?
Both have their pros and cons visually. I'd like to try both on top of the terrain tiles to see which works better. In the end in my view playability trumps eyecandy every time, so if one of those is either really hard to make out from the background or identify correctly with a glance I'd drop it even if it looked better.


In other news: Attack of the pixel people! :p


cjjCw.png
 
Last edited by a moderator:
I like the one on the right better, at least compared to the bright colors of the tiles.
Yes, but for a better contrast on the maps it is recommended to have some bright and dark faces on the sprites. I guess I'll take the left one, it still can be made a little bit brighter in Photoshop without render everything again:)

Both have their pros and cons visually. I'd like to try both on top of the terrain tiles to see which works better. In the end in my view playability trumps eyecandy every time, so if one of those is either really hard to make out from the background or identify correctly with a glance I'd drop it even if it looked better.
Here we go:





The front and back view are just some playing from me, no worries. :D I don't plan this for every unit, take ages to make sprites out of the renderers for every colour and every side. However, I will redner units from both sides, just because the lightning changes slightly, if you look closeley you can spot it, the units are not mirrored but rendered like this.


I choosen an offset of 16 Pixels, should be more than enough. If you plan to make this ingame, I keep placing the Units like in the old Sprite sheet, means the ground units straight down the tile and the air units as high as possible.


Later, I post my updated Sprite sheet with the new and improved bridges. :)


...then I'll start the other units - still 19 to go...GAAAWWWDDD! :wacko:
 
Last edited by a moderator:
I think the blue tank is a bit too dark, no real contrast there and it might be hard to identify different blue units.


For reference, I currently offset 12px :)


I adjusted pixel units to be clamped to the bottom of the tile too yesterday.


I know how you feel :D
 
I think the blue tank is a bit too dark, no real contrast there and it might be hard to identify different blue units.


For reference, I currently offset 12px :)


I adjusted pixel units to be clamped to the bottom of the tile too yesterday.


I know how you feel :D
I guess, I just render everything with my default colours first, after that I can adjust the colours to every shade. :)


So, here you have something to play with:





I know, my Medium Tank looks small. But the light Tank will look even smaller. :D


The Bridges should be more different now, the white lines also indicate which part fits to which side. I hope I can test these soon at your Test-Server. ;)
 
Looks good. :)


My Tanks fit better in than I thought, the new offset really is an improvement for Sprite placing. My Bridges also look good enough to recognize them as bridges. At least this part is done. ^^


Are Ships capable of traveling under bridges or are these just decoration? and can Infantry jump straight from the water onto a bridge?


Your new Editor is nice, works pretty well. Maybe a little bit to much tiles to search and find but that's not a big deal. Maybe you could add a "fill" option or at least a option to choose an empty land or empty water Map, could save time. :)
 
Last edited by a moderator:
I'm having major problems with nginx right now. It doesn't seem to reroute large requests correctly somehow. For example large maps cannot be saved. I use nginx as a virtual host proxy. Will continue coding once this is sorted out.


Ships will traverse bridge tiles like any other tiles. They basically work like beaches. Imagine they are drawbridges :D . Same with infantry, they can climb from water to bridge. The game mechanic has no concept of tile boundary, only different tile types, graphical variations (subtypes) and owners. Movement is only based on if the target tile is of a traversable type, direction is irrelevant. The base mechanic of this game is actually really simple and elegant, once you know the elements. Currently I'm not even considering adding complexity to it.


I intend to add more tools to the map editor at some point :)
 
Just make sure that you can't park a ship ontop of a bridge, would be a little bit weird. :D In Advance Wars they solved this problem pretty clever, they just forbid narval units to swimm through rivers. And only rivers have bridges there. :lol:


By the way, I was able to import my CrissCross Map to the Testserver and now it has the right T-tiles and nice Bridges everywhere. ^^ One thing I noticed during the tests is that the units after you have moved them get a intense transparency effect. Could be a little bit confusing IMHO, looks like a invisible stealth unit or something like this :unsure: . Maybe it would be enough to grey out the units after they've moved or something like this.
 
Last edited by a moderator:
Well, basically a ship unit in a bridge tile would be drawn on top of the bridge tile. I can see why it would seem counterintuitive, but what do you suggest? The current bridge tile is functionally a drawbridge. The units and tiles are not to scale anyway (like infantry troops are the size of a city), so I don't consider the game view to be a bird's eye view picture of the battlefield. I consider it more like a map, divided in tiles with differing terrains. So the ship is not on the bridge when it's drawn on top of the bridge, it's in an area with a bridge. Making the units and tiles work differently with one another would complicate the rendering code and unit/terrain information system to no end, because the game is not designed to support things like that.


Yeah, I'll see if I can make a better effect for it at some point. Making it a little transparent was a simple task from development point of view, since it's basically a single line.


The game was originally coded so we can play the game, we really didn't care much how it looked :p . I'll try to make stuff look a little nicer with wars-gamenode, but the weight is still in playing the game, not looking at it :) .
 
Let's see how it actually looks first before whining about boats on top of bridges. Worst comes to worst, you can make it an in-joke among players of the game.
 
I could always make bridges just another type of road. So boats couldn't traverse them at all. But that wouldn't be as nice from a map design point of view :(


EDIT: I think I should explain the game mechanic and internal data structures a bit to make it easier to see why it would be hard to add something like that.


Basically, this file contains all the information about all the elements in the game. All tiles, all units, weapons, armors... it's all there. For example you can see that for any given Terrain I have six bits of information: id number, name, default defense bonus, unit classes it can build, unit classes it can repair and flags (like capturable or fund-producing). Both the server and the client get this information. In addition to that I have another file that tells the client which part of the sprite sheet corresponds to what sprite, just simple x/y coordinates for any terrain id-subtype-owner or unit type id-owner and so on combos. Other than these two files, there's no code that differs for any of the units or tiles. The code gets the current situation and those files as input and produces the wanted output.


I don't have a giant if-structure in my code to see how a specific unit moves in a specific terrain for instance. I have generic functions (like this) that rely on data about the game elemets to differentiate the result. This is why I can't have a "if terrain is water" type of conditions, because it would break the generic nature of the code and essentially hard code that terrain id to be water. The renderer simply goes through the tiles, checks their type/subtype/owner, picks the correct sprite sheet coordinates, and draws the tile. If the tile has a unit, draws the unit too the same way. Done.


You can see why adding complexity to a highly generalized system like this could be problematic. This system works well for the intended game, but isn't really flexible for exceptional behavior. The server for instance has no idea how the game is represented to the player. It only knows there's a type 3 unit owned by player 1 in terrain type 0 subtype 2 owned by nobody located in (3, 4) and stuff like that. All the rendering related stuff is in the client, which could potentially make exceptions like the one you're suggesting, but since it really adds nothing to the game I'm a little hesitant to use my time making exceptions to beautifully generic code :)
 
Last edited by a moderator:
After some tcpdumping it seems my problem isn't with nginx, but with socket.io which is even weirder. It's weird because the maximum request size seems to depend on the host running wars-gamenode. I think there's something like an incompatibility between the two going on here. Neither seems to cause the problem by itself.


EDIT: After looking into this I created an issue in socket.io's issue tracker. I think it's not reading all the data before sending a reply.
 
Last edited by a moderator:
The game was originally coded so we can play the game, we really didn't care much how it looked :p . I'll try to make stuff look a little nicer with wars-gamenode, but the weight is still in playing the game, not looking at it :) .
I actualy also don't care much how it looks, OK, maybe a little bit. ^^ But my focus is also on the gameplay and general overview, thats why I made graphics that helps me there to have a better overview. This includes stuff like bridges or why I mentioned the transparency etc... I'm not that GFX fetishist (hey, I even play Minecraft without Texture Packs! B) )


I guess, the bridges are fine, I just wanted to know if stuff can happen happen like a ship "under" a bridge automaticly blocks a Land unit that want to pass the bridge etc...


Of course you can decide how the game acts, I would just prefer it as flexible as possible (for other weird ideas I have :lol: )

Let's see how it actually looks first before whining about boats on top of bridges. Worst comes to worst, you can make it an in-joke among players of the game.
You call it whining, I call it "Brainstorming". ;) And I actualy can see how it looks because I have access to the Beta Server. :p

After some tcpdumping it seems my problem isn't with nginx, but with socket.io which is even weirder. It's weird because the maximum request size seems to depend on the host running wars-gamenode. I think there's something like an incompatibility between the two going on here. Neither seems to cause the problem by itself.


EDIT: After looking into this I created an issue in socket.io's issue tracker. I think it's not reading all the data before sending a reply.
Thats sad, you suffer from bugs that are actualy not even part of your own project. :(


So, I have to build some more units now. It takes longer than I thought so better not calculate with all new units finished soon. One QUestion:


It doesn't matter if a land Vehicle has wheels or Tank Track right? I just wanted to draw some Artillery/Howitzer on Tank Tracks instead of wheels. I know at least in Advance wars it makes a huge difference if a unit has wheels or tracks.


I don't want to confuse people with the "wrong" unit graphics. ^^"""
 
Last edited by a moderator:
I actualy also don't care much how it looks, OK, maybe a little bit. ^^ But my focus is also on the gameplay and general overview, thats why I made graphics that helps me there to have a better overview. This includes stuff like bridges or why I mentioned the transparency etc... I'm not that GFX fetishist (hey, I even play Minecraft without Texture Packs! B) )
That I can relate to :) . Actually I liked your theme from the start because of the same thing :D . I think it's easier to make out what's what.

I guess, the bridges are fine, I just wanted to know if stuff can happen happen like a ship "under" a bridge automaticly blocks a Land unit that want to pass the bridge etc...


Of course you can decide how the game acts, I would just prefer it as flexible as possible (for other weird ideas I have :lol: )
It's not possible with how the rendering is currently handled. It's not impossible by any means, there's no actual technical reason why the client couldn't do it, but it would require rewriting the rendering code. Perhaps when I start looking at animation I can implement something like this too. Currently the code is flexible for gameplay changes, so any tile can be changed quite easily or new ones can be added.

Let's see how it actually looks first before whining about boats on top of bridges. Worst comes to worst, you can make it an in-joke among players of the game.
You call it whining, I call it "Brainstorming". ;) And I actualy can see how it looks because I have access to the Beta Server. :p
I call it constructive feedback :)

Thats sad, you suffer from bugs that are actualy not even part of your own project. :(


So, I have to build some more units now. It takes longer than I thought so better not calculate with all new units finished soon. One QUestion:


It doesn't matter if a land Vehicle has wheels or Tank Track right? I just wanted to draw some Artillery/Howitzer on Tank Tracks instead of wheels. I know at least in Advance wars it makes a huge difference if a unit has wheels or tracks.


I don't want to confuse people with the "wrong" unit graphics. ^^"""
Yeah. I've gotten quite deep into the issue already and am just about to turn every debug output to the max. Superficial packet sniffing didn't help much, since all the packets seem to be routed correctly through nginx to node.js. Didn't look deeper than that the data is about right at this point, but if debug output won't help me I'll start going through the TCP packet headers.


Link to issue
 
OK. The problem manifests every time I send anything over 4KiB, because then nginx splits it to separate TCP packets and stuff breaks. If it's not proxied by nginx (sent directly) the data can be in several TCP packets. So for some reason the way nginx splits the data to TCP packets is incompatible with how node.js/socket.io interprets them.
 
OK. The problem manifests every time I send anything over 4KiB, because then nginx splits it to separate TCP packets and stuff breaks. If it's not proxied by nginx (sent directly) the data can be in several TCP packets. So for some reason the way nginx splits the data to TCP packets is incompatible with how node.js/socket.io interprets them.
I can't help you there, I'm just the graphic guy. :D


And I have a new Sprite Sheet for you. There is not much new but I made the red and blue tanks a little bit brighter. I would like to see how it works on screen. :) There also is a small Tank now. I adjusted their basic offset a little bit so their onscrean appearence should match more with the size of their 3D models to each other.


 
Updated the sprite sheet. I think the red ones are good now, the blue ones still look a bit dark to me.
 
At the moment, red and blue are 25% brighter than before, maybe I set blue to 50% but for example ships needs a clear contrast to the blue water, so to bright is also not good. But nothing is set in stone, I can even give the Units bright, shiny halos if you want. :lol:


During playing with the beta I noticed that there could be a mini map, could be useful for larger maps. And I noticed that the map doesn't scroll on the Pandora when I use the D-Pad. I thought that the D-Pad is mapped to the arrow keys so it should work actualy, it does on the PC without problems. Not sure if this is a Mapping problem of the Pandora or a browser problem. :unsure:


But it is not that important, the game isn't made for Pandora. Otherwise I would suggest optional cursor controls like in AW or so. ^^
 
Back
Top