4k General

Contests 4K Game Competition - 2012
#21

pelle, I experimented the same problems than Mickelukas, although I didn’t go as far as him in your game.

I recommand you to try to fix the screen blinking problem first. If you need some help to do so, don’t hesitate to ask us.

#22

Mickelukas,

  1. It works nice without double buffering on my machine, so I was hoping to not have to spend bytes on that. :frowning: OK, I have a few more to use, I hope there is enough room.

  2. I see indication that engineers can move to water, but it is not easy to see blue on blue. I’ll think about what to do.

  3. The enemy do attack. I can see that when including my debug output. But, yes, they are rare, and even when they happen do not always succeed, so you will not even notice them. Combined with the fact that it seems to easy I’ll tune the AI parameters slightly to make attacks more likely. (The problem of course is that if attacks are too common the game will be easier because you can just move close to the enemy and let them kill themselves counterattacking.)

  4. Grey border means a unit has moved (or been attack… reusing the same code paths).

  5. OK. I never saw that. Maybe the clickable region is smaller than what the button looks like? Could add some margins. Or there is a problem with the state machine.

  6. I used to have move+attack, see above, but I couldn’t fit it inside of the 4096 bytes. :frowning:

  7. Actually you can click anywhere to get the WIN to show, no need to click the turn button. I agree it should be seen earlier. I can see if it is possible to move things around without having to rewrite the huge mess of game logic.

Thanks for the link (and for StephR to comment as well; no, I do not need to ask about double buffering, but including a few more classes/methods will be tricky).

#23

Trying to fix the flickering. I wasn’t overriding update, since I wasn’t seeing any flickering anyway.

Annoyingly when I override update (the standard trick calling paint(g)), and make sure to only clean the screen at the start of a new level (all other painting is being done inside of hexes or the status bar, so no need to redraw everything) it works well in my test Application, and in an applet running in Opera, and in Firefox, but when the applet runs in Safari it for somereason insists on filling the background with default gray and it looks horrible (and probably flickers too on some machines).

I don’t want to doublebuffer, since that adds too much code (I have 16 free bytes now). What I might be able to do is to add dirty bits and only redraw hexes that actually changed, but I think by removing the clearing of the screen it will be very difficult to see any flickering anyway. Of course every individual hex/square is cleared to be redrawn, but they are so small I doubt too much flickering will be seen even on a very slow computer?

#24

Trying to free some bytes and add doublebuffring, to fix the Safari problem.

#25

It doublebuffers. Now it looks right in Safari. Ironically though, NOW I can see flickering now and then. But not often. First time I click in the applet it flickers, and then I can get it to flicker by clicking randomly along the edges of the applet. I guess it is the browser that decides to do a redraw of the plugin area for some reason or something. But overall I guess it should remove flickering.

Problem is the jar is now 4171 bytes. Have some thinking to do.

#26

Weird. I figured there is no need to keep the doublebuffer around as an instance variable, so I moved it into the paint method, but that only saved 1 lousy byte.

#27

On Internet Explorer and Chrome, under Windows 7, I still got some flickering on each mouse click, which I find very annoying. pelle, you should consider implementing simplier graphics in order to save some bytes.

And did you use Proguard, Pack200 and Kzip to compress your jar ? Riven’s compressor tool chain is not easy to use manually, yet it could save you a lot of memory if you still don’t use it.

#28

I have not uploaded any new version yet, so you should still have as much flickering as there used to be.

Have no Windows 7 to test with, so I’m just adding the doublebuffering and hoping it will work for everyone. Will try to add artificial flickering by adding a delay in my paint method just to confirm that buffering removes it (ie that I implemented it correctly…) before uploading.

Got rid of some bytes by simplifying some mechanics that are not easily visible to players anyway. It is below 4096 now even with buffering, but I want to test to make sure I didn’t mess up something that used to work (hm, maybe I should have written some unit tests for this game after all…).

#29

Mickelukas was correct. There was a bug resulting in enemy attacks having no effect. Now they have. Not sure if it makes the game easier or more difficult. At least enemy artillery should be somewhat dangerous, so there is a good reason to try to overrun them.

Slightly tweaked the combat system so that units can only fire back once. So in addition to being easier to kill when attacked multiple times, there is no risk at all to the attacker when attacking a unit that has already been attacked.

Uploaded new version to the competition site. It’s getting late here and no time for the double buffer test. Just hoping that it works for everyone. Good thing there are many days remaining before deadline.

#30

Also made the move targets much easier to see. Hopefully that fixes the problem with the engineer next to the river not seeing it can move there.

Markers are not pretty, but I think being easy to see is more important.

#31

The game is easy. However there’re some those wrong a bit. My tank is always killed in one to one fight with foot soldier. Plus my tank never could attack in range, make it like a foot soldier.

#32

Double buffering works now, well done :slight_smile:

And here I thought my post with a link and all suggestions was worth an appreciation ::slight_smile:

Mike

#33

Now when I knew what to look for it was possible (not easy) to see. Maybe make it even more apparent (i.e. color the whole blue area grey)?

Mike

#34

Uhm. True. Grey might work.

Another great idea. Thanks again! It is all very much appreciated! :slight_smile:

#35

That is some unlucky tank.

The tanks are not really stronger, but 50 % faster. Use them to rush enemy cities or go around the flanks to take out enemy artillery. It is more like reality than many computer games really in that way. :slight_smile:

The scale is supposed to be operational, representing large areas, so multiple-hex ranges is for artillery only, not tanks.

#36

Just won all, on level 30. Several interesting levels, especially the last one ( actually the tenth… ) that I found the hardest to win. If you still have some bytes left, you may consider painting the end turn button in a different color than white, and also the edge of the moved allied units in red instead of grey.

You just made a really honourable classic wargame, with a very good and modern user interface. Good job !

#37

Thanks!

There will be a new version very soon. I found several ways to free up more bytes, so despite having fixed several problems and added some new features I’m down to only 4064 bytes.

#38

OK. New version uploaded. Thanks for all the comments and support. :slight_smile:

If it has a blue button it is the updated version. Also:

  • Fixed so that a level is WON immediately when moving into the last city.

  • Made units that have moved grey.

  • More units on both sides on most maps. This is because with both sides attacking a lot more units are eliminated. Slightly less enemy artillery though, because they are so dangerous now.

  • Bonus scenario 11 reached by winning all 10 scenarios with no loss. A bit lame perhaps? Maybe I should just add a few normal scenarios? I wanted some kind of bonus to fight for. Not that the bonus map is very special.

  • Fixed old bug I had forgotten about that a unit in top left corner of map was auto-selected at beginning of each new turn.

  • Scenario setup changes. Mostly just unit positions and types, not so much terrain.

  • Lots of size optimizations. I have 33 bytes to spare!

Hope it is somewhat fun and not still way too easy now.

#39

Ooops. Silly bug prevented units from crossing rivers. Fixed and new version uploaded. But not it’s up to 4084 bytes. One optimization turned out to be a bit too optimistic.

#40

It’s much better now to see which allied units have moved or not.

Your idea of an 11th bonus scenario reached by winning all 10 scenarios with no loss, seems really hardcore. Or at least, for my skill !

If you want to add a new feature, you may implement a score. Each destroyed enemy unit may add one point to this score. And then, a minimum score may be necessary to start the 11th bonus scenario after winning the 10th.

Or you could just add one or more scenarios.