ExBiEn - Movie Game Contest

Started by Qube, April 12, 2018, 04:52:36

Previous topic - Next topic

Derron

Works - and exiting via Alt+F4 (sorry windows guys) works like a charm :p


bye
Ron

Qube

Command + Q exits mid game on Mac :P

Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

From the voting thread:
QuoteYes, by improved A.I. I meant A* Pathfinding rather than the crude direct line approach. I did have A* Pathfinding in the game but doing it when you've got a dozen EBE's after you dropped the frame rate and my quick attempt to split up the working over frames to ease the workload wasn't successful and so I just had to go another route. Now there's no worry about doing everything I wanted to do in time I can begin again on that side of things and split all the working across multiple frames.

Yes, you wrote that already.

So you mean, the path finding itself is already taking longer than you want "per frame"? With "path finding" I am talking about creating a list of "tiles"/grid-cells your character needs to move from A to B?
So while you could split up the iterations (find neighbour cells, check all "not yet checked" cells ... and do until reaching target or n cells are left) to remove strain/workload I am not sure why it takes so long - because of the map size? Maybe only do this path finding once they are close enough. It is also possible to have multiple "grid setups": a fine grained one for narrow paths - and a "big one" for all the big floors. As this is too complicated you could cheat another bit:

- you have some kind of "rooms" on the map
- pre-calculate paths from "room to room" (or the cells at the "entry" of the room)
- far away mobs (so with "many tiles to take into consideration"):
- - calculate their path to the "nearest room"
- - calculate the "nearest room" to their target
- - calculate their path from "nearest room to target" to the real target position
- - append the pre-calculated route between those too rooms to their "to nearest room" path
- - append the path "nearest room to target"-"real target position" to their to-take path

This means you would use a mix of "cached path calculation" and dynamic path. But of course this is under the assumption that - somehow - your pathffinding is "slow" (for whatever reason).
The part "nearest room to target" could be also precalculated during "team movement update" - so the team checks some rooms in its neighbourhood. Why? You only have 4 team members, but the level may have 100 units needing path finding - so 4 vs 100 sounds like a speedup.


Ok, much stuff for an "easy thing" - maybe your path finding algorithm is doing something nasty so it takes too long? Is it custom code or something you copied from somewhere (which often means it is already "optimized a bit")

bye
Ron

Qube

Quotemaybe your path finding algorithm is doing something nasty so it takes too long? Is it custom code or something you copied from somewhere (which often means it is already "optimized a bit")
It's code converted to AGK and already optimised. When I first put in the pathfinding it was calculating the path for all EBE's to the dudes in one go every half second. It was causing a stutter, or to be precise a frame drop.

So I attempted to split up the path finding over frames and not work it out all in one go. That didn't work for some silly reason and I didn't have hours and hours to figure out why not. I'd still loads to hand draw, sounds and music and building a single level sometimes took 3 days ( roughly 6 hours over 3 days in spare time ).

The reason it was slow is ( for example ) on level 2 there are around 70 EBE's all hidden in the walls and it's a 100x100 grid. I tried setting it to only do the path finding in a certain range but sometimes that lead to 10-ish EBE's in range and as AGK is not a compiled language you can't brute force lots of loops and keep up frame rate. The game runs at 60FPS on most hardware and is already doing a lot without the path finding code on top.

So I set about breaking up the path finding and building it up over frames ( which would work ) but it didn't work out as quickly as I wanted. As I'd still loads to do in the game I decided not to waste valuable time on it and come up with a quicker alternate solution.

Now I do, so I'll start that side again :) - As it doesn't matter if it takes a full day or two to sort out I can rewrite the path finding based on range and over concurrent frames without effecting frame rate.

Quote- you have some kind of "rooms" on the map
- pre-calculate paths from "room to room" (or the cells at the "entry" of the room)
- far away mobs (so with "many tiles to take into consideration"):
- - calculate their path to the "nearest room"
- - calculate the "nearest room" to their target
- - calculate their path from "nearest room to target" to the real target position
- - append the pre-calculated route between those too rooms to their "to nearest room" path
- - append the path "nearest room to target"-"real target position" to their to-take path
That's more complicated and it'd take longer to do that sorting out a frame based path finding routine :P
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

