Progress Report: Taking Stock

ID:92656
 
Mar 9 2010, 2:37 pm (Edited on Mar 9 2010, 4:25 pm)
Keywords: design, game, motivation
Releasing my AStar library last week was encouraging: I actually accomplished something. Although it was a fairly easy accomplishment because all I had to do was break off some fairly modular working code I created for my Vehicle Wars project.

When enabled, the debugging mode of my AStar library shows open (potential) and closed (investigated) paths in green and red circles respectively. Here, it actually paths from the middle of that spiral, off the view, and into the room on the right. Shaded tiles reflect the actual path taken.

Developing a code library with a workable demo is also an opportunity to create an excellent test bed. In making my A* library, I discovered aspects that would have been difficult to detect if I were just testing it as a larger part of a project. Perhaps I should get in the habit of developing libraries for more difficult parts of my games before integrating them.

Releasing this library hasn't attracted a whole lot of notice, and I don't blame them: most people would prefer to have something to play. Actually, there is a game I've been wanting to create - My Own Net Dream, so to speak - and that is along the vein of Sentinel Worlds or Megatraveller: a space RPG that includes both space travel and on foot exploration experiences.

Unfortunately, I've run head-on into the reason why such games are far and far between: working out the details of such a fusion is hard. (Perhaps the best recent example I've seen is the Space Rangers series which, perhaps as no coincidence, is very much a hybrid of many kinds of games just as my experiments have been.) I keep getting distracted by details in much the same way I started creating Vehicle Wars with Battletech MU* in mind and somehow ended up turning it into game that pits a real time strategy game against SimAnt.

Nonetheless, just thinking of working on such a project goes far to restoring my motivation to get some work done in BYOND. Probably because, after years of looking, I've yet to find a computer game that gets it quite right. It's partly a fault of my expectations - if I want a game done exactly as I'd want it, I'll have to do it myself.

Well, I should have an opportunity for some heavy development soon: I've got next week off for Spring Break. Though I've a Spanish midterm to cram for during that week, you'd think having that many waking hours to myself should be enough to produce something. We'll see.
Mar 9 2010, 3:06 pm
What happened to Project Shock? You're not getting away with this one.
Mar 9 2010, 3:14 pm
What happened to Project Shock? You're not getting away with this one.

Right you are, and nor should I allow myself to do so. In many ways, Project Shock is an essential stepping stone to reaching my larger aspirations.

Developing a space/ground hybrid right from the getgo complicates things unnecessarily. Project Shock is going to be the ground experience fully realized as a standalone game.
Mar 10 2010, 8:41 am
I'll check out your demo when I get a chance. I've used a number of them on BYOND (Tower Defense: Clone Wars) so it's always fun to compare and contrast.

Mar 10 2010, 10:08 am (Edited on Mar 10 2010, 10:13 am)
I'll check out your demo when I get a chance. I've used a number of them on BYOND (Tower Defense: Clone Wars) so it's always fun to compare and contrast.

Heh, I suspect the first thing you'd notice is that it's ridiculously well documented and has more than a few lines of code to optimize. It seems I code as I live: as though the world could end tomorrow and it's up to somebody else to pick up the shattered pieces.

Now that you mention it (in a passing example) in my various mental short circuits spazzing about trying to figure out an idyllic focus for my game, Tower Defense is one that comes up fairly frequently.

Particularly, a tower defense game sort of played from a singular protagonist perspective who has to assemble things on the fly. I actually discredited this idea with myself a lot, but then along comes Soulcaster and Dungeon Defense to show me that actually such a concept could work and work well.

Give the whole thing a Dwarf Fortress-esque spin, where you're not only putting up towers but actually carving out a whole little digital society, and that might just be interesting. Hmm... such a design practically lays out the steps of its realization all by itself.
Mar 13 2010, 9:13 am
I got a chance to play around with it. It does everything you would expect and I may come back and reference this for future projects so well done in that regard.

- When I randomized the map, I was a little disappointed at the generation. I was hoping for something a little more like the first level.

