🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles


A member registered 1 year ago

Recent community posts

You mean like classes? 4 different kinds of bots that can be leveled up and choose one of given upgrades?

Development updates showed multiple movement types, namely classic (quadripedal), bipedal and hovers. However, your post has no mention of them, furthermore, they are absent on attached gif

Unless you meant part about time, development is not easy, especially if you don't develop [this game] for living. If it takes more time than initially expected, then so be it.

Unless you meant strikethough part, which is a joke

Yeah you should be sorry

Take your sweet time with this, don't worry.

Also, I noticed no mention of movement classes, will they be in too?

(Edited 2 times)

Just look at this magnificent machine of destruction. Isn't it cute? It's like a kitty, fluffy on the outside, murderer on the inside.

Anyway, forum is not too active in between updates, if there is a chance to make it more vivid, why not take it?

Now, give an appropriate name for this glorious gladiabot, go!

This is how Bot programs work, they are just compund while loops

Move speed = 1.2 m/s

Move speed while carrying a resource = 5.5m/s

Something's not right here

Well, on second thought, I can't really recall single reason why variables are needed, because I am human mess. Since like, changing variable theoretically is an action, and actions end cycle in robot program, and that would make it pointless to change variables

Therefore variables would be always set on start

Now, I'm not sure if you follow, that'd mean that they can be either replaced by constants (Shield > 25%), or replaced via reading things on go (Specifically Shield).

I recall that what I presented above is not actually concept for variables, but rather for targeting, so your variable would be weakest robot equipped with railgun within medium or long range and less than 25% health left, then just plug it into attack node

In Gladiabots, basically targets would be more narrow spectrum of variables, since targets refer to robots, but you could also use variables to get more accurate health/shield values, distances, or to set other variables...

MY GOD, I got lost in maze of my own thoughts

Synchronizing Android and PC accounts is on roadmap, currently you need to manually recreate AI trees

Which is why I came up with this concept

I think we'd need first way to store... things in general, in Bot's memory, before comparisions make much sense

Just out of curiosity, how fast could you possibly run battle without it losing it's accuracy?

But you can do two...

...As long as these two are walking and carrying resource

I just came here to announce that I am still alive. Also, this is really nice and, certainly, will help making better AIs. Can't wait :)

Read more here: https://en.wikipedia.org/wiki/Pseudorandom_number_...

Basically, there is no random number generator, instead, there is a function which gives seemingly random outcomes. But really it's just bunch of equations.

Random function has one input, that is seed. Seed and amount of rolls determine what number random function will output.

What that means in context of Gladiabots is (all?) matches use same seed, which means two matches with identical starting conditions (Same map and same AIs) will have identical outcome.

The problem with making all games completely random is that it would switch players focus from "My AI is not good enough, I need to make it better" to "RNG fucked me, I need to try until it works", which is both frustrating for player in question (who might just get fucked by RNG over and over again) and completely misses theme of game, which after all is about improving AI, not gambling, right?

Is it unfair? I don't think so. That's the design of range system, the further you are from enemy, the more you rely on luck. If you want to win, you need to think of ways to reduce impact of luck. And after all, your enemy relies on same system too.

It might not seem like it, but there is no luck in this game. Two matches between same AIs will always be exactly same, no matter how many times you repeat them

I feel useful

Try this:

1. Attack weakest enemy with ball

2. Otherwise If any enemy exists move towards enemy base (In long or out of range)

Then obviously, you also need to score afterwards, but I'll let you figure that one out :p

This sounds absolutely ridiculous, I fully approve it!

It's not ugly, it's just crude, It'll look better when you finish. Like this one:

Makes me wonder why you didn't include customization right off the cut.

Anyway, I think modular customization would be better. Most important aspects of robots are mobility (Am I faster than this bot? Can I run away from him?) and weapon (What is best range to engage it?) and rest just not as important. Besides that, I think most maps would still use fixed bot combination and/or have fixed choice of module combinations. The more custom module combinations would probably come later in game, when programs are more advanced anyway.

I think it's good as it is. If there is no balls at all on field, either

  1. Game is over
  2. Game had no balls to begin with

So this condition would be basically pointless, in current state it can be used to check weather there are balls which can be picked.

