Races/Classes,Objective, Magic systems?

[DebianJoe]

One of the things that I've always enjoyed about D&D-styled anything, good Roguelikes, or any kind of RPG worth its weight in sand is character creation. There are a few aspects of this that I'd like to see implemented in some way before each new game.

I'd like to see some Tolkien-esque races (You know, elves, humans, etc) as options for the player to choose. Perhaps of those, we could come up with a few "character classes" such as warrior, ranger, etc. for each race. These options should serve to buff/debuff some of the base stats for the player. I would like to maintain some semblance of balance between them, though. I had implemented this in my own RL before, but it never really reached the kind of depths that would allow someone to become invested in their "@" on a story-telling level.

There would need to be some kind of adjustment to the "story" option that's already available, so that it seemed to be more than +1 Agility, -1 Attack...or whatever.

Also, I haven't managed to make it beyond level 8. I don't know where we should finish this thing out, but there needs to be an "objective" for the player as well. I am not too particular about the "why" you're descending in the cave...but who is going to enter a cave filled with rats, zombies, trolls, whatever if they don't have a purpose? I know I wouldn't. If I remember correctly, Rogue ended at lvl 10. Perhaps we should make it 12 or so, add a few items to allow the character to actually live that long, and then try to tie the whole story/object/race idea together somehow.

I guess that's my current level of design input. Thoughts? Questions? Comments?

[Frostlock]

Objective should be something pythonesque ;) Maybe the Amulet of the flying circus... that way there is a bit of nethack tribute as well :-p

[DebianJoe]

I like it. :dancer:

[Frostlock]

Another idea which might be doable and is somewhat original. At some level you can let the player ascend to python demi-god status. Changing the appearance to a snake, like in the snake games, trailing a few characters after every move so it looks like a snake on screen :-) Should be a fun little exercise to implement.

[wesleywerner]

One could build your character class as you level up, so you start off as the melee warrior as is now, when you upskill you have choices that will improve melee stats, or magic stats, or agility stats respectively. So by the end you can have a warrior like hero, a wizard, a rogue, or a combination of them.

edit: Later on this can be expanded on by saying, okay this wizardly staff is only usable if you are a wizard level 3, and this shield if you are a warrior level 2 + magician level 2 (effectively a paladin). I am probably overcomplicating this, but like to replay with different tactics :)

:+1: the Amulet of the flying circus

[DebianJoe]

LOL, I had built a character selection screen and racial implementation, but I like this idea perhaps more than what I had going. One of the most productive things I can do is throw out lines of code some days...and I think that this is one of those days.

[DebianJoe]

So let's flesh out this idea a bit more. Using a system similar to what I'm using for choosing what stats you want to increase, you guys want to allow a "mastery" kind of system, where you could add in a set of control-variables such as "Melee" "Spellcasting" or "foobar-whatever" that would determine if items later in the game would be able to be equipped? I can see adding passives to the scrolls, (such as +Spellcasting would add a few extra damage to each scroll used), but the idea of a "rogue" class eludes me with the current mechanics. Are we also looking at adding some kind of non-"scroll based" ranged combat, such as bows? There would need to be some items at lower levels or a buff to base stats, because in order to really allow the system that you guys are talking about to shine, you'd need to be able to make it without too much difficulty to a level where the limits that were self-imposed would actually change gameplay.

As far as your "Python-snake-lord-demi-god status" Frost: what would be the prerequisite for that? I mean, cool idea, not too hard to implement, but we need to at least have a "why" to it somewhere.

I could hack out parts of this system without too much effort, but I want to make sure that I understand them clearly before I begin, because that's going to be a drastic change to game mechanics. I like the idea of enchanted weaponry with prerequisites, though...and it's a good thing if we're going to be implementing new items that we have a stackable inventory system. ;)

[Frostlock]

We are talking about a lot of different things here :-) Here's my two cents!

For one having an end goal, I think that Amulet of the Flying Circus could fit the bill for now. We can always replace it with something else later. If this is ok for everyone lets put it in a separate issue for someone to take ownership of.

About the class/profession mechanics, that is an entirely different ball game. We want to get that right the first time. That is not something we want to have to rip and replace later. Before talking about how to implement it DebianJoe rightly points out that we need to establish what we want to achieve first. Basic IT rule, get the business requirements first ;-) You hardly ever get them but hey we can try :-D Our most important requirement is that we want to keep it relatively simple so new programmers can understand it. So lets not take it too far immediately! Melee, spellcasting, ranged seem like three classic abilities we should do. I'm not sure but I think the code might be simpler if we work under the philosophy that every character can do everything. That way we only have one codebase (player class) , depending on the choice you make during level up you get better at doing things and certain more powerful items become available for use.

What I also would like to see is that we extract the actual monsters, spells, items and equipment definitions out of the code. If we can externalize them in files or something we can develop on limited sets but we could create very rich games by adding monsters and items using these files. It would be good to leave some examples in the main code but to also read additional content out of files. This would make the code a bit leaner.

Concerning the "Python-snake-lord-demi-god status" (:+1: on that name). In my mind it was something to achieve at the end or very late in the game. Maybe tied to the highest level you can reach, or a an effect of the AotFC (wuut, letterwords!). I see activating it more as an effect so I would consider it as part of the class/profession mechanics. Too soon to implement I guess, unless someone wants to have some fun with it eh :)

Talking about fun, I'm cooking up a new set of commits. Hopefully more news later today.