Would you elaborate a bit why it would be slower to use caches?

Just imagine you needed to find a route from Madrid to Kopenhagen. It does not matter if you use the "shortest possible" path, but want a reliable and fast route. So why not just route from Madrid to Paris, append an already known route from Paris to Hamburg - and calculate a route from Hamburg to Kopenhagen.

It can only be faster if the cache-key-finding (so to know that you can use "Paris to Hamburg") plus cache-lookup takes longer then traversing through all the possible tiles in your 100x100 map.


Also: keep in mind to only calculate routes if things changed! So only re-calculate the route if the targetTileX or targetTileY or tileX or tileY changed (means "mob or enemy moved" - enemies are of course up to 4 then).


Hmm, I just had another idea: None of the mobs or team members is able to "teleport". So within eg. 1 second of playing, the units wont move by 100 rows/cols. So once the initial route is calculated, you could reuse X percent of the route and just calculate a route "x Tiles" away from the target.
Means:
- TeamMember1 is at 10,10
- Mob is at 200, 200
- Mob calculates path from 200,200 to 10,10
- ... time goes by until path refresh is required
- TeamMember1 is now at 12,11
- Mob takes last X Tiles off the "to go" list, last (aka "target") might be 15,10 now or so
- Mob calculates route from 15,10 to 12,11 now and appends this to its list

This should speed up calculation by having _a_little_ chance to move a longer path than needed (eg. old position told the mob to move "above" a wall, while new position would be better reachable below a wall). you could also have "every x refreshes, do a full route calculation".
Imho this sounds like a good idea - without "overcomplicating" stuff.


What could be cool is if the mobs took into consideration their "collegues" (= attack in groups) but this might be overkill for now.


bye
Ron

Qube

QuoteWould you elaborate a bit why it would be slower to use caches?
I meant slower as in coding time ( the rooms idea ).

QuoteAlso: keep in mind to only calculate routes if things changed! So only re-calculate the route if the targetTileX or targetTileY or tileX or tileY changed (means "mob or enemy moved" - enemies are of course up to 4 then).
If the dudes aren't moving then no need to recalculate but 70% of the time I'd say they would be a moving target with the other 30% in a gun fight.

QuoteHmm, I just had another idea:....
I see what you are getting at but a complete path to target would need to be calculated because :

The dudes could move 40 pixels and the quickest route could be a lot different to where they were a second ago.

For example if E is heading towards D and D is moving right and down then E will need to reverse course to intercept them the quickest.


*    *
*    *
*    *
*    *
*    *        DD 
*    *        DD
*    *******    ***********
*     E    *    *         
*          *    *
*          *    *
*          *    *
*
*


I think it'll be safer, easier and more accurate to build up a complete A to B over 10 to 15 frames :)
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Qube

#21
So... Control wise, what would be the best system?

1.. Left click and dudes go to the point clicked ( but stop if they start firing )
2.. Left click and dudes start walking to that point until the left mouse button is released?
3.. Keep the current controls but don't have them stop when they reach the cross hairs?

Any other better method?

I know none of them will be getting path finding as that could be used as a cheat to get from A - B, so the exploratory side of things must remain.

I have an idea for joypad control and I think that will work well but my main concern is the best for keyboard / mouse control.

I'm also toying with the idea of beefing the game up and doing a tablet release for iOS / Android. Probably free / ad supported with in-app to remove the ads. So any control tips would be appreciated here too. Also I'd have to change the EBE graphics so the legal people don't freak out.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

@ tablet/mobile device
Moving the crosshair over the whole display to move the team is rather "untypical". So there you either need to react on "tap" ("go to there") or have this fake-joypad-control-widget (so a small area on the device to say "move left/right/up/down").

