Opening the Game-play...slowly

[DebianJoe]

I really like when the story to something feels organic. I remember when I first tried out Angband, that the introduction town was a nice way to become comfortable with the menus and the controls. I was thinking that it would be really cool to have an area that you enter at the start of a new game that was the "level outside of the levels." I don't want to promote pack-ratting, so the scheme of "pick up everything, go to town, sell ALL the things" doesn't become the primary focus, but a small area that is manually drawn as opposed to having the map-generation do it would allow me a chance to add a few "NPCs" and have them interact with the player vocally instead of fighting to the bloody death. Since the races are now a global that is set and saved, it would be a piece of cake to have what the NPCs would have to say hinge on what race you had chosen. Unless someone has a great reason for me to not do this, I'll probably spend a few days working on that. Thoughts? Opposition?

[wesleywerner]

I approve on all your thoughts :thumbsup: especially the hoarding of items bit. Some items do not need to be picked up twice like equipable things. If you say "you don't need another cloak" it will discourage me from hoarding.

Keen to see what you come up with for npc interaction!

[Frostlock]

I was actually thinking the same thing an "above ground" starting area would be nice. Later we can get some vendors and NPCs in there as well. also we should add stairs that go up again to previous levels. That way you can avoid a though fight like the rabbit untill you stacked up on scrolls. Lets fence of this level design as a work package for someone :)

[DebianJoe]

You do realize that you're asking for a way to backtrack through what is a generated floor-by-floor dungeon? I approve totally of the idea, but son of a b**\ that's going to take some significant hacking to make happen. I'll do my best to set up the "zero level," and in the process, we could use the map-generation that's in place to populate a table of floors and then shelve them, possibly using an index to work back through them. That's going to be a beast, but it would add a lot of fun. Should monsters regenerate when you come back? That would enable grinding until you hit higher levels, which would make it practically certain that the game would be beatable...but we could also compensate by adding a significant curve to how difficult the monsters from one level to the next would be (ala: Diablo) and that would force grinding to some degree.

[Frostlock]

I thought to at least remember the map layout. You could also package :wink: map monster objects and all in a level class and keep track of those. Quite a bit of work but very cool feature. :+1: on diablo. Scroll of town portal!!

[wesleywerner]

I recall Moria had a scroll of word of recall, to warp back to town, and back to the deepest level you last visited. Or you keep a random seed for each level to regenerate the same structure and items. Just love predictive randomness ;) Hunting and climbing backup up sounds like a grind.

[DebianJoe]

So, scroll of town portal/word of recall it is. We already have the option to track what level the player is on, so recalling them will probably have to do with a "previous" command of some kind that's tied to a "in-play" variable. It would be extremely cool, so it's probably worth doing. The town-level will be made as a static object, so porting from the depths back should be easy...perhaps we could shelve the dungeon so far...or simply regenerate the last floor that the player has made it to when they re-enter the dungeon. I believe that's what you're talking about with the random seed idea wesley. Too cool of an idea to ignore, so once I finish the opening town and some super-simple NPCs, I'll start to try to map out what would have to be changed to make this work.

[Frostlock]

But dungeon levels that have been explored stay the same right? Repopulating monsters I can understand but changing hallways would be weird.

[DebianJoe]

Look carefully at what's there so far. I'm randomly cutting "unblocked" rooms out of a totally blocked map, and the rooms are set using a guess/match/check/reguess method. I've been looking at this since I got home about 5 hours ago trying to figure out how to implement static maps that have been generated already. I don't totally have it yet. I tried using a " def in_town" option before calling "def new_game" to set the initial town up. To do this would take cutting lines from 60 other places, or redefining how I call out certain classes throughout the game so far. I had a teacher that said, "If you have to copy and paste code, then there's a better answer." I don't want to have reorganized walls if we leave and re-enter a floor. That wouldn't make sense. On the other hand, I've got to lay down some better framework for how I am making rooms to get away from that.

[DebianJoe]

You said, "Let's fence off this level thing as a work package to someone." Unless someone volunteers to restructure the entire thing, I'll get to work on it. I never planned on "going back up" like in Angband, because I was mostly interested in playing with the lib and didn't really look this far into the future. I should probably deal with my own mess. :smile:

I am pretty sure that what I am going to do is push the make_map function option off into some kind of code and then output that much like how how we're saving games. That way we can simply recall the stored information when we go back into the dungeon.

I'm almost tempted to move the "how in the hell do I pull this off" into the #! thread, and try to keep this section here for things that "need to be done / are being done" some of the process here would be good to share with everyone, but I'm afraid that we might overload the totally new programmer. On the other hand, it would possibly also help see the process fleshed out a lot better. I'm not sure.

[wesleywerner]

Joe for interest sake see the libtcod.random_new_from_seed thing to recreate the same dungeons. Remembering the monster and item data as you left it is another story though! It's a tricky task. How about pickling the level data? Wonder if that would work, hmm.

Pose this puzzle in the Off-topic thread on the forums :)

[DebianJoe]

Making the initial level isn't too bad if we split the new_game() function right down the middle after generating the player to the objects list. I'll have to move a variable into where I set the player level, and then actually control the player's level outside of that (perhaps as a basic player_level = 1 inside of the race menu function) or every time they go back to town, they'd start over at level 1. I can use level range checks to determine if a level is supposed to be randomly generated or static, and I think that once I get this working, I'll have a much better idea of how to make retracing our steps work. For now, though, I'm going to get some sleep.