If you want to check if there are balls at all, try:

If any ball exists OR If any ally exists with ball OR If any enemy exists with ball

This gives same result as you want

I wanted to share my own thoughts on bot classes after Alpha 5, but you left me no choice :P

First of, I think that rather than having literal classes, robots should be modular: Separate movements, weaponry and utility. Movements and utilities are boring though, so let's move on for weapons:

Particle Machine Gun (Standard Gun)

This is standard, current gun, which I'll use as reference. For range reference, this gun has

  • Short range: 3 tiles
  • Mid range: 8 tiles
  • Long range: 14 tiles

Laser Rifle

It's almost reverse of standard gun. Instead of short particle bursts it shoots long beams of energy. Firerate is same as PMG. Dmg/shot is 3x higher than PMG, however it does not shot in 3 shot bursts, so theoretically, DpS should be even. Ranges are same as for PMG, hit chances are:

  • Short range: 10%
  • Mid range: 40%
  • Long range: 70%

Laser-Guided Missile Launcher

This weapon shots Laser-Guided Missiles (Duh!). Whenever Missile is launched, crosshair on ground appears, indicating where missile will land. That crosshair can be targeted by enemy bots It takes some time for missile to hit the spot. Missile deal fairly heavy AoE damage. AoE range is 2 tiles in diameter. Very low firerate. Short and Mid ranges are same as PMG and Laser. Long Range is 20 tiles. If missile lands in long range, enemies will always have enough time to escape.

Because of it's firerate and difficult aiming, Missile Launcher is designed for suppression, rather than dealing damage

Plasma Artillery

This weapon shots Plasma Shells, which deal AoE damage against enemies. It's firerate is lower than PMG/Laser, but not as low as Missiles. Damage is about 2x higher than PMG. It's overall DpS against single enemy is lower than Laser or PMG. AoE is 1 tile in diameter. Ranges are: Short - 5 tiles; Mid - 12 tiles; Long- 18 tiles. Similarly to Missile Launcher, at Long range it can be avoided if enemy keeps moving. It cannot hit enemies at Short range.

This weapon is designed against clusters of enemies.


It's like Flamethrower but on acid. It deals Damage over Time with lingering effects after it stops shooting. DpS to be discussed. Short and Long range are same as PMG/Laser, but it cannot attack at Long range. Mid range is 7 tiles.

Ion Reflector

This weapon projects rectangular (Slightly curved, like cut-off sphere fragment) shield. That shield is impenetrable and reflects projectiles back at enemies, however it is suspect to cohesion - shield's cohesion falls when it takes shots and regenerates when inactive. If cohesion falls to 0, shield deactivates, and is on cooldown before it can be used again. Shield is projected 3 tiles away from robot equipped with it. in pinch, it can be also used to ram enemies (for huge cohesion cost). Because of it's shape, Plasma shells and Missiles can be lobbed above it.


It can flip robots in short range (ranges same as PMG/Laser), rendering them unable to do anything for short while

Repair Beam

This weapon projects constant healing beam to your teammates. It's Healing per Second is same as Maximum DpS for PMG. It can heal itself which takes 1.5 times longer than healing other robots. Mid and Long Ranges are same as PMG/Laser, short range is 4 tiles. It can only Heal in short range. In pinch it can attack enemies in short range for half of PMGs DpS.

Do notice that repair beam doesn't interact with Shield, only HP

Tesla Dispatcher

This weapon boosts damage of other bots OR regenerates their shield. Ranges are: Short - 4 tiles, Mid - 7 tiles, Long - 12 tiles. Effective of this weapon depend on range and is higher, the closer targeted bot is. It cannot attack at all. Details to discuss.

(Edited 2 times)

Teams are put into 4-team groups and play with each other. For win they get 2 points, for draw 1 point. Then teams with most points proceed to next round, which is classic tournament such as this one:

Now obviously, the group part would need to be repeat until exactly 16 (or 8) players advance to finals

I was thinking about how tournaments would work, I'd imagine every player would set up their AI's on same map, and then matched against other players, in Euro-style tournament

(Edited 1 time)

I broke scoring down.

[Score] = [total games played] * ([wins] / [total games played])^3

