[Game]TAZS (Java compo entry)


So I couldn’t getting fun from my previous entry ([DRAFT][CANCELLED] Ze Launch (Java Comp)) so I’m cancelling it.

Instead I’m starting some sort of battle / war game, quite inspired from Totally Accurate Battle Simulator, a game I’ve fallen in love for its clanky physics and derpy characters. That makes it some kind of weird mix between a strategy, an action and a puzzle game.

Actually the name will be “Totally Accurate Zombie Simulator”, as a homage.

The Story

You’re a powerful Lych or Sorcerer. Somehow you ran out of coffee, and those greedy humans don’t want to give some to you, instead gifting you with useless decaffeinated instant coffee and keeping the actual coffee in their hands.

Fortunately your magic powers are still there! But they’re weak, since you need coffee to power them.

Now is the time to visit those pesky humans and ask for donations with some more convincing arguments!


The core gameplay is done in 2 phases:

  • Preparation - you’re lining up units, using the limited resources you got, against an already lined-up army.
  • Battle - you watch the chaos of your units derpily going against the enemy’s ones.
    • There will be a way to control a single unit of your army, and that probably will be the most intelligent one.

It’ll feature several units, including:

  • Brawler - Mostly punchers, the cheapest units.
  • Swords - They hit with swords, strongest melee units.
  • Archers - They will rain arrows on their enemies.
  • Shields - They will absorb a lot of damage, especially from the front.

Unfortunately, you’re not able to summon puppies and kittens so the bulk of your army will be made of Zombies and Skeletons, with a few other joyous things.

Depending on the time I got left, it’ll feature:

  • Challenge mode
    • You’ll have to line up units against an army with a limited choice and resources.
    • You can retry a challenge as much as you want.
  • Sandbox mode
    • You can line-up an army on both side to tests how things turns out.
  • Two other modes

Advancement (2019-10-01)

I’ve only started since a few days, so for now it looks like a Happy Reunion Simulator, but it won’t be that way for too long :stuck_out_tongue:


It’s an ambitious game for sure. If my vision comes correct, it should be fun to at least watch.

This thread will mostly provide the (hopefully) regular advancement for the core gameplay.

Timeline & Demos


I am SO excited to see where this goes!


That looks neat, I like the dozens of little dudes all over the place

1 Like

On the one hand I’m not entirely sure what the game is supposed to look like because I’ve never seen much of TABS beyond it ending up in my Steam queue, but I get the feeling this might be a bit too ambitious for a month’s work depending on how much physics you want.

It is ambitious for sure haha I don’t deny it - and I did remove a lot of things I wanted to initially do.

That’s why I want to focus on the core stuff and get it done as soon as possible for now and accrete the rest of the game around it.

Obviously, the physics aren’t going to be as advanced as the actual game’s, but they should be fun enough to watch :stuck_out_tongue: it is a chaos-based with a hint of strategy game, after all!

1 Like

Advancement (2019-10-01 +1)

Now able to add and remove Units.
Note that the Units are currently moving; that won’t happen when I’ll properly separate the Preparation from the Battle Phases. Or at least not in the normal gameplay.


The following things are the missing Core Features and will be done soon enough:

  • Splitting the Preparation Phase and the Battle Phase
  • Units seeking the closest Enemy Units for some … hu, “intimate moments”
  • Brawlers using their Fist to harm a close enough Enemy
  • Brawlers dying after being “hugged” a bit too much
  • Resetting the scene to its Preparation Phase with the Unit’s original Positions and Roles.

I will release a preliminary demo when those Core Features are up!

Stay tuned!


You might not want to make them seek out the closest unit otherwise you could end up with half the team converging on a single unit, and eventually all units will smush together into one big blob because they’ll all be targeting roughly the same area.

Instead you should probably simulate the units’ sight lines and make each unit attack the first enemy they see.
Ideally the sight lines should be conical or trapezial for better realism,
but failing that there’s probably a couple of cheap alternatives you can do.

1 Like

The big blob is part of the silliness and chaos tho :stuck_out_tongue: in TABS, they do try to reach the closest unit available and that usually ends up in a big blob of units focusing on the same units.

This also got some tactical “advantages” because you can use special units to capture their attention, but most importantly it’s the simplest way of doing stuff - I do have a lot of things to do, and I’m not going for the smartest guys anyway. The more silly, primitive they look the best it is! Most likely, my Units will refresh their target if it gets too far for too long too.

