Wars

[bzar]

Yes, the lag is because the "database" is getting a bit big for the current database implementation to handle. It gets linearly slower every time data is added.


I wiped the database. Try it now.

 

[Blue Protoman]

You may want to change the "Save" section in the map editor to "Properties", just to avoid confusion. I bet you that people would think the option itself saved the map, and would thus lose work on what they've created by forgetting to actually save!

 

[bzar]

Yeah, the "Save" category is a bit misleading. I'll try to think of a better name, but I don't feel "Properties" would be any more descriptive. Say a user wants to save his work. How does he navigate from the palette to the saving form? My thinking was that saving was the dominant tool of the tool group. Also because it is mandatory during normal workflow it should be easily found. The rest of the tools in that group are discovered in the process. Same as with "Size" and the shifting tools. I would use more descriptive names, but they tend to be too long. Ideas are welcome

 

[fusion_power]

Mockup Time!





With coords the Event log would be also more useful, you could see the starting and ending tiles of a unit movement. ^^ There could be an Extra Info area in the Menu section which always displays the current coords of an active tile. The Frame of course would have the same colour as the current Team. I also made the Background darker, it is much better for my Eyes.


I also have an Idea for inactive units, instead of making them transparent, you could grey them out. I don't know if this is possible within the Website code but I also could make pre adjusted Unit graphics, no problem.

 

[bzar]

I've been thinking about making the event ticker more helpful, but I think the actual tiles should be highlighted when an item is selected/hovered over. This way the the user wouldn't need to hunt for the correct coordinates


Greying them out is possible using only the canvas. Not sure how it would affect performance. Probably would need to be done every time a view with a map is loaded (prerender grey versions to memory). I'll see about it.

 

[bzar]

OK, looked through the entire process of how I would desaturate (grey out) the units complete with some prototyping. I'm guessing it won't be more than a few hours once I get to it.


In technical terms: it's possible to create invisible canvas elements as pixel-modifiable back buffers and then get the modified image data to an Image object.

1. Load the source image you want to modify as an Image
   
2. Create a new canvas element with document.createElement('canvas'), set the size to equal your source image
   
3. Get the 2d drawing context object from the canvas
   
4. Render your source image to the canvas using the context
   
5. Get the canvas pixel data from the context object using context.getImageData()
   
6. Modify the pixel data
   
7. Put the modified pixel data back to the canvas using context.putImageData()
   
8. Get a data URL containing the image data using canvas.toDataURL()
   
9. Create a destination Image object
   
10. Set the destination image's src attribute to the previously acquired data URL
    

My, that's a convoluted way of doing pixel manipulation, but I'd say for one-time stuff like preparing sprites with effects load-time it's not so bad. I count three instances of copying the image data and one serialization/deserialization. Shouldn't be too bad.


OK, it seems you can use the canvas object directly as an image data source for canvas.drawImage(). That takes out the serialization/deserialization, so it's just three instances of copying the image data. An optimal solution of course would only have one (initial duplication), but this isn't as bad as I expected.

 

[fusion_power]

...or you just repace the Unit Sprites with Black/white versions.


Should not have an input to the Performance I guess. Game feels already a little bit slow (may be caused of the lack of no movement on screen) so if the grey out effect costs to much (more than transparency for example) then we could use the other option for this effect. Would need more sprites of course. ^^""


P.S.: would it be possible with your method to just reduce the saturation of the Sprites? So you still have a slightly indication of the Unit Colour, just to make sure you always can identify the team Colours?

 

[bzar]

No, no, it won't affect game speed or input lag at all. Only page load time, and I think even that hit won't be too bad, perhaps not even noticeable. On another note, I've noticed some browsers are not too efficient rendering the current page layout. Chromium and Firefox seem to do just fine, but for example Midori scrolls the game area a bit slowly. Not unplayable on it either, though.


Yes, it would be possible to decrease saturation. Just do a RGB->HSV transformation to the pixels, tune saturation, then convert back to RGB. Easy as pie.


Anyway, I've set this effect for version 1.1. The most important thing now is to get the game to a state where I can start beta tests, in other words when 1.0 is feature-complete. First things first.

 

[fusion_power]

Yes, Page loading, especialy after turn switching is still pretty slow, I noticed this on every Browser, PC and Pandora by the way.


