Monster work continued

[Frostlock]

Just to let you guys know I'm doing more work on the monsters.

@Wesleywerner: I like the config file a lot, also the unit test script is a very good idea. Good thing you pushed all that work in :smile:

I still have some other features I would like to add in there. This time I'll use a Git branch and I'll handle the merge in my own repository. Hopefully that will make Joe's life easier.

[DebianJoe]

All I can say is that Wesley's push was seamless. I couldn't have asked for it to be any easier. That is obviously going to be the method that I'd prefer as long as it's not too much work on you guys.

[Frostlock]

It makes sense really, the contributors like Wesley and me need to make sure our code and more complex branches fit in with the master. Its our 'mess' to clean up ;-) At least thats what I'm aiming for with my next batch of changes!

[wesleywerner]

Did I get carried away with the unit test? ;) I learnt from job experience they really help pinpoint bugs. Will be doing local merges on changes from now on. It was painless as all changes were isolated to place_objects().

Hackery

To explain how the object death_function and ai components are created:

    ai_class = globals().get(monster['ai_component'])

globals() gives a list of Class and Functions in our program. We .get() the class by name as set in the config for monster['ai_component']. It will return None as default.

I feel this a bit hackery and wondering if this should change? It does not allow arbitrary code execution so it's not a security issue, but for new users should I stick to commands taught by Joe? I think so... :

    # pseudo code
    value = monster['ai_component']
    if value == 'BasicMonster':
        ai_class = BasicMonster()
    elif value == 'BasicFriend':
        ai_class = BasicFriend()
    elif...

@Frostlock As you see Killerrabit's splash-screen of dying still works as monster names stay the same :)

Item love

We can leave the cast_heal(), cast_lightning() and all those item functions. Those work great! They just need to take the item name as parameter so messages print out right.

So a scroll of lightning and scroll of thunderbolt both cast_lighting with different strengths. While the scroll of fireball and a holy hand grenade both cast_fireball :)

[Frostlock]

I noticed your hackery :smile: I am trying to further separate monster creation from game logic so I need to figure out how to deal with that globals() stuff as well. Stay tuned! :wink:

[Frostlock]

Argh, a lot of pain today but I'm getting somewhere. Lost two hours on a silly inheritance problem, as always the devil is in the details :smile: My branch is operational but not ready yet for merging.

[wesleywerner]

I lost about 4 trying to get tab-completion for selection targets - who would have thunk it's such a tricky thing to do? ;)

Keep at it Frost, I am halting monster and item changes until you finish.

[DebianJoe]

We may be due a sit-down pow-wow about potential ways to break up the existing dungeons.py into smaller, more manageable bits. There have been times where I've looked through it trying to figure out how to insert a function and realize that I've chained processes in some pretty odd ways that force me to say, "What the hell were you thinking?" Well, when I did this one, I was trying to grasp libtcod...and didn't look very far into the future of the program. I'm sure that we could revamp some of the basic design and make everyone's life easier. I ran into this on Saturday with trying to figure out how to store floors for the sake of moving both down and up. The race_menu calls new_game & play_game and new game sets stats, calls make_map and initialize_fov which eventually leads back around to rendering the screen but only once the rooms have already been cut up. Coming up with a practical way to split that up in a way that I can store floor designs has been a total nightmare, and I haven't succeeded yet. (Although I didn't have time for coding at all today, so I may only have about 5 hours into it.) The question is all in how much further the base will need to deviate from it's current design for us to regain control of the flow of objects The current design will require more hackery to make things happen in a particular order...and God help us if we decided to change it later. I don't like being forced into hackery if it can be avoided. Thoughts?

[Frostlock]

I definately have some thoughts on the matter but they will be OOP minded. :smile: we could try to do a skype or something on the topic if you guys are up for it. Timezone wise this may be tricky. I'm in Brussels time btw, which I think is roughly the same as Wesley. What zone are you in Joe?

[DebianJoe]

I'm central standard. O_o

Well, I guess that we could open up a group discussion here. It's just that I want to have a clear plan of just how complicated reorganizing 1400+ lines of code is going to be before we get started, and if the effort will actually benefit us all in the long run. I don't think that anything brought up so far would "require" doing this, but I'm not going to pretend that some of the hacking of code that I'm looking at in order to reorganize the map-building structure looks pretty. It doesn't. Am I the only one who's thought "We should just scrap this and start over with a strict set of guidelines about maintaining flexible structures for future use?" By allowing map generation to be less hard-coded, I could implement more organic algorithms for map-shape and design that would allow a great deal more design choice in the end. On the other hand, it is a lot of work down the drain to go that route. If we can get this split up, then I'd be 100% for that. I'm just not as OOP minded as others. :wink:

[DebianJoe]

I want to be certain that my thoughts are as clear as crystal. I personally believe that we could create a far superior product than what I'd originally expected. If there is a way to make what we have currently into that, then that's what I'd prefer. On the other hand, huge design changes are becoming rather difficult with the way that things are currently laid out. I'd want a vote from everyone who's contributed so far, but there is the possibility that the easiest way to make such a perfect product that meets everyone's expectations is to finalize this one as a "coffee break" game...and start over from scratch with a solid design in mind and with the understanding that everything will need to be coded for more flexibility in the future. That's a huge decision to be made, but would it be the best option?

[Frostlock]

Cool, can I reply via email to this? (Its Frost btw) :smile:

I think I'm fine with both options. I believe it is doable to evolve the current code to something more structured. Actually I'm trying to take a step towards more structure in my current development branch. I also believe starting from scratch is not going to take us extremely long to get back to the featureset we have now. We would start over but we can copy paste a lot of stuff, or look at the existing code as example. We would have to put effort in structuring but hopefully not loose much time on understanding libtcod (and blitting :wink:) I'm undecided at the moment.

Main question for me is what the new structure would look like. I would opt for object oriented since I believe it is the easiest and most flexible in a bigger project. I can propose an OO structure for discussion if you like?

PS: @DebianJoe Central Standard Time? You work strange hours ;-) or get up insanely early! :lol:

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