Also realism would make the line of sight more significant, but also consider immediate surrounding because of the noise some of enemy would emit too. On another project, I do use 2 cones, one of 60° with a weight of 1 and one of 180° with a weight of 3; those weights are then multiplied by the actual distances before the smallest one is searched. Those values are quite arbitrary of course, but after testing them they felt nice enough

Advancement (2019-10-02)

Today I implemented more UI-related things:

  • The Preparation Phase is now separated from the Battle Phase.
  • A Menu was added in order to extend the features provided by the C button.
    • Accessing it will draw an overlay on the whole screen.
    • Options are chosen by keeping the corresponding Arrow Button pressed for a set amount of time.
    • In the Preparation Phase, it serves to exit and to launch the Battle Phase - provided the Allied Side got at least one Unit.
    • Later, it’ll be also used to Exit and Retry a Battle.


Tomorrow will be about the following:

  • Units Seeking Enemy Units
  • (Maybe) Units Punching Enemy Units
  • (Maybe) Units Dying

Advancement (2019-10-03)

At last something a bit like more war!


  • Brawlers seeking out the closest enemy units.
  • Brawlers punching their enemies.
  • Brawlers discovering that their enemies can also punch back.
  • Brawlers collapsing under the fist of their way too numerous enemies.

Also, this make very nice movements:


Which ends up with bodies and chaotic ending formations nonetheless.

I’m only missing the Result screen + retry command to have the core demo ready! That should be ready tomorrow.

Advancement (2019-10-04)

Today I’ve implemented the basic loops:

  • Results screen that tells you if you won or loss.
  • This screen can also show you basic stats if you maintain B.
  • Every time the game is launch, a new configuration of opponents is found, in both number and position.
  • There is also an option to relaunch the game, which simply “reset” it, leading to what will be the Title screen.


Also, there is now an early demo of the game at the first post of this thread!
It’s missing a lot of stuff, but the core is here.

Advancement 2019-10-07

Today I’ve implemented a Menu for the Title Screen, and the Sandbox Mode.

  • The Title Screen allows the Player to choose from the Quick Battle (Same Randomized Enemies as before) and Sandbox mode.
    • It beeps and features a nice zombie hand.
    • Related GIF below.
  • The Sandbox Mode allows the Player to deploy whatever Units they want on both sides.
    • It’s great for testing things and as such it’ll also help me creating the Battle Plans for the future Challenge and Campaign modes.
    • Unfortunately the position aren’t retained yet after a battle, so it’s not that useful right now.
  • A new No Man’s Land forbids the Player to place Units too close from the Enemy’s side.


Next feature:

  • Slapper Unit - Slaps tangentially units instead of pushing them back.

Advancement 2019-10-08

Today, I’ve added the Slapper and some UI.

  • The Slapper is a new Unit that will push back to the left their target - this can provide them some tactical superiority depending on the context.
    • Also they’ve got a nice hat.
  • I also added counting, both in number of units and cost, for each side. This is quite helpful to balance the game later.

Slappers in action

A Slapper dying.

Next Features:

  • Adding a unit of our choice (which is, right now, between a Brawler and a Slapper).
  • Rendering a limit between the two Areas in the Preparation.
  • Challenge Mode (the mechanic, not all the challenges themselves)

Advancement 2019-10-09

Today, it was dedicated mostly to the Battle Preparation Phase:

  • The Pad Menu was revised in order to work as a Hold-C+Press-Direction.
  • The Pad Menu can now change the Current Unit.
  • The Unit that is going to be added is now shown on the Bottom Right, with its cost.
  • The Brawler’s Cost was set to 20$
  • The Slapper’s Cost was set to 25$
  • The Result Screen was updated with the actual cost of both armies.

Me demonstrating my poor tactical choices.

Next Features:

  • Challenge Mode (Main Menu Entry, Challenge List, Cost Restrictions, and 2-3 simple Challenges, No Save of any sort).
  • Rendering a limit between the two Areas in the Preparation.

Advancement 2019-10-10

Today was about implementing the mechanics of the Challenges:

  • The List of Challenges is available from the Title Screen, as a new Menu Entry.
  • It provides all the available Challenges.
  • A Challenge is about fighting a fixed Army with limited resources.
  • It doesn’t feature Unit Type Restrictions yet as I only have two for the moment.
  • The 4 challenges aren’t very elaborated yet.
  • I refactored the Preparation and Battle code in order to provide more ways to customize it.
  • Also, each challenge provide a few flavor texts.
  • No record is made about solving them or not at this time.