Also keep in mind that there is no "right" click there - either use "long tap" or "two fingers tapping". For TVTower I use the "long tap" option to simulate right clicks (leaving roms, aborting actions) - as people played it on windows tablets and blamed the missing right click. This does work here, as right click is used for fast-reaction-stuff (shooting).

Think the "fake joypad" works easiest there - else best thing would be "auto shooting" (so you control where to go, what to equip, ...) which leaded to a totally different game.


@ controls
re 2.
this is "left mouse _hit_" not click (click = hit + release)

re 3.
so what do they do once they reach the spot of the crosshair, continue walking in the direction they walked before? What happens if the player moves the crosshair a slight bit (aka "direction change") would they change direction "relatively" or would they return to the crosshair as a new target (at which they would not stop)

re 1.
Think that changes the gameplay as you could concentrate a bit more on the enemies (they "auto walk to target" meanwhile - until you decide to fire).


bye
Ron

STEVIE G

Quote from: Qube on April 18, 2018, 02:48:21
So... Control wise, what would be the best system?

1.. Left click and dudes go to the point clicked ( but stop if they start firing )
2.. Left click and dudes start walking to that point until the left mouse button is released?
3.. Keep the current controls but don't have them stop when they reach the cross hairs?

Any other better method?

I know none of them will be getting path finding as that could be used as a cheat to get from A - B, so the exploratory side of things must remain.

I have an idea for joypad control and I think that will work well but my main concern is the best for keyboard / mouse control.

I'm also toying with the idea of beefing the game up and doing a tablet release for iOS / Android. Probably free / ad supported with in-app to remove the ads. So any control tips would be appreciated here too. Also I'd have to change the EBE graphics so the legal people don't freak out.

How about the Cannon Fodder method using only the mouse .... left click to move to cursor, right to fire at cursor, (Left+Right) to throw grenade.  You could also copy it's method of splitting your team up.  It may not be fast enough for intense battles but should be fairly quick to try.

Also, re Pathfinding - you might consider a flow / vector field method  which is better suited to lots of enemies.

Derron

@ Stevie G
Are you talking about this?
https://gamedevelopment.tutsplus.com/tutorials/understanding-goal-based-vector-field-pathfinding--gamedev-9007

Never read about this before - added that on my bookmarks to read later. Sounds interesting.

There also was a comment there leading to:
http://www.gamasutra.com/blogs/TylerGlaiel/20121007/178966/Some_experiments_in_pathfinding__AI.php
Which had the interesting aspect of "add randomness" in - so if there were 20 mobs ("a crowd") they would use a bit random paths to "spread out" instead of moving on top of each other.


@ Qube and Pathfinding
Of course the implementation of a "cache" or "combination of cache + dynamic paths" would lead to more to code - but we are coders, so we are also problem solvers. The result counts, not your way to it.

bye
Ron

Qube

#25
QuoteMoving the crosshair over the whole display to move the team is rather "untypical"
It is.. For mobile I had in mind a dual virtual joy stick on each side of the pad. Left side for moving and right side to fire in the chosen direction. I still have to try it out and it may not work but that is the current idea.

QuoteAlso keep in mind that there is no "right" click there - either use "long tap" or "two fingers tapping". For TVTower I use the "long tap" option to simulate right clicks (leaving roms, aborting actions) - as people played it on windows tablets and blamed the missing right click. This does work here, as right click is used for fast-reaction-stuff (shooting).
For mobile it would have to be a completely different control system. I think the above method would work well and I'd have to try it on an actual device to see if it works.

Quote@ controls
re 2.
this is "left mouse _hit_" not click (click = hit + release)
Control 2 was more of a hold at X/Y point and the dudes walk to it. If that changes then the dudes walk to that point.

Quotere 3.
so what do they do once they reach the spot of the crosshair, continue walking in the direction they walked before? What happens if the player moves the crosshair a slight bit (aka "direction change") would they change direction "relatively" or would they return to the crosshair as a new target (at which they would not stop)
They always follow the angle based on the cross hairs and continue forward.

