OK, I'm starting to feel confident this will be complete in time for the deadline. Otherwise I guess I can save it for java4k 2013...? Started working on december 19th, based on some template posted here last year. Currently at slightly over 4k, but I have lots of things that can be removed, and made no real attempt to keep things very small. Just need to make the AI a bit more clever and have some better scenarios (probably fewer scenarios though; there are 14 now, but that is probably a waste compared to having maybe 5 good ones instead?).

Oh, I should probably come up with a name for it before submitting. At first I was planning to do something more like a Panzer General clone, so I thought of something like Panzers 4k or 4k General, but now it has diverged quite far from that anyway.

AI and scenario data/generator is using up way too much space to have nice graphics (at least at my 4k beginner skill level), but in a way that is just staying true to the genre. Maybe I can make the map look slightly better if I have a few bytes to spare.

- 4 unit types (infantry, tanks, artillery, engineers)- limited field of vision (there are more enemies in game seen above, but most are too far away)- 4 types of terrain (clear, woods, city, water)- engineers can enter a water hex and act as a bridge for other units, for "river crossing"- engineers are also good for attacking cities, that other units are not so good at- a unit that is attacked is weakened (marked with a gray border) and much easier to attack later in the same turn, so you want to concentrate several units on the same enemy in the same turn (and preferably strike with artillery first)- a campaign of several scenarios; complete a scenario by taking all cities before a certain number of turns to advance to the next scenario (fail and you get to replay the scenario)- different units have different movement rates and combat power in different terrain- some sort of AI... it's not very clever of course- combat results in possible loss of attacking and/or attacked unit

Essentially what I think you expect from a turn-based wargame?

Currently all units except for artillery can move then attack, like in Panzer General, but I will probably have to remove that to save a few bytes (especially by making the game easier for the AI).

I would be interested to hear if you think this is a too easy project? It's my first attempt at a 4k game. I know there are some obvious features (eg supply, air-support) that I would like to add if I could, but that there will be no room for me to make a proper GUI for. Supply would be very confusing for the player if there is no good way to display what units are "in supply" and why.

Also, what other similar games have there been? Couldn't find any on the current java4k site.

Your game is very promising, and will certainly make an original 4K entry. And good for every wargamer, with all these announced features. I don't remember any such turn-based wargame in previous 4K contests, although some turn-based strategy games have already been submitted.

To answer some of your questions :- it doesn't seem at all an easy project ;- about the scenarios, favor better and fewer ones ;- about the name, 4K General is a cool one. Some other suggestions : 4K Storm Rising, Memoir '4K, T4ktical Assault...

So... finally I sat down to do some more coding on this game. I thought an easy way to save some bytes, to leave room for improvements, would be to throw out my silly wasteful way of saving bitmap images as a long string with one character ("x" or "o") per pixel, and instead use a byte array. That didn't work out so well. JAR size increased to 4197 bytes. I know some FAQ already warned that this wouldn't work, but I guess I couldn't believe it until I saw it.

Guess I'll have to git stash this implementation and forget it for now.

OK, so I have to figure out some other trick to make room for a little more content. I want the move-attack-rule back, and I know how to make the AI handle it too, but I need a few more bytes. Some other day. At least now I tried this thing (only 30 minutes lost anyway).

Game submitted! (Of course not accepted by admins yet, but soon I hope.)

Campaign ended up being 10 scenarios. There is room for more, but I think 10 is enough. If anything there would be more interesting things to use the last 57 bytes for.

The AI is extremely defensive and rarely counterattack. One thing it definitely should do is attack with artillery more often (no risk of losses to the attacker), but if I fix that all scenarios will be much more difficult and you will need many more units to win (which will slow the game down and be boring). We'll have to pretend that the enemy is running very low on ammunition or something.

Some notes:1. Every time I click on the map the whole screen blinks so I guess you missed double buffering.2. When engineers stand next to the water there is no indication that they can move to it.3. The enemy never, ever attacked, making it extremely easy to win.4. Add an indication as to whether a unit moved or not, this will also help with the visualization around the next point:5. Sometimes when I clicked next turn it didn't register.6. Maybe make it possible to move and attack if you have at least one spare square as that will make it more tactical where to move your units7. When winning it isn't saying anything until you hit next turn (and that might make it 16/15 turns with just a small text showing you that you won).

1. It works nice without double buffering on my machine, so I was hoping to not have to spend bytes on that. 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.

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).

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?

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.

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.

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...).

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org