I want to be certain that my thoughts are as clear as crystal. I personally believe that we could create a far superior product than what I'd originally expected. If there is a way to make what we have currently into that, then that's what I'd prefer. On the other hand, huge design changes are becoming rather difficult with the way that things are currently laid out. I'd want a vote from everyone who's contributed so far, but there is the possibility that the easiest way to make such a perfect product that meets everyone's expectations is to finalize this one as a "coffee break" game...and start over from scratch with a solid design in mind and with the understanding that everything will need to be coded for more flexibility in the future. That's a huge decision to be made, but would it be the best option?

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

[DebianJoe]

If we go OO, I don't think that anyone would have an issue with your proposal. Your OOP is stong, young jedi. :wink: and I'm still trying to break C-styled habits. I think if we can take what we have and migrate it to something more flexible, then that would be a cooler final idea...simply because it's always better to fix up an antique car than to simply go buy a new one. We're all in this to learn something, and I'd like to see how you would manage to split everything up. You tell me if it's possible to take what we have and make it work for everyone. I can still get the recommended features into it as it stands, but it's going to require some strange answers to problems. I would like to avoid that if at all possible. Propose what's on your mind, and I'll spend more time with libtcod. I know that I could still use a lot of work on really understanding the engine behind noise generation.

Since it appears that we're starting to really bring together ideas rather than simply hack on something that already exists, I guess that it would make sense that we'll probably be best served by playing to our personal strengths. Mine isn't OOP, and I am okay with that. :smile_cat:

[wesleywerner]

My responses:

On the mangled code calling:

Many small calls that do one thing well, than large monolithic ones that are prone to mangling ;) -- just like the Unix approach.

On OOP:

I use OOP where called for, but bend towards functional if the solution is straight forward and clear. Clarity is everything, and goes for any style you choose.

On scrapping:

Yes I thought that, but only for the benefit of new Python learners. personally I like to drop libtcod for an ASCII version, but that is my feeling and not going to press that any further :)

Do not discount the lessons this project teaches us, in that view it is very good! I only wrote a few crawlers so far, and each time I learn more.

I do not feel I 'lose' work by scrapping it. In my experience, I would rather redo something if I feel I learned something from first time, yeah?

I vote to retry from the current base :thumbsup:

Question: would it be easier on drawing if we isolate all drawing? That is don't use drawing calls everywhere. Instead the player takes a turn, we move characters, update the map, do combat, all data operations. Then at the end of the turn we redraw the game state.

example pseudo main loop:

while True:
    if is_in_menu:
        keys_menu()
        draw_menu()
    if is_in_game:
        keys_game()
        draw_game()

Just a thought... I implemented a similar method in my rpg project and find even as the code grows I have no problem knowing where to add new stuff. Everything game goes here, everything drawing goes here. Easy peasy lemon squeezy.

[DebianJoe]

I REALLY like the idea of trashing libtcod for straight up ASCII calls. I'm a cli junkie anyhow. The thing that I personally vote for is a far better "planned" project. I just spent the last 30 minutes making a commit that came in actually work, and I'm afraid that with multi-layered consoles and overlapped semi-transparent mapping, that this project may reach a point where I can't just take a few minutes to fix things that are broken.

On the other hand, it's technically a Rougelike already. I say we come up with a conclusion, and start over on a different project, carrying what we've learned here into it. Libtcod is great, but if we could do one that doesn't require newer coders to have to custom compile libs that would probably not hurt anyone.