Navigating through the new List and solving a rather simple challenge.

Next Features:

  • Retrying a Challenge/Battle with the last positions. (Going to make thing muuuch smoother)
  • Visible Areas of Placement. (Convenient and cheap to implement)

Advancement 2019-10-15

Today, I focused more on the UI/UX part.

  • Proper areas of deployment were added for both Armies.
    • They’re also rendered in the Preparation Phase, so you can see where exactly you can place your troops.
  • C-Menu has been added to both Battle Phase and Result Phase, which allows the Player to Retry or Exit from there.
    • Interestingly, the battle will still happen but at a reduced rate. This is of course, totally intended, and that’s totally not something not optimized properly :stuck_out_tongue:.
  • Battle/Challenge/Sandbox can now be re-prepared again, with each unit’s placement kept intact.
    • This will avoid the pain of having the redeploy every troops, and allow for easier experimentation.
    • Playing the same placement will yield the same results!
    • This is a feature that also helps me a lot, for designing Challenges, and for balancing Units as well.

Demonstrating the Areas, Retry Feature, and Menu Integration in Battle Phase and Result Phase.

Next Features:

  • Impersonating/Possessing a Unit.
  • Sword Unit
  • Shield Unit

Advancement 2019-10-16

Today, I’ve added two useful health bars and a way to control a single Unit:

  • Two health bar are now present, colored in the Team’s color, and represent the ratio between the current health and starting health for both team.
    • When full, they say an army is intact, and when empty, well that one was defeated or is about to be defeated.
    • Very satisfying to watch them deplete as the battle goes on.
  • From the Preparation Phase, it is now possible to mark a single Unit.
    • Both the Brawler and the Slapper support Control.
    • When retrying a battle, a Unit marked as Controlled will still be marked as such.
    • Unfortunately, since the current AI is quite efficient at dealing hits, going melee while controlling is very hard.
    • The Player’s controlled Unit doesn’t have any advantages, and actually has the inconvenient of not being able to control exactly the angle of their punches and slaps.
    • However the base feature is here, and already has its usefulness!

Those life bars are sure very convenient to check how a battle is going on.

Controlling now allow to use the advanced tactic of Benny Hilling around in order to slowly deplete a more numerous army.

Next Features:

  • Sword Unit
    • A stronger melee unit, using a sword.
    • Longer reach than Brawler and Slappers.
    • The Sword hits harder, but swings slower than Fits.
    • Also, more expensive.
  • Shield Unit
    • A sturdier melee unit who bears a Shield.
    • The Shield can absorb some hits from its direction.
    • The Shield can also be used for bashing, which is slower than Sword, has the same range than Fists.
    • They’re more expensive too. Probably the same than Sword, but testplaying will determine that.

Stay tuned!

Advancement - 2019-10-18

Today and yesterday I worked on the Sworder Unit:

  • Refactor in order to extract the common code between the Slapper and Brawler.
  • Implementation of the Sworder, a Unit that uses a Sword to attack other people
    • They got more HP, more reach, and more attack power.
    • Their speed is slower, both for walking and attacking.
    • They cost 50$ (Brawler costs 20$ and Slapper 25$ for comparison)
    • (That’s a temporary name - tho I found it was an archaic word for Swordman)
    • They’re also a Controllable Unit.
      • They won’t fare well as a decoy unit tho, because of their slower speed.
    • They’re currently the most powerful unit, and don’t really have a proper counter yet.
  • Fixed some bugs related to attack - before the fix, all Melee Units’ weapons would wrongly go their maximal range and animate from there. Now they’ll go back from their hit position.
    • That also increase their attack speed (up to 100%) when they’re closer from an Enemy Unit, as the weapon will have less distance to travel.
  • Added a quick challenge related to the Sworder.

I might need a Wiki dedicated to TAZS soon enough haha

Unfortunately not as resourceful as Link.

They like swinging it so much.

Next Features:

  • Shieldbearer - A Unit that bears a Shield.
    • They’ll absorb direct, front hits with little pushback - tho they’ll still be vulnerable from behind.
    • They’ll also bash their shield into their opponent’s face.
    • They should make a great counter for Sworders and others units, as well as a great decoy Unit in general.

Also, after the Shieldbearer, I’ll publish a new intermediate demo.