If there was just one dude then perhaps it would be easier. But keep in mind that I am aiming for a more squad / individual control when needed. I think I have a decent basic game here which just needs some focus and attention to get things right. I know there are rough areas which are expected in time frame comps but I would like to spruce it up and see how it performs on tablet mobile platforms ( just out of shear curiosity.. no expectations )

Quotere 1.
Think that changes the gameplay as you could concentrate a bit more on the enemies (they "auto walk to target" meanwhile - until you decide to fire).
That is true. There are so many varieties of control that I'm thinking it may be best to give the player a selection so they can choose what fits best to their personal preference. This leads to a few tweaks in gameplay to accommodate but that's OK.

QuoteHow about the Cannon Fodder method using only the mouse .... left click to move to cursor, right to fire at cursor, (Left+Right) to throw grenade.  You could also copy it's method of splitting your team up.  It may not be fast enough for intense battles but should be fairly quick to try.
I've been thinking about that style as the default mode. It seems pretty default and expected.

QuoteAlso, re Pathfinding - you might consider a flow / vector field method  which is better suited to lots of enemies.
I've been looking into pre calculated hot zones. Derron has a nice idea of pre-calculation and from what I've been reading it's a fast method. I think I'll end up with a custom path finding routine continually updated over a number of frames. I can easily refuse such a routine in different games so it's worth the time getting it right / optimised.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

STEVIE G

For Polymaniacs, I used a custom pathfinding method which is precaculated at runtime.  I was working with a 64x64 grid and for each grid coord I precalculate the maximum free spaces and cost to move in 24 directions from each tile.  It wasn't 100% accurate and they occasionally smack into a tree if going fast but it was lightning fast for lots of vehicles.  It would work very well with dumb slower moving Aliens :)  Happy to provide more detail if you're interested.


Qube

Quote from: STEVIE G on April 18, 2018, 07:39:07
For Polymaniacs, I used a custom pathfinding method which is precaculated at runtime.  I was working with a 64x64 grid and for each grid coord I precalculate the maximum free spaces and cost to move in 24 directions from each tile.  It wasn't 100% accurate and they occasionally smack into a tree if going fast but it was lightning fast for lots of vehicles.  It would work very well with dumb slower moving Aliens :)  Happy to provide more detail if you're interested.
VERY INTERESTED!! ;D

I already have a crude routine up an running but I want that random screw up element so I'm very interested in your fast bit not 100% approach ( seems ideal ). Go! ;D
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Derron

@ random screw up
If you had "weights" for your cells (so a left cell is less likely used than an upwards cell - like "mountains") then you could weight them "randomly" - leading to a bit random movement as two mobs will take different routes from A to B then. To make it "predictable" - so you could "re-calculate the route" without leading to totally different results - you could base that "random weight" on an individual property. Each Cell would get a weight based on some kind of "((cellTileX + cellTileY) * (randomWeightMod-1.0)) mod 5". Means the mobs get a "randomWeight mod" ("1.0" makes all cells having the same "weight"). The calculation might need to have a higher initial value to result in "substantial differing weights" or you could differentiate between the directions - it is just a rough sketchout, excuse this please.



bye
Ron

Qube

#29
For the tablet version I have come up with the following :

A virtual thumb stick on the left to control movement
Buttons on the right to fire bullets or grenades ( no swapping weapons, you just choose to fire bullets or grenades )
You touch a dude to deactivate / reactivate
Press and hold on a dude for around a quarter of a second to show how many bullets / grenades they have left
Health bar is shown below for each dude

Does that seem a decent enough system?

Quote@ random screw up
My aim is of course to make the A.I better but also avoid it being predictable. A random choice of routes would be ideal. I did have a thought about making multiple EBE's work together but the way the game flows at the moment it wouldn't even be noticeable that they were working together. Perhaps I could design a few more levels where EBE's working together was more noticeable? In it being more obvious they are trying to pin you in as a group.

I know the tablet side isn't a huge market for us mere mortals but it's an area I'd like to see what happens with this kinda game.

Worst case scenario is it's a total flop on the tablet side but at least the members that liked the game also get an updated desktop version to have a go on. More to the point, I'm still having fun working on it ;D
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.