The bots will do amazing things if I pull this off. Btw. its a real – GEM more devs should appreciate it.
Written by MM. Posted at 1:11 pm on February 5th, 2010
15 comments.
Post a comment.
http://www.gametrailers.com/video/2-player-capsized/61602 for your soldat clone collection…
Hehe!
Another reason to create split screen for LD =D
lol…it’s mixed up soldat and teeworlds with single player gameplay, more physics and nicer graphics…
I think the game doesn’t come even close to SOLDAT’s addictiveness, nevertheless, two things:
1)GRAPLING HOOKS!!! The more I imagine this in-game in something like link-dead, the more I like it. This way you could even get directly on the roof of the building without those nasty stairs.
2)Graphics. I repeat, I really like the procedural stuff you’ve done, and for any map-maker without time or skill, this will simply ROCK. However, leave room for sprites and tiles and maps as detailed in modern 2D games. Most games’ got excelent graphics and nothing else, yours seems to have everything else BUT excelent graphics.
That Mario stuff is very interesting I have always liked these kind of things.
(side-scrolling && platform shooter && mouse control) != soldat clone != abuse clone
Hey MM,
On a serious technical note: A* is not a bad approach to your path planning needs, but it’s far from a “fast” approach. Look into D*, or simply “reverse dijkstra algorithm”. It’s a dynamic programming approach to the shortest/cheapest path problem – it performs in O(n^2), which a lower constant than A*’s run-time.
Just wanting to help :^) I do path planning day and night for robotics.
Gosu.
@nint22
Do those robots have guns?
Now that’s a Soldat clone. The gameplay seems a bit slow and I didnt notice any gore. Which by itself disqualifies it from even looking at it. BLOOOOD!!! That’s what players want.
nint22: D* seemed complicated, I’ll have a look a second time.
“reverse dijkstra algorithm” – isn’t that just A* with a constant heuristic? Why would it be faster?
I would like to talk some day if you want?
sorry to offtopic and knowing that maybe you dont give a’fuck, can you check soldat development… like right now…?!
MM is no longer the main developer of Soldat.
Nope, my robots don’t have guns. We only do innocent navigation competitions. I think we all learned from Terminator that, though it may be awesome, robots & guns don’t end well for humanity..
A* vs. D* topic: I poorly defined why I like D* over A*. The reason is simply because of my project’s needs: In my robotics application, the search space is not only HUGE (hundreds of square meters the robot has to drive around) but the arena is unknown at run-time. The robot fills in its “known world” over time, as it discovers obstacles, while driving to a goal.
During each “known world” update (we queued up sensor readings into burst-writes for performance), we actually only update the node/edge values within our D* map. For added performance (this code was never deployed) we removed nodes that were surrounded by obstacles as well as only added new nodes if the robot *really* thinks there is an obstacle. From there, the algorithm doesn’t need to run through all possible paths like A* does (hence the dynamic programming aspect!), but only updates the paths associated with the node/edges that have been changed.
This is a very subtle difference, and frankly the performance gain from our own D* implementation wasn’t huge, but when we ran simulations of worlds that had overly complex obstacles (fences, clustered poles, etc..), D* outperformed by far! Simply: A* is great for well-defined static worlds, D* is great for dynamic changing worlds. That’s it! I think A* seems to best fit your needs since maps are very well defined; any needed path planning data could just be pre-calculated.
Oh, and maybe I’m dumb, but aren’t the heuristic function for A* and D* still equivalent (constant)? If you want a total mind-fuck in terms of powerful path planners, look into V* from Penn State (http://bit.ly/9pXsTi) which uses language theory and has a theoretical lower constant than A* and D*, assuming you live in the future with dozen-core processors! I programmed a proof-of-concept, but couldn’t understand 90% of the paper.
tl;dr – I like path planning.
I think that settles it. Link-Dead has a static map so I go with A*. I’m still curious about reverse-dijikstra, can you tell more about it?
I thought of using it in situations where the goal is not known. Such as the bot trying to find a place to take cover or find the best camping spot.
I also use A* for the bot combat decisions. There we have a dynamic situation where D* would be good. But I don’t know if it would be a performance gain since the decisions aren’t so long.
D* is “reverse-Dijkstra” in the sense that you apply Dijkstra’s single-source shortest-path algorithm to a standard graph (vertices and edges, horah!); the only *real* difference is that the “source” vertex now becomes a “goal/sink” vertex. You then use the generated edge-table to find the “cheapest” adjacent edges, which are all globally correct for finding the “best” path. What’s very cool about this is that no matter *where* you start, once you apply the algorithm, *all* “best” paths are already found for you from any starting location!
When an edge cost is updated, as we have to when we discover obstacles in the before mentioned robotics competition, the algorithm only propagates the new changes through the table in such a way that only related paths (paths that contain the updated edge) are changed, generating new paths with as little work as possible (hence the power of D*).