Wow, it seems really ambitous. Keep up the good work!

1 Like


Advancement 2019-10-20

Unfortunately, nothing for today, but the ShieldBearer is a WIP in my mind at least!

However, I’ve updated the original post with the v0.2.0 version, which includes every feature documented until now. Pretty much 80% of the gameplay is here at least! However it’s missing a lot of content (units, challenges) and isn’t really aligned well with the theme (well, the AI IS as stupid as a zombie for sure :grin:), and also some parts could be more refined (like using an acceleration for the cursor)

Please report any weird stuff / bugs you spot here!

Related news:

  • Due to memory constraints and rare related crashes, I’ll most likely reduce the unit number to 100. 50 vs 50 should still be enjoyable! Most of the challenges won’t permit you to reach that limit anyway.
  • There are some ways to save memory but I won’t have much time to explore them - instead I prefer focusing on creating more content.

Next Features:

  • ShieldBearer
  • Space Occupation
  • Time Flow Control
  • Proper Rendering Order

Just make the units zombies.
Paint their skin green or grey and maybe make them more dishevelled.

Or skeletons if you want to be a bit more original.

I recommend a min-heap.

1 Like

Yeah, that’s the idea for units, a bunch of various monsters. That’ll be fun to draw for sure!

For the min heap, I’ll have a look when I’m on it, thanks for the suggestion!

Advancement 2019-10-21

Today, I implemented a new unit:

  • Added the Shield Bearer.
    • They bear a Shield -hence the name- which protect them against front attack (up to 90% of damage/pushback is absorbed).
    • They can also bash said Shield on Enemy Units, and that’s equivalent to the Brawler attacks.
    • On 1 against 1, they wear out all other Units, including the Sworders.
    • On groups, their principal weakness is the Slapper -because this one is shifting their direction a bit.
    • Otherwise, they’re pretty great as crowd control units, and perfect for protecting more fragile units by delaying their opponents.
    • Stats wise:
      • 50$ - same cost than Sworders
      • 150 HP - same than Sworders
      • 5 ATK - same than Brawler and Slapper
      • Same Attack Speed than Sworder
      • Increased Attack Recovery when the Unit that was bashed was close to the Shield Bearer.
      • 90%, 75%, 50% Damage/Push-back Absorption from the front, 100% from the back.
    • They will give more tactical options for sure, and provide more fuel to the Challenges as well!
    • However their current domination will probably be disturbed a lot when units won’t be able to overlap onto each other.

Shield Bearers fare well against Sworders. Note how the lone one manages to keep two Sworders at bay for a moment.

Slappers are somewhat a counter to them. This might become more true in the future.

A single one can slow down defeat 4 Brawlers.

Controlling a Unit will provide you with a way to disturb a line of Shield Bearers. Nothing like a backstab, hey? It might be best to choose a faster unit for that purpose tho,

Next Features:

  • Physical Occupation - Avoiding 10 units at the same location.
    • It’s a tricky one, yet it might bring great results - less confusion, more interesting battle, etc.
    • If I take too much time to make it good enough, it won’t be included until after the comp.
    • If it takes too much CPU, I’ll try spreading it onto multiple frames -e.g. separating half of the units each frames and similar strategies.
  • Time Control - Playing the game at a 0%, 25%, 50%, 100%, 150%, 200% speed.
    • Quite Useful for me - easier to see what’s going on.
    • Also provides a way to make Unit Control easier for the Player.

Sorry to nitpick, but why ‘sworder’?
Such an obsolete word seems out of place among all the other titles.

Was it an attempt to avoid ‘swordsman’ being an arguably gendered term,
or simply because you want all the unit names to end in -er,
or maybe something else?

Also I’m not criticising it because I think it’s hilarious,
but are you aware of the alternate meanings of the word ‘slapper’?

Yeah, it’s an attempt at not having a gendered term! Also, that conveniently matched the pattern Weapon/Items + er :stuck_out_tongue:

Those are temporary terms anyway (that might end up in the comp release because my focus is somewhere else). The Slapper might be renamed into Slap Giver or something. I knew about how obsolete was “Sworder” but I didn’t knew the alternate meaning of Slapper haha

I might just name them for the weapon they hold in the end.

Advancement 2019-10-22