- I actually added a quick block of code to see how your routines handle unexpected objects appearing while mid- course. It may be fun and/or interesting to add a "Keep Trying" checkbox. Adjust your tick based on your ability to move. If your trapped in a box, reduce the tick to once every 2 seconds or something but keep trying.

Here's the added code.

proc/ObjectDrop()
    if (pathToFollow != null && pathToFollow.len > 0)
    {
        var/turf/t = pick(pathToFollow);
        var/turf/wall/w = new (locate(t.x, t.y, t.z));
        pathToFollow[pathToFollow.Find(t)] = w;
    }
proc/AStarPath_Heartbeat()

    while(1)
        ObjectDrop();
        ...


The next step is to add some code that randomly removes walls in the world which eventually allows a new path to the goal. I had to deal with this a lot in my tower defense game but mostly from a performance perspective since Theodis's PathFinder library worked really well.

What if we had a pathing competition. It might actually make for an interesting competition. I would actually prefer to make it even more interesting by adding other elements such as monsters, obstacles, HP, and what not. We're talking about moving red dots that block or attack your AI unit. Pits which aren't solid objects need to be discovered and learned by the pathing unit (or designer) as well as traps. PathFinders would get several weeks to refine their bots and to send them into the dungeon.

PathFinders - are the AI designers
DungeonKeepers - are the map designers

We setup some base rules but neither group knows what the other has planned.

The world would be open to many PathFinders at the same time so everyone can watch everyone's PathFinder unit move around.

Upon death, the PathFinder unit automatically starts again.

PathFinders get points for treasure found, depth reached, and possibly monsters killed. The battle system would have to be really simple such as 6 beats 5 and ties go to the monster. PathFinders would have to solve the riddle which is, what # is that monster and can I beat it with the weapon I found or do I need to go around it?

Looks like I can ramble on about this forever without meaning to...

I have a good classic random dungeon generator that goes on forever. I can simplify it (which I planned on) for a competition. Just need to figure out how to plug-in "PathFinders".

Mar 13 2010, 11:52 am (Edited on Mar 13 2010, 3:28 pm)
Good suggestions all around.

To a large extent, I'm leaving optimizations such as deciding how often pathing is attempted, how to path between maps, or what counts as something that returns turf.Enter() to the individual developer of the project. All my library does is return a list of turfs based off of assessing turf.Enter and weighted to reflect a lower turf.GetMovementCost() score. A few changes to those two procs will determine the kind of path returned, while you can decide for yourself how often you want to attempt pathing. This is just to make the library very flexible with a potentially unlimited number of implementations.

The current map randomization mechanism is indeed very crude. You can also change the status of a turf between wall and floor by right-clicking on it. I figured this was enough tools for anyone to test the pathing capability of the library. Although, there is a glaring omission: currently, there is no "higher cost but passable" turf. This leads to a certain question of if the cost assessment part of the pathing code even works right!

Well, the nice thing about BYOND is it does make rolling out updates really easy to do. Up the version number and bam: the BYOND pager issues the new copy to everybody who has the library.

Having broken my pathing routines into its own library has certainly revealed room for optimization here and there. I'm noticing that the closed paths (the red marks when debugging is on) tend to extend a goodly distance away from the direction that should be calculated towards. It's probably an issue in the way the movement costs are being counted. I should probably bubble sort the list of closed paths by cost every time a new one is added.

Along the lines of map generation for games in general, one cool idea that occurred to me was to base map generation off of previous existing maps that have special objects which are replaced with random elements during generation. In that way, you could potentially have individual types of rooms which generate thousands of possible appearances. You'd end up with a randomly generated map that looks relatively hand made.
Mar 13 2010, 8:26 pm
Geldonyetich wrote:
This leads to a certain question of if the cost assessment part of the pathing code even works right!

Thus far, I haven't been doing a great job of getting any game development done this Spring Break week (granted, it's not even Monday of that week off yet).

However, I did go into my library and do some heavy revision today. Not only is the above quote resolved, but the library is a bit more efficient and paths more effectively/accurately now.