I think ability to rematch would be great, but I do not think it should count to ranking score, especially to score of former winner, as he is put in severe disadventage.

I don't think sudden death would be hard to implement code-wise, but I'd certainly be tough nut to crack design wise. Score-a-ball sudden deaths for example might turn into eliminations for example, if both players go full "Eliminate, then score" mode. Elimination sudden death messes up with AIs which use shield values, that is literally every AI ever.

(Edited 1 time)

First of, lifetime W/L ratio. I hate it. I absolutely hate it. Should it be W/L ratio of last 100 matches, I wouldn't mind it, but it's lifetime. At least ranking itself isn't dedicated by it.

Other than that it was pretty fun, I had good moments, I had some teeth gnashing, but generally I enjoyed it. I'm also looking forward to tournaments.

EDIT: I also think that Draws should either be separate from loses (When you draw, it counts as draw, not as loss), or instead of ending, game should enter sudden death mode, ex: In elimination - turn off all shields; in score balls - first player to score wins

Though generally speaking, multiplayer is never something I get too exited about, I'm looking forward to Alpha 5 and 6 already :P

(Edited 2 times)

"Right now, the way to victory as I see it is more guns on the same target."

The most common way to do so is attacking weakest enemy. However I think it's better to attack enemy with weakest shield. I assume weakest enemy is enemy with least health

What matters in this game is dealing permanent damage to enemies, that is, their health. Attacking shield deals virtual damage, it ceases out after a while. Mission "Shield" is great example, where your enemies do more damage to you, but at the end of level you still have full both health and shield.

Now the reason why I'm bringing it up is because enemy with least health, can have most shield. Theoretically, attacking weakest enemy may lead to station where your bots stop attacking enemies with 50% shield, to attack enemy with 100% shield which lets enemies with weaker shield regenerate while shooting. That wastes a lot of precious damage, which could change outcome of game, of course, if default AIs were smarter

I have noticed this happening with my own AI

Personally I'm cool with targeting system taking priority over other features. It would be also lovely to get few new levels along with it, since current ones don't last long enough (Also, all but last one are symmetrical)

Also, I'd like to ask, what is your general idea on game? I mean things like how smart you want robots to be? Do you want AI to be able to solve same tasks as say C++, or be way more simpler? Do you want environment to be simulation-like or do you want to eventually expand upon other enviroments, like arenas, nature, etc.? Do you want missions to be a "clash" of robots, where you just get robots and need to fulfill objective, or would you want to add more complex levels with base and resource management, etc.?

Cool. I was also thinking about more advanced movement instructions, namely avoid which tries to find shortest path to object A, while keeping certain minimum distance from object B (That is because using combination of MoveTowards A and FleeFrom B in not viable at accomplishing that). Thought, I do not know how autonomous you want robots to be and this seems like it would be relatively easy to get anyway

Performing checks from perspective of other object, for example:

- Check if there is enemy close to closest enemy (As closest enemy, detect any ally in short range)

- Check if any ally needs protection (As all allies with Shield level < 25%, detect any enemy in short and medium range)


Another useful thing would be Dynamic Camera Modes: Following certain Robot, or All player's robots, or All Robots on map

(Edited 3 times)

A3: It does really nothing. Whether program reaches subtree, it continues onward just like it would with fulfilled condition, always. You can, and I'd advice that, use it to organize your code. It is also useful because...

A4: This is how you can create sort of functions in this game. In case you didn't know, you can connect multiple inputs to same block. Say for example you have action block "MoveTowards Closest Enemy". You need your robot to move to enemy when closest enemy is either at long range, or out of range. Normally you'd probably duplicate that block, however you can both conditions to same block.

Now Imagine you need simple program to collect balls and hunt enemies. You want only one bot to carry ball at same time.

You would need to make four step program:

1. If you have ball, score it at base

2. There is an allay holding ball, attack enemies

3. Take ball

4. Attack enemies

Normally you would need to either duplicate whole "Attack enemies" part, or make spiderweb of connections between blocks and thus your program would look like chaos. However, with subtrees you can group "Attack enemies" part, i.e. make function, and do this:

TL;DR Subtrees are used to make functions

Nota bene In my program, Shoting enemies should be before moving towards them, not after

Edit by GFX47: replaced links by images ;)