Today, I’ve made all Units more physical than ever:

  • Every unit will now be separated from units too close from them
    • That means they won’t gather at the same exact location, and instead form groups and (somewhat) surround their enemies.
    • The separation process is split into 2 waves to ease the CPU a bit.
    • Overall the battle looks muuuuuch better solely because of that feature.
  • I’ve locked the game into 30 FPS.
    • I still have to adjust every Units’s speed as they’re quite slow currently.
  • I’ve added a performance bar, a debug tool, which allows me to quickly know at a glance where the CPU spend most of its time
    • Such as flushing the buffer, updating Units, rendering them…
  • I fixed the following:
    • The Shield was not being rendered properly when held by an AI facing front.
    • Units’ attacks often land into dead bodies instead of other alive Units.
  • Finally, I added a new test Unit, the Target. It doesn’t have any utility, beside crumbling when hit too hard.
    • Surely it’ll be more useful on some Challenges!

A lengthy GIF showing the Targets, how the units spread out more, and the Performance Bar on the Bottom.

Next Features:

  • A few improvements on the Unit Control and UI.
  • Adjusting the Speed of all Units.

If I might make some suggestions,
you could have ‘Swordbearer’ (to match ‘Shieldbearer’),
or if you want something different then maybe ‘Swordfighter’?

Both are still used in modern English, both are ‘neutral’, and both end in -er.

‘Slap Giver’ just sounds terrible.

‘Slapper’ should be fine as long as you’re happy with Britons (and Aussies, and the Irish, and possibly people from other commonwealth nations) giggling about it when you aren’t looking. :P

Sadly I’m not surprised.

Swordzombie, Shieldzombie, Fistzombie, Palmzombie etc. could work.

This is probably one of the most underused ways of making good use of processing power.

Though in fairness it’s made a lot easier by languages that have coroutines or ‘fibre’ (lightweight threads) support.
For a long time most major languages have let coroutines slip through the net,
but they’re slowly gaining more recognition and more uptake.
The ISO C++ committee is planning to add coroutine support in C++20.

1 Like

On HW/Emulator (as opposed to seeing performace information in FemtoIDE)? If so that is very cool! Are the sources somewhere?

Thanks a lot of the suggestions!

That game is kind of silly anyway, and as french people, we have to show off our terrible English to the whole world :stuck_out_tongue:
I’m going to keep in mind those patterns!

As for the coroutines, I got to have a look at that as well. They seemed like an elegant tool, so I’m glad C++ will eventually have them!

Yeah, the performance information is running inside the game (because of that it’s eating away CPU itself!). It’s actually pretty simple and because of that, quite inaccurate and buggy at times. But it does help me see grossly how the work is done. Plus it looks cool for me :stuck_out_tongue: and sort of reminds me those Power Bars in the Command & Conquer series too.

  • Externally it’s a static class with a few methods onXxxx (like onStateInit, onStateUpdateStart, onUpdatedUnits, onRenderedUnits, onFlushedScreen, onStateUpdateEnd, onStateShutdown, …), which are manually called from various points.
  • Most onXxx methods simply measure the time in ms using System.currentTimeMillis() since the previous measure, and store it into a variable.
  • onStateUpdateEnd however will also limit the FPS, measure how long the whole frame was (including the FPS limitation).
  • Times measured this way are also smoothed a bit using a value = (value * 7 + newValue + 7) / 8 (which is acting like a cheap lowpass filter).
  • Milliseconds are stored, in a way somewhat similar to Fixed points (they’re multiplied by 16 in order to smooth them more).
  • Finally there is a draw(screen) which renders the bars at the bottom of the screen. It’s using a lerpi method I made into my Tools, and do an integer interpolation in order to scale the times to the pixels.
    • On that matter, the draw(screen) method will give a somewhat inaccurate rendering, because it’ll be called before the flush, whereas the total frame is measured after it was flushed.
    • It’s not such a big issue because times are smoothed anyway, and precision isn’t really what is seek here.

As for the sources:

I didn’t publish the source yet, thought I intend to do so.
It’s partially to preserve a few secrets inside the game until the comp is finished. It’s mostly because, for various silly and less silly reasons, I never opened any of my source code, so I’m kind of totally clueless about which license to choose, where to host the code, how to make it properly, etc (for instance, my github account is totally empty). I’ll do that after the comp, when I’ll got the time to do so.

Also, I don’t want to be interfered too much about my coding habits during the comp, as it’s very distracting to me :stuck_out_tongue:
(no, really it is. I’m always seeking out ways to be a better coder and that can be obsessional at times).