Sudden Uppercut forced delay queue tweak [bounty: 6 XTR]

[DreadKnight]

Nightmare's Sudden Uppercut ability causes a forced delay on target units, though the "Delayed" indicator is not being triggered, even though the unit gets moved at the end of the queue; manually delayed units will trigger indicator without including the unit affected by Nightmare's ability as well. Affected unit should cause the indicator to appear and be placed after it, as this would help with being able to distinguish such units, since certain abilities can have bonus effects on them.

[andretchen0]

Does the queue delay marker needs to show up in the next round creatures?

E.g.

Or just in the current round?

In any case, it seems to me that there's a problem with src/creature.js. Here's a list of [ids, delayed] for queue.queue and queue.nextQueue following a Nightmare "Sudden Uppercut" on creature 4.

First, the creature is delayed, but in subsequent calls, it's no longer delayed. It looks like this bit fromsrc/game.js is partly causing the issue:

AncientBeast/src/game.js

Line 683 in 7082882

this.creatures[i].delayed = false;

I think I can patch up Creature using the existing refactor in src/ui/queue.js and get it to work. But the best way forward for the future is to eventually fix up creature.js, creature_queue.js, and game.js.

That code is tough to rewrite at the moment. There's a lot of reaching out and directly modifying values of other objects/modules.

[andretchen0]

I'm not sure where to ask this, so I'll put it here. Is there a way to start the game in a particular state? E.g.,

• 1v1
• Nightmare on E4
• Scavenger on F8

[DreadKnight]

Does the queue delay marker needs to show up in the next round creatures?

E.g.

Or just in the current round?

In any case, it seems to me that there's a problem with src/creature.js. Here's a list of [ids, delayed] for queue.queue and queue.nextQueue following a Nightmare "Sudden Uppercut" on creature 4.

First, the creature is delayed, but in subsequent calls, it's no longer delayed. It looks like this bit fromsrc/game.js is partly causing the issue:

AncientBeast/src/game.js

Line 683 in 7082882

this.creatures[i].delayed = false;

I think I can patch up Creature using the existing refactor in src/ui/queue.js and get it to work. But the best way forward for the future is to eventually fix up creature.js, creature_queue.js, and game.js.

That code is tough to rewrite at the moment. There's a lot of reaching out and directly modifying values of other objects/modules.

The delay marker can show up in next round as well if it addresses that round, ex forcefully causing some unit to be delayed that already acted in the current round.

Yeah, figured the core mechanic files will probably need some poking in order to fix this stuff.

[DreadKnight]

I'm not sure where to ask this, so I'll put it here. Is there a way to start the game in a particular state? E.g.,

• 1v1
• Nightmare on E4
• Scavenger on F8

All good. You can't start the game directly at a certain state, that would sure be handy, but instead you can create a save or log and replay that in a new game to get hassle free to a certain scenario, which is very handy for testing and reproducing bugs, see the paragraph over here for some info on it (I'll probably turn it into a full blown section soon) -> https://github.com/FreezingMoon/AncientBeast/blob/master/CONTRIBUTING.md#report-issues

[andretchen0]

Yeah, figured the core mechanic files will probably need some poking in order to fix this stuff.

My vote would be for a full refactor. As they stand, they reach out and modify each other directly. That makes changes quick in the beginning – just make the modification you want – but an accumulation makes it hard to figure out what the code is supposed to be doing and what it actually does.

Since the codebase is sorta OOPy, I think I'd make it OOP all the way and make strong boundaries with tight interfaces. That would mean that if game wanted to modify creature, it would have to fire a method, not just make the change – which obviously means creature has to implement that method.

That'll be a pretty big undertaking though, requiring a lot of testing.

[DreadKnight]

Yeah, figured the core mechanic files will probably need some poking in order to fix this stuff.

My vote would be for a full refactor. As they stand, they reach out and modify each other directly. That makes changes quick in the beginning – just make the modification you want – but an accumulation makes it hard to figure out what the code is supposed to be doing and what it actually does.