Seriously, some of the guys who have actually done a RL before may be able to make sense of the theory much better than I can. I normally deal with real-world implementations, and never actually use Python for anything other than fun. This has proven to actually be a lot harder than I would have expected.

Pickling the data might be just what the doctor ordered.

[Frostlock]

About fencing of this work item, have a go at it! I'll stay out of you way. On how to do it, I think you were of to a good start with that save load logic. I haven't looked at the code but I would say that every time you generate and populate a new map. group all the relevant information in a structure. Create a list levels[]. Push town on index [0] and the dungeon levels as on the [1,2,3,4, etc]. That way you just reload from that list of levels whenever you enter a level :-) There is bound to be a lot of extra complexity when doing this but have a go at it :-)

[DebianJoe]

I've got a decent idea now as to how to do it, and pushing information to a file seems like the best way to keep it totally organized. That being said, I'm going to be out of place for a few days (I've got to deal with a robot+camera configuration for work), but I'll hopefully have a chance to at least use my cell phone to keep you guys merged in if there aren't any significant manual merges to be done. If that happens, I don't think that my cell phone will use vim + ssh. :pager: . If you don't hear back from me for a bit, that's why.

[Frostlock]

Merge conflicts on phone sound like a bad plan ;-) If you can try to get the latest stable stuff in before you leave that would be great. Hopefully we have some new stuff waiting for when you get back. I'm also starting work again tomorrow (I was on holiday last week) so contribution wise I'll probably slow down a bit as well.

[DebianJoe]

I've got a few hours before I'm out of place. So, if you've got something sitting around that needs to go into the canon, then shoot it my way.

I'm still struggling with trying to wrap my head around not only starting in the town, but recalling the area later...but not resetting inventory, levels, etc. Then, when you go BACK into the dungeon, leaving everything as it had been previously. I've taken about 3 different angles so far, and it's not worked like I want yet.

Who knows...a few more failed attempts and I may change the '<' symbol to a '0' and tell people "It's a hole, down is the only direction you can go! F*\ you!!!" :wink:

[Frostlock]

Lol :) I'm also struggling a bit at the moment. Trying to separate the monster logic from the main dungeons.py; it is linked to the 'hackery' wesley mentioned in the other open thread. Tricky bit is getting t I think a class layer "game" around a big piece of the existing logic would make it easier to refer from the monster implemenation to the "game". If this makes sense :-) I think your challenges would also benefit from it.

[DebianJoe]

I've come up with something that I'm 90% sure will work. I went ahead and committed it since I had about 30 minutes to work on the project tonight. The idea should allow us to transport the player to a statically generated town, while storing their inventory and game_msg current states and allows shelving of the entire dungeon map for thier current floor without having to totally rewrite the way that the dungeon is generated. This way, the player can recall to town, sell or drop items, and then go back to the dungeon in the exact same state that they'd left it. I would imagine that the same file for shelving could be used to offload a dungeon levels by tying the stairs to a call to shelve the current map level using a statement for level_foo where foo would be indexed off of whatever level they'd just left. Then, should "up stairs" be used, we could shelve the level being left and recall the one that they were entering from the file's index. It would work like the save-game feature, but only with the adjustments tied to things that weren't supposed to change from floor to floor. We wouldn't have to do anything to the player itself except provide them a player.x and player.y in the pulled map when they used stairs.

I'll have a lot better grasp of if this in going to totally function like I imagine it once I get a town built. I may end up doing a LOT of redrawing in the town just so that I can keep the current init-fov logic like it is currently. Plus, NPCs don't need fighter_component setting or to be able to move. They run stores, and that's going to be a beast in and of itself. I think they deserve a class of their own. (Dear God this is a lot of stuff to consider.)

I'll get to making a town when I get time.

[wesleywerner]

Thanks Joe, I am keen to check out what you added so far. Frost please don't hesitate to poke me if you have any questions around how I did that hackery or if you want to shout at me for adding it ;)

[DebianJoe]

Nothing that I've added so far should significantly change game-play...it's more for handing info after we actually build a town. LOL. Then I rushed the last 3 commits to make it so that joek's commit would actually function like I believe that he had intended (I'm not sure if using "vim-like" keybinds were supposed to give players the advantage of not allowing the monsters to take a turn...but I use emacs, so I at LEAST made sure they didn't get free-reign of the dungeon.) I also tried to adjust the opening msg and menus to reflect the changes.

[Frostlock]

@Wesley: I won't scream, I'm impressed you figured it out. :lol: But seriously trying to access those global variables and functions from another python module (like for example what I was trying a monsters.py module) is not possible; globals() gets you the globals of the current module only. I found a few work arounds but all would make it even dirtier. I ended up just keep my new classes in the existing module but ready to be ported out as soon as we have less global variables. One way to achieve this would be to add more classes in the main dungeons.py module to bring structure and then move them out to new module .py files. I'll go reply in that other thread now :wink:

On Mon, Jun 17, 2013 at 3:56 PM, Joe notifications@github.com wrote:

Nothing that I've added so far should significantly change game-play...it's more for handing info after we actually build a town. LOL. Then I rushed the last 3 commits to make it so that joek's commit would actually function like I believe that he had intended (I'm not sure if using "vim-like" keybinds were supposed to give players the advantage of not allowing the monsters to take a turn...but I use emacs, so I at LEAST made sure they didn't get free-reign of the dungeon.) I also tried to adjust the opening msg and menus to reflect the changes.

— Reply to this email directly or view it on GitHubhttps://github.com/DebianJoe/dungeons/issues/22#issuecomment-19546372 .

[DebianJoe]

Closed along with the idea that we could do more with a better base.