By the way, what do you still have to do until you reach 1.0? Any major things? ^^

 

[bzar]

Page loading after turn switching? It doesn't reload the page when the turn changes, just refreshes the data. What I meant by page loading was what happens when you move between views (create game, game, my maps...). I'm wondering which part of the turn switching is slow for you. The server operation takes around half a second with the current database layer (which is slow). The transferred data is a couple of kilobytes (so it shouldn't take too much time) and the client side processing is not that intensive either. Weird.


You can see the remaining things, as well as planned stuff in the Roadmap.

 

[fusion_power]

Maybe it's because I'm playing against myself, I don't know. It is not to serious and not to bad.


Here is my Idea of inactive Units:

Saturation lowered about 75% and brightness increased of 32% to make it more "smooth". ^^ Looks OK IMHO on a Map.

 

[bzar]

I agree, it looks nice . I'll aim for that when I get to the task.

 

[Gregor]

/me randomly wanders into the thread.


I wonder if browser-based games need background music ...

 

[bzar]

I wonder if browser-based games need background music ...

With wars it depends on how you play it. If you play it real time constantly looking at the screen, perhaps it could use some. If you play it like I do most of the time, that is playing about a turn per a day or two during your coffee break at work, not so much


I might be a bit strapped for free time the next couple of days, so expect less updates. Life requires my attention.

 

[bzar]

Just a small status update: I need to get reacquainted with Java for work reasons quickly, so most of my time is spent doing stuff in Java for the week and maybe the next as well. The stuff I'm doing as a practice project is beneficial to wars as a whole however.


I'm implementing a gamenode client for Java. It should make it quite simple to do Java clients for applications based on gamenode, and I plan on doing a monitor application that shows what's happening in a user's games. Perhaps at some point this will become a nice little desktop notification system that tells you when something is happening in a game you play.


I'd rather work on getting wars-gamenode to a deployable state (1.0), but for now I need to brush up on my other skillsets for a few days (or until I feel confident I can work efficiently).

 

[fusion_power]

No Java please. Java is the evil, I still want to kill it but I did not found a way yet. ^^


Java would make Problems on the Pandora, I'm sure. Java feels always slow and eats ressources like mad. You actualy want to accelerate Wars and not make it slower.

 

[bzar]

1. Java is not slow. It's definitely faster than most scripting languages, and most of the time it reaches at least half of straight C's speed. If it's used badly, of course it's slow. The memory consumption overhead from the JVM is a minus, though. The actual memory handling is actually smarter than many coders tend to make in other languages. It most definitely is faster than browser running javascript.


2. I only do this in Java because I have to do something in Java. I decided on doing something based on my current projects, and this seemed like a nice fit.

 

[j0n]

1. Java is not slow. It's definitely faster than most scripting languages, and most of the time it reaches at least half of straight C's speed. If it's used badly, of course it's slow. The memory consumption overhead from the JVM is a minus, though. The actual memory handling is actually smarter than many coders tend to make in other languages. It most definitely is faster than browser running javascript.


2. I only do this in Java because I have to do something in Java. I decided on doing something based on my current projects, and this seemed like a nice fit.

Have you considered using Gwt? There are Gwt libraries for canvas / WebGL,etc.

 

[fusion_power]

Well, "Crysis" (non java) runs faster on my PC than "MINECRAFT" (Java) does. And Minecraft hasn't anything that I would call "intense graphic effects" :lol:


However, here is my latest Sprite Sheet, this time with my Name in and some small adjustments here and there. ^^

 

[bzar]

Have you considered using Gwt? There are Gwt libraries for canvas / WebGL,etc.

Nope. I'm keeping the java stuff I do separate from the web interface at this point. The only connection is a common server.

Well, "Crysis" (non java) runs faster on my PC than "MINECRAFT" (Java) does. And Minecraft hasn't anything that I would call "intense graphic effects" :lol:


However, here is my latest Sprite Sheet, this time with my Name in and some small adjustments here and there. ^^

Well, minecraft is badly written performance-wise. It's not because of Java. Also graphics are mostly GPU-bound, so the CPU code being in Java shouldn't even affect performance that much. Unless it's really intense or badly written . You can get decent OGL scene rendering performance even out python and javascript.


Awesome . I'll try to update it to the dev server tomorrow