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 
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!
3 Likes
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 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
3 Likes
Advancement (2019-10-03)
At last something a bit like more war!
Today:
- 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
.
- 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
- 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.
8 Likes
Wow, it seems really ambitous. Keep up the good work!
1 Like
Thanks!
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 
), 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
3 Likes
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.
5 Likes
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 
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.
2 Likes
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
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 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
onXxxmethods simply measure the time in ms usingSystem.currentTimeMillis()since the previous measure, and store it into a variable. -
onStateUpdateEndhowever 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 alerpimethod 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.
- On that matter, the
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
(no, really it is. I’m always seeking out ways to be a better coder and that can be obsessional at times).
2 Likes
Advancement 2019-10-23
Today, I’ve worked on a lot of things related to Player Control, as well as the Camera.
- The direction of a Controlled Unit is now shown with a simple line.
- There is a slight animation helping to locate the Controlled Unit as well.
- The Camera now follows a Controlled Unit if there is one.
- Herbs were crudely added to the background in order to see better the Camera’s movement.
- It’ll be improved in the future, with more “organic” positioning.
- The speed of all the Units were doubled in order to compensate with the new 30 FPS limit.
- Also, the 30 FPS limit was added to all other screens.
- Holding B while Controlling a Unit will lock its direction, which is useful to flee and attack at the same time.
- The Result’s Screen’s Stats Panel now appears automatically, and can be hidden and shown again with each press of the B button.
- The Pad can be used in the Battle Phase (when not Controlling a Unit) and in the Result Phase to explore the Scene.
- The Camera will focus by default on the last, losing-team Unit to die, unless the Player is pressing the PAD.
- When Controlling a Unit, a Life Bar is now visible.
- The length of this Life Bar is actually proportional to the initial Health of a Unit - e.g it’ll be longer for sturdier units and shorter for more fragile ones.
- Also, it’s blinking when the Unit’s health is under 50%, and grayed out when they died.
Exploring the surroundings of a quite heated battle,
Camera focusing on the last destroyed Target. Later it’ll come with a slowdown for a more dramatic effect.
Introducing the new LifeBar 
. It’ll stress you out when it starts blinking. Shall I add some annoying repeating music to that?
Locking Directions in order to have a higher chance of beating someone else.
Next Features:
- More horror-like creatures for the Player - Zombies, Skeletons, …
- Mostly appearance-wise, no new units yet.
- Replacing $ with the Bean icon I’ve had since a couple of week.
- Wall Unit - an immobile, destroyable chunk.
- It’s more of a technical unit, much like the Target.
- Won’t be normally available to the Player for Challenges.
4 Likes
As am I. I’m already quite familiar with them because Lua has had them for ages.
There’s a good introduction to Lua coroutines here and a more in depth explanation here.
(Though personally I don’t like the second link characterising coroutines as threads because coroutines don’t run in parallel like threads do.)
Technically that means they actually are fixed points because 16 is a power of two and multiplying by 16 is equivalent to shifting left by 4.
Assuming you’re using 32 bit integers, that means the format is ‘Q24.4’.
(Whether or not they stay in that format is another matter.)
The short version:
- MIT and BSD 3-clause are probably the least restrictive whilst still requiring a copyright notice. Use one of those if you want to give people the freedom to edit anything whilst still giving you credit.
- Apache 2.0 is like MIT, but it requires anyone who modifies your code to leave a prominent notice stating that they’ve modified it.
- CC0 is as close as you can get to ‘public domain’,
but if you use that then there’s no restriction on the user whatsoever,
they don’t even have to say who originally wrote the code.
I won’t discuss the GPL here because it’s too complicated to sum up in 1-2 sentences and I’d recommend against it anyway because of the number of restrictions is has and its viral nature.
If you want more info then feel free to ask (here, in another thread, or in a PM) and I (or someone else) can provide you with more info.
GitHub or GitLab is ideal. (Personally I find GitHub easier to use.)
If you choose to use GitHub and need help doing anything then again, feel free to ask.
If you choose to use GitLab you’ll have to ask someone who is au fait with GitLab (e.g. @drummyfish).
I’m not sure how you’re planning to do this, but if you’re thinking of randomly generating the herb positions and storing those positions in a list then I know of a good alternative that could save you memory.
1 Like
I’ll ask in time for sure, thanks!
I know a few ways to have those random grass and that’s part of the fun to make them look as such also I’ll make them move like a wave
Advancement 2019-10-25
Yesterday and today was all about zombifying the game a bit:
- Player’s Units are now made out Zombies (replacing the red one without hat) and Skeletons (replacing the red one guy).
- Refactored a bit the Handlers so it’s easier to draw bodies from other handlers.
- Merged all the Game Sprites (Units, Weapons, etc) into a single one.
- Some RAM and Flash were freed that way, for no visible CPU cost!
- Finishing a Challenge will give an option to try the next one.
- Made the RIP sprite for units less contrasted.
- That’ll look much better with
- Reworked the death animation a bit.
Humans were better organized here and survived with 4 units left, although they were overpowered both in cost and numbers!
Zombie dying.
Skeleton dying. Also, they wear a hat because they’d get a cold otherwise!
Next Features:
-
PikerHole makerPike Bearer- A melee unit dealing light to moderate damage at a higher range than the Sword Bearer
- Will deal less optimal damage if a unit gets too close from them.
- (Maybe) will choose a target that cost them the less movement/rotation and have optimal damage.
- (Maybe) will try to adjust their distance toward their target in order to do optimal damage.
- That means they might walk back while poking at a pursuer.
- Should be great in combination of a shield or behind some stationary obstacles.
- Time slowing down in Results
- So we can appreciate the death of the last one.
- Better FPS control
- Hopefully correcting that issue of stuttering!
3 Likes