Since the codebase is sorta OOPy, I think I'd make it OOP all the way and make strong boundaries with tight interfaces. That would mean that if game wanted to modify creature, it would have to fire a method, not just make the change – which obviously means creature has to implement that method.

That'll be a pretty big undertaking though, requiring a lot of testing.

Yeah, sounds good to me. Most code is up for being refactored sooner or later, it's natural as the project evolves and gets more complex. Problem is actually getting the man power as well to actually get things done :-) Main issue of the project is not having bots or online multiplayer (we sort of have this, but it has a nasty bug #2044 and since that didn't get fixed, at some point didn't bothered with more testing, nor keeping servers online, as costs pilled up for no purpose). Getting that into good shape would draw way more eyes and resources.

[andretchen0]

Ah, I hadn't tried the servers yet. I didn't know they were down.

How would a rewrite be welcomed by the community? Would folks get upset if things were rewritten from scratch?

[DreadKnight]

Ah, I hadn't tried the servers yet. I didn't know they were down.

How would a rewrite be welcomed by the community? Would folks get upset if things were rewritten from scratch?

Online multiplayer only had like a few waves of alpha testing with me and some of the volunteers from our Discord server. Some others bumped into it as well and found and reported quite a few already known bugs; some chinese guy (I think) even emailed and offered $1000 if we fix the bugs, but only managed to get smaller ones from the list fixed, not the desync #2044 one; anyway, his email annoyed me rather, people should just donate first and then expect stuff to get fixed, not the other way around.

Hopefully for v0.5 will have proper online multiplayer, could even be rewritten, was actually hoping to get away from current online multiplayer engine, Nakama (see #1788) as it wasn't the best choice but there was already quite a bit of progress on implementing it at the time. Nakama was nothing but frustration, devs annoyed me as package was basically not maintained at the time for js client, their advertised Digital Ocean 1 click installer was far from the truth and it was problematic and costly to get SSL for the thing (for a simpler set-up had to pay for a pointless load balancer on DO). I got sponsored by a serverless host, Qoddi, recently, but can't get this to work on such architecture sigh.

I'll put some text soon to let people they're down, as quite a few try to register or log-in apparently xD oh well.

[andretchen0]

Gotcha. Thanks for the rundown.

With that in mind, to me, it makes sense to think about the 1vCPU before multiplayer.

It doesn't seem like there's currently a way to slot in a CPU/AI/scripted player. If the game has that, lots of good things flow from there: demos, tutorials, bots, single player matches, etc.

But I think it'll be a pretty major change; is the community ok with that, assuming it works?

I guess I'm asking whether forking and doing a rewrite has a chance to be merged back into the main branch, or whether it's simply not an option.

[DreadKnight]

Gotcha. Thanks for the rundown.

With that in mind, to me, it makes sense to think about the 1vCPU before multiplayer.

It doesn't seem like there's currently a way to slot in a CPU/AI/scripted player. If the game has that, lots of good things flow from there: demos, tutorials, bots, single player matches, etc.

But I think it'll be a pretty major change; is the community ok with that, assuming it works?

I guess I'm asking whether forking and doing a rewrite has a chance to be merged back into the main branch, or whether it's simply not an option.

Bots are also on the to-do list #542, some would prefer playing it like that in order to learn the game before playing with others. Anyway, this is an eSport, so the cherry feature will be the actual online multiplayer, which if done within reasonable specs and stable enough, will most likely get merged. There were other attempts before, but since it's a pretty big feature, lots of devs don't actually deliver. The online moves between players are peer-to-peer atm, which is fine at this stage, later on can have validators or judges implemented; Nakama mainly used for bringing players together (lobby), but we could actually use a service from Google for that sort of thing, called Open Match https://open-match.dev and skip on Colyseus altogether. At some point even Open Match would be deprecated as well since things move towards IoT, but one step at a time. Community is waiting on bots & online multiplayer, which weren't properly delivered even up to this point.