If someone wants to pick an ending level for it, let's make a conclusion and take a far better approach to planning the next project. - That's my opinion on the matter. I like brainstorming, but taking something that's already functional and trying to hack it up to meet everyone's needs just isn't working out as smoothly as I would have hoped. -joe

[DebianJoe]

Also, libtcod is a middle-ground. It's not ASCII, and it's not fully graphical. If we're going to go graphical, let's use pygame and make something that's REALLY flashy. If not, then let's be able to run it in cli. :sweat_smile:

[Frostlock]

Something without external libraries would indeed be nice in terms of simplicity But I have to admit I do like the fact that libtcod makes it just a little fancier graphics wise. I mean the current graphics are simple but already a lot nicer than plain ASCII. The fun stuff to implement is the game logic, I always grind to a halt when having to do the graphical UI. So I'm leaning towards keeping libtcod. Unless there is another more accessible option we could use, like pygame maybe, don't know that one. In any case something simple for 2D stuff.

In any case I think it is good practice to separate the game logic from the graphical visualization. Like Wesley proposed in his loop above I think that is clean way to do it.

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

Also, libtcod is a middle-ground. It's not ASCII, and it's not fully graphical. If we're going to go graphical, let's use pygame and make something that's REALLY flashy. If not, then let's be able to run it in cli. [image: :sweat_smile:]

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

[DebianJoe]

When doing a graphical project, I generally try to separate the draw handler from everything else. If we do go full-graphical, it'll be a one-man job just to keep supplied graphics for everything. I've got the capacity for doing that, but you'll have to deal with transitioning center points across tiled images to create animation. That can be lots of fun. :wink:

I certainly volunteer to do vector graphics and pngs for a "more flashy" version if that's what we want. If we stick to libtcod, then I'll work on trying to centralize importable mapping options, and avoid global calls to them.

I'm cool with whatever, but I think that we all agree that our current design is more of a prison than a platform to really build on. So, do we finish it out and say it was a good first attempt, and hit up the drawing board again?

[wesleywerner]

How about finding the amulet so you are protected against the Killerrabbit, and get a chance to destroy it with the holy hand grenade? A suitable ending :)

Of course, without the amulet, you will suffer the wrath of the rabbit.

[DebianJoe]

That should be easy enough. The amulet is an item that gives +9000 HP for you. And then after you have it, you descend one more floor, where you can kill the rabbit? Sounds like a suitable ending.

So, how about we finish this fool out and hit up the CB forums to discuss the next project in good detail before we set out on this huge quest to make a far better game. I want everyone to have input in the matter.

[wesleywerner]

for your reading pleasure -- no idea if these are viable, just researching...

• http://pythonhosted.org/tdl/ - A Pythonic port of libtcod.
• https://github.com/robotis/rlfl - Python RogueLike Function Library

[Frostlock]

Works for me! in car can't type.... On Jun 17, 2013 5:12 PM, "Joe" notifications@github.com wrote:

That should be easy enough. The amulet is an item that gives +9000 HP for you. And then after you have it, you descend one more floor, where you can kill the rabbit? Sounds like a suitable ending.

So, how about we finish this fool out and hit up the CB forums to discuss the next project in good detail before we set out on this huge quest to make a far better game. I want everyone to have input in the matter.

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

[wesleywerner]

Right DebianJoe, can I have a stab at adding the amulet then? At what level should it start appearing, 6 or so? I found that after level 5 I have upskilled by defense enough to not even need potions anymore, lol. so anything thereafter would become monotonous.

[DebianJoe]

Sure. Finish this thing out wesley. Make it EPIC in a Monty-Python-esque high brow humor kind of fashion. You guys be sure to shoot ideas back on the Python Class forums for what we want to work on next.

It doesn't have to be an RPG, even. I've done sports and spaceship styled games before as well. An arcade game could be fun to take a shot at. Lots more math, though.

[wesleywerner]

I have a working pull request coming in. This is what is added:

The Amulet of the flying circus starts appearing around level 6 with 10% chance. While wearing it you are immune to Killerrabbit attacks. So do not take it off your neck ;)

The holy hand grenade appears around level 7 with 10%. It has 9000 damage. It is probably too powerful and should be lowered. It does not damage the player either.

The Killerrabbit appears around level 8 with 50% chance.

Fixed a bug so now there truly is only one unique per level.

All that is left is an end-game screen, and perhaps some story lines to match. Ran out of time for today.

[DebianJoe]

If I get some time tonight, I'll see about finishing the story up. I assume that upon killing the rabbit, we end it with some kind of over-the-top story. That will be fun.

[Frostlock]

For the sake of merging everything in I grabbed the latest version and merged my branch in my own repository. Hopefully this will be easy for Joe to merge into the master repository.

BTW merging with your text editor of choice is also possible, made my life a lot easier :-)

[Frostlock]

Closed since merge happened.