[DebianJoe]

I pushed up a skeleton structure for an "Opening Menu" that is presented at the beginning of a new game. I struggled with an efficient way to manage the transparent msgbox libtcod blitting. If we go to try to implement the "on leveling" option for class evolution, that's going to take some studying to get around. It's not so bad for inventory screens and such, but when you have text over text, it's terrible. I chain loaded the menu_background image to avoid this, but that won't be an option in mid-game unless you create a temporary console. Be sure to pull before you push those totally sweet commits Frost. :ghost:

[wesleywerner]

+1 for a godlike player class. As for simplicity, I found the inventory-item linking a bit confusing myself, I can imagine new programmers would too. That was the implementation from the libtcod tutorial right? Hmm, I don't want to suggest doing it another way, maybe a small doc explaining it would suffice... Will check it out but first I have to hack an idea for another feature... :)

[Frostlock]

@DebianJoe I like what you are cooking up with that opening menu! Looking forward to seeing it more fleshed out. :+1:

Some additional thoughts

• Structure wise I think the menu needs to be in a separate function, also I would call it before creating the player, not at the end of the function where it is now. (I realise this is in an early stage at the moment :smile:) If it becomes a lot more detailed we could even consider moving it to another file. A file for the menu/out-of-game stuff and a file (dungeons.py) for the in-game-stuff. Beware this is my OOP urges coming to the surface :wink:
• open question: Do we have to do everything using libtcod? You could just implement the menu in vanilla python before launching the libtcod... Of course it is nice that it feels like an integrated whole. Hmm the blitting proved a pain but maybe we need to review the approach. I read something about of screen consoles, the way I roughly understood it is that you can use that to keep multiple screens in the background and switch to screens when needed. Guess I answered my own question. Lets try to find a good way to do it integrated with libtcod.

Some feature requests (finally some concrete input :wink: )

• I would like a quickstart menu item as well (generate a random player)
• Ideally we are able to go back a step in the menu by hitting escape, a push-pop stack for the menu progress comes to mind.
• Quiting during the opening menu should be possible, neither the close button of the window or Alt-F4 work currently (but I'm sure you know about this one)

Fun to see this project evolve! :laughing:

[DebianJoe]

The currently implemented menu is more about me playing with getting better at blitting than anything concrete. I would much rather have the call for the menu working as a function that's called after "new game" (eg: actually set in the same area as new_game(), play_game(), around line 1300, if memory serves me correctly.) The system I used there is a super simple "while not window_closed" structure, which should return all of the functionality back for closing the program mid-menu.

Even though I see what you're saying about doing things in vanilla python as opposed to using libtcod, I'm just going to point out that we technically don't have to import "random" as we've already got a rand. from the library. That should make the random character feature super easy. I'm not going to pretend that blitting using it is intuitive, because it isn't. it does allow us to get more nested functionality without importing much more. (You're a Java man, right Frost? :package: <----makes lots these...build house with them. LOL.) On the other hand, we're miles from being unable to run this on even the most basic netbook. That's really the only reason that I tend to try to do the most with the least (it was a big sacrifice for me to use a graphical console at all, as I could have done most of this using a unicode terminal emulator and ASCII + ANSI...but I wanted to learn the lib.) As long as we can run this on a Pentium 3 with integrated graphics, then however we wish to organize it is fine be me.

So are you saying you'd prefer to use sub-consoles in libtcod for the opening, or actually have terminal input to open it, or use another lib that's simpler to make text-menus with than libtcod?

[DebianJoe]

Note: Moved the opening menu into a function, tied it to sequential loading order, and added story mechanism for the "s" hotkey that depend upon racial choice. I also kept the lines under 79 characters, so that KBMonkey would approve. :dancer:

[Frostlock]

Via phone, sorry for typos

Yes Oop and java were dominant at school :-). Also did alot of other stuff along the way some php, fortran pascal, vb and even prolog (brrrrrr)! on the job I spent a few years in a .NET environment but these days I'm no longer developing, which I sometimes miss :-) But yes absolutely more focussed on Oop.

About the question on vanilla python or libtcod. What I tried to say was that it would be nice if it looked all integrated. So preferably in libtcod consoles. I would definately avoid another third party library.

Looking forward to seeing your commits :-) btw did anyone meet the rabbit yet? :-P

[DebianJoe]

I met your rabbit. I died a horrible bloody death from it. My little girl (who does my beta-testing) thought it was the coolest thing ever.

I'll take up trying to get far more familiar with all that libtcod is capable of. Since you two are seemingly working on organizing the portability of the code for future expansion, I'll take up trying to get good at using the graphical portions of libtcod. There's a lot about it that I don't know yet, and I don't want to make anything that you guys are working on more complicated than it needs to be yet. It would be best to work on restructuring the code layout before it keeps growing. During that time, I'll figure out how to do some of the more "fancy" integrated graphical stuff and try to build a few basic structures off of it, like how "msgbox" works. - joe

[wesleywerner]

I met the rabbit, it is so powerful. I got squelched. Need a holy hand grenade to destroy it :rabbit2:

Joe you said you started this to learn libtcod, so that is a good idea to look at the drawing stuff.

Perhaps all the menus need is a nice border and background, like a paper scroll or stone tablet.

[Frostlock]

If you get lucky and save up on scrolls you could blast it. But definately :+1: holy handgrenade :smile:

[DebianJoe]

Closing this out, as we've all pretty much decided to not keep developing this project.