WhoreMaster: Abby's Crossing

[DocClox]

[edit]

Changed the title to reflect the content of the thread a little better

Been messing around with pygame and PGU. I wasn't too impressed by Ren'Py when I looked at it before. I mean it's excellent if you're writing a VN, but seemed a bit of a pain if you needed to add a lot of actual game to the text boxes.

So I thought I'd have a try with pure Python. Well, Python and Pygame and PGU. I'm finding it a LOT easier to work with than C++ and the WM codebase

So far I'm just learning how to make widgets and the like.  I've had way too much fun making that viewscreen: the slider slides, the little lights change colour randomly, there's three to five frames of random snow when the image changes... that sort of thing.

Next thing probably is to look at Python's XML handling. I'd like an XML based container for screen layouts, and I want to be able to read the XML files for existing girl definitions. If I can get that far might look at porting some of the code from standard WM.

It should go without saying, but no promises or deadlines for any of this. I'm just messing around at the moment.

[Xela]

Ren'Py does offer the simplest scripting system for events for modders imaginable. Also it comes with most of the tools required to make a game like WM.

but seemed a bit of a pain if you needed to add a lot of actual game to the text boxes.

What do you mean exactly?

=======
In any case, please take a look at PyTFall before starting a new design all together (especially in Python), there's been a lot done already and we aren't really working off a concrete concept so development is really flexible.

[DocClox]

Ren'Py does offer the simplest scripting system for events for modders imaginable. Also it comes with most of the tools required to make a game like WM.

Well yeah,if you want to do mainly narrative and dialogue with supporting graphics then it's wonderful. The sound support is very nice too. But the dating sim/gui/forms plugin didn't strike me as particularly easy to use, and looked like a bit of a nightmare if you wanted your own layout and your own look and feel. And the python integration seemed fiddly if you wanted to do more than keep track of a few variables. That might just have been me, though. My python wasn't as good as I thought it was back then.

Mainly though, you're talking about taking a framework optimised to do narrative and dialogue and using it to make a forms based business sim.  I reckoned I'd end up doing most of it in python and pygame anyway, so why not cut out the middle man?

Of course, that's just the way I see it. YMMV and all that.

In any case, please take a look at PyTFall before starting a new design all together (especially in Python), there's been a lot done already and we aren't really working off a concrete concept so development is really flexible.

It's a bit awkward, really. Between your name and avatar, you put me mind of a poster called exodia with whom I had a full and frank exchange of views back when WM was in active development. I appreciate that the similarity is probably pure coincidence, but it makes it difficult to collaborate for all that. 

As for PyTFall, it looked like a cool project when last I looked at it, and I wish you well with it.

Really though, bottom line is I'm just messing around at the moment.

[Xela]

Well yeah,if you want to do mainly narrative and dialogue with supporting graphics then it's wonderful. The sound support is very nice too. But the dating sim/gui/forms plugin didn't strike me as particularly easy to use, and looked like a bit of a nightmare if you wanted your own layout and your own look and feel. And the python integration seemed fiddly if you wanted to do more than keep track of a few variables. That might just have been me, though. My python wasn't as good as I thought it was back then.

That sim plugin does suck... that's why we don't use it

Python integration is as good as it gets (it's basically 100% integrated). Couple of modules has been deliberately left out as not required for game making, but they can always be added later.

Mainly though, you're talking about taking a framework optimised to do narrative and dialogue and using it to make a forms based business sim.  I reckoned I'd end up doing most of it in python and pygame anyway, so why not cut out the middle man?

Of course, that's just the way I see it. YMMV and all that.

Mainly because middleman offers a good amount of widgets, multi-platform support, packaging, failproof serialization system and easy scripting for modders... Doesn't really get any better than that. PyGame is a good choice as well, but it just seems like you're creating a lot of extra work for yourself.

PS: If not RenPy, have you considered Python + Qt as an option? It might have more to offer than PyGame.

It's a bit awkward, really. Between your name and avatar, you put me mind of a poster called exodia with whom I had a full and frank exchange of views back when WM was in active development. I appreciate that the similarity is probably pure coincidence, but it makes it difficult to collaborate for all that. 

As for PyTFall, it looked like a cool project when last I looked at it, and I wish you well with it.

Really though, bottom line is I'm just messing around at the moment.

Name is for Alex (reversed) as it was already taken. Good luck messing around, tell me if you change your mind, we could always use some assistance

[DocClox]

That sim plugin does suck... that's why we don't use it

I'm glad it wasn't just me then

Python integration is as good as it gets (it's basically 100% integrated). Couple of modules has been deliberately left out as not required for game making, but they can always be added later.

mmm... I was more thinking of the $ prefix for embedded python and the various init blocks and how nothing seemed to be scoped the way I expected it to be scoped and a load of little things like that.

I expect the problem goes away if you ignore the Ren'Py DSL and just use it as a Python library. But  a lot of the appeal of Ren'Py lies in that DLS and the simplicity of it all. So if you lose that, you lose a lot of the appeal.

Mainly because middleman offers a good amount of widgets, multi-platform support, packaging, failproof serialization system and easy scripting for modders... Doesn't really get any better than that. PyGame is a good choice as well, but it just seems like you're creating a lot of extra work for yourself.

Well, Python offers multi-platform support, packaging and scripting. I've not looked at serialisation yet, but I can't imagine it's difficult, knowing python. The widgets are nice, but I find I like working at low level, and I enjoy the control you get that way. And nothing kills a game atmosphere faster than standard widgets to my mind.

Name is for Alex (reversed) as it was already taken. Good luck messing around, tell me if you change your mind, we could always use some assistance

Well fair enough. I'll have a bit think and get back to you.

[rudistoned]

Hi there!


That's a nice screen you created there


pygame
I tried it about two years ago and really didn't like it. The documentation was poor, the API felt unpythonic and I didn't find a nice GUI toolkit to go with. The GUI toolkits I found were incomplete and often poorly documented.


packaging

Python offers multi-platform support, packaging and scripting.

No argument about multi-platform support and scripting, but packaging? I'm pretty sure with "packaging" Xela meant creating an .exe, .deb or other binary/installer from the game source so your players can run it easily without having to install dependencies. The best way to do this that I've found so far is to use PyInstaller. I also tried py2exe and cxfreeze some time ago. All of these options may create problems when you try to package libraries, especially more complex toolkits like Qt or GTK. It often is doable, but it's far from easy IMHO.


serialization

I've not looked at serialisation yet, but I can't imagine it's difficult, knowing python.

It's not
*) The best XML library is ElementTree, unless you want to parse XML files that are too big to keep them in memory.
*) For JSON: import json
*) To serialize native python objects pickle works great. Unless you want to get close and personal with the pickle protocol, I would advise against trying to pickle instances of classes inheriting from standard data types.
*) For easy, human-readable object serialization, including custom classes, PyYAML works nicely.

I wrote some pretty generic ressource loaders which might be of interest to you. Look for the RessourceMap class and its descendants here: http://sourceforge.net/p/pytherworld/tags/ci/default/tree/resload.py


custom widgets

The widgets are nice, but I find I like working at low level, and I enjoy the control you get that way. And nothing kills a game atmosphere faster than standard widgets to my mind.

Well, IIRC renpy implements its widgets in pure python, so you can take as much control of them as you want, right?

Another option for widgets with a customized look is to take a mature GUI toolkit like Qt and reimplement the paint methods of the widgets. After all, why should you implement all the boring, technical details widgets need to handle when all you want are widgets that look non-standard?


Pytherworld
I've been working on a reimagination of Otherworld, implemented in Python. The GUI is based on Qt and lately we've been talking about adding 3D graphics. Koffii is currently working on that.
Maybe we've created something you can use or are interested in? The discussion thread is over at the Otherworld forums: Pytherworld discussion
Pytherworld's code is on Sourceforge: Mercurial repository


paperdolls
Did you write the paperdoll code for Otherworld? Just so you know: Daisy lately talked about breaking the current system and reimplementing it to fix some issues with the scaling and positioning of the dolls. This would also mean that all items have to be repositioned. I've tried to convince Daisy to just fix the bugs causing the scaling and positioning problems, but I'm not sure I succeeded.
It would be a shame if Daisy actually decides to break the current implementation because I know the structure of the XML is not the problem. I implemented Otherworlds paperdolls in Python and they work very nice, no issues with scaling.

[DocClox]

Hi there!

Heya Rudi! How goes?

That's a nice screen you created there

Thanks. I think my fondness for steampunk and art deco is probably showing

I tried it about two years ago and really didn't like it. The documentation was poor, the API felt unpythonic and I didn't find a nice GUI toolkit to go with. The GUI toolkits I found were incomplete and often poorly documented.

You're not wrong about the latter In fact I'm more using PGU, in particulkar the GUI module. It's still not fantastically well documented, but I think I'm getting the hang of it. If I could just work why it renders a one pixel seam two thirds of the way across my nice mahogany background, I'd be really happy.

packagingNo argument about multi-platform support and scripting, but packaging? I'm pretty sure with "packaging" Xela meant creating an .exe, .deb or other binary/installer from the game source so your players can run it easily without having to install dependencies. The best way to do this that I've found so far is to use PyInstaller. I also tried py2exe and cxfreeze some time ago. All of these options may create problems when you try to package libraries, especially more complex toolkits like Qt or GTK. It often is doable, but it's far from easy IMHO.

I was faintly planning on using py2exe, but I'll take your warning to heart. I'll also look at PyInstaller

serializationIt's not
*) The best XML library is ElementTree, unless you want to parse XML files that are too big to keep them in memory.
*) For JSON: import json
*) To serialize native python objects pickle works great. Unless you want to get close and personal with the pickle protocol, I would advise against trying to pickle instances of classes inheriting from standard data types.
*) For easy, human-readable object serialization, including custom classes, PyYAML works nicely.

Using ElementTree (the lxml version) and I'd heard of pickle. PyYAML sounds useful, too

I wrote some pretty generic ressource loaders which might be of interest to you. Look for the RessourceMap class and its descendants here: http://sourceforge.net/p/pytherworld/tags/ci/default/tree/resload.py

Thanks. I'll take a look.

custom widgetsWell, IIRC renpy implements its widgets in pure python, so you can take as much control of them as you want, right?

I'm sure.  I mean, don't get me wrong, I'm not knocking Ren'Py. I spent a few days playing with it, got confused, decided the
forms plugin wasn't very good and then got distracted by something else. This time I thought I'd try using pygame, looked at the GUI options and decided that PGU was probably closest to what I wanted.

I will admit, I never considered using Ren'Py as a widget library. Maybe I'll give it another look. I did want to have a fairly strong story in  this outing, so the VN aspects would actually be quite useful.

Another option for widgets with a customized look is to take a mature GUI toolkit like Qt and reimplement the paint methods of the widgets. After all, why should you implement all the boring, technical details widgets need to handle when all you want are widgets that look non-standard?

Yeah. More or less what I'm doing with PGU

Pytherworld
I've been working on a reimagination of Otherworld, implemented in Python. The GUI is based on Qt and lately we've been talking about adding 3D graphics. Koffii is currently working on that.
Maybe we've created something you can use or are interested in? The discussion thread is over at the Otherworld forums: Pytherworld discussion
Pytherworld's code is on Sourceforge: Mercurial repository

Oddly enough, I came across an very early version of Pytherworld just the other day. I have to confess I didn't know you were still working on it. I guess I should check in to the Otherworld forums more often I'll have to have a look. It was a cool idea and I'm glad it's still going.

paperdolls
Did you write the paperdoll code for Otherworld?

Guilty as charged

Just so you know: Daisy lately talked about breaking the current system and reimplementing it to fix some issues with the scaling and positioning of the dolls. This would also mean that all items have to be repositioned. I've tried to convince Daisy to just fix the bugs causing the scaling and positioning problems, but I'm not sure I succeeded.

I keep promising Daisy I'll do some more work on Otherworld, but I never quite seem to get to it. The dolls were always a bit fragile though.  In principle it should be dead simple. In practice ... there's probably a lot to be said for a rewrite, really. I'll stick my head into IRC and talk about it.

It would be a shame if Daisy actually decides to break the current implementation because I know the structure of the XML is not the problem. I implemented Otherworlds paperdolls in Python and they work very nice, no issues with scaling.

I think the scaling issue in Otherworld was because I used a lot of relative placement, which meant that the various parts have different origins. That means that when you scale the whole, all the bits transform around different points and everything separates. Thinking about it, it should be possible to transform all the items to use a common origin after positioning. Or better yet, before. That should solve the problem.

I should also add that (after year or so in the wilderness) I finally found myself paying employment this week. So my spare time is going to be limited for a while. On the other hand - money! - so that's ok

[rudistoned]

Heya Rudi! How goes?

All's fine, thanks. Congratulations on your new job! Good luck!

I was faintly planning on using py2exe, but I'll take your warning to heart. I'll also look at PyInstaller

To be honest, packaging external libraries so I can distribute my software has always been my biggest problem with Python development. Everything else was more or less smooth sailing (or my own fault...).
This goes so far that packaging a new library is the first thing I try when I consider if I should use it in one of my projects.

Using ElementTree (the lxml version) and I'd heard of pickle.

Is the lxml version better? Never tried it myself.

I'm not knocking Ren'Py

And I'm not trying to promote it (that's Xelas job ). I don't really like it myself, but it is a good engine with quite a few things to offer.

Oddly enough, I came across an very early version of Pytherworld just the other day. I have to confess I didn't know you were still working on it.

Came across? Did people upload it somewhere?
The current version still is in an early stage of development, especially from the looks of it. I spent quite some time with other projects and rewrote it from scratch once to fix some early design flaws. Now it is going quite well IMHO. I think what sets Pytherworld apart from other projects at this point is the dynamic image matching. You can give the game a set of parameters describing the image you want and it will find the image closest to your search criteria most times.

I think the scaling issue in Otherworld was because I used a lot of relative placement, which meant that the various parts have different origins. That means that when you scale the whole, all the bits transform around different points and everything separates.

I know. I had to play around a while to reverse-engineer how exactly your XML positioning and scale info was meant to work, but I think I got it in the end.
I do think that the way you built that XML is the best way to do it. For example, positioning all doll parts from the same origin would be awful. Adjusting the position or size of any part for any reason would mean all parts attached to it would have to be repositioned/rescaled too.

[DocClox]

All's fine, thanks. Congratulations on your new job! Good luck!

Cheers muchly

To be honest, packaging external libraries so I can distribute my software has always been my biggest problem with Python development. Everything else was more or less smooth sailing (or my own fault...).
This goes so far that packaging a new library is the first thing I try when I consider if I should use it in one of my projects.

Sounds like good advice to me. Also slightly worrying, since I'm doing most of my dev work on Linux again. Oh well, that's what dual boot and virtual box are for

Is the lxml version better? Never tried it myself.

It's about the same, with a couple of added extras and a couple of security holes fixed. I read on the Python wiki (I think) that the ElementTree that shipped with python was exploitable with malicious xml. Not a huge problem for what we're doing, of course, but I thought I'd use the secure one in any event.

And I'm not trying to promote it (that's Xelas job ). I don't really like it myself, but it is a good engine with quite a few things to offer.

I might end up using it yet. The other night I found that PGU had started adding 60 pixel invisible borders to some of my screen elements,  for no reason I could make out. So I've been looking at some of the other possibilities. I thought I might have gone with Tkinter until I found that it can't cope with transparency in widgets.  So I'm currently playing with PyQt. I keep meaning to look at how Xela is using renpy, but every time I start to install mercurial, something happens to distract me at the moment.

Came across? Did people upload it somewhere?
The current version still is in an early stage of development, especially from the looks of it. I spent quite some time with other projects and rewrote it from scratch once to fix some early design flaws. Now it is going quite well IMHO. I think what sets Pytherworld apart from other projects at this point is the dynamic image matching. You can give the game a set of parameters describing the image you want and it will find the image closest to your search criteria most times.

Sounds cool. I think the version I have is the initial proof of concept you posted on the otherworld forums. I've not seen it posted anywhere else, certainly.

I know. I had to play around a while to reverse-engineer how exactly your XML positioning and scale info was meant to work, but I think I got it in the end.
I do think that the way you built that XML is the best way to do it. For example, positioning all doll parts from the same origin would be awful. Adjusting the position or size of any part for any reason would mean all parts attached to it would have to be repositioned/rescaled too.

Yeah, the relative positioning seemed the only sane way to do it. There is a good case for flattening the image once it's built, of course, and keeping the actual doll off-screen. That would solve all the scaling issues, at the expense of making it a little slower to change clothes. I know I thought about doing that - I might have even done at some point... but I have this nagging feeling I've forgotten something important about that.

[DocClox]

PyQT seems to be working out quite well. I've reimplemented the old pygame ones and got a bit further into the bargain/



I've got all the elements of the main screen in place. The layout needs a little love in places, and some of the widget seems a little too bright. I'd also like to make a little more space under the viewscreen for a brass box containing a rotating paper drum which I can use to print status messages and the like. Oh, and obviously most of the buttons do not yet work



But in general, I'm quite pleased with what I've got so far

Next things are a suitably themed message box to mkae a brothel name does in fact get entered, followed by a some basic game data handling, save/load, and loading some girl data.

[edit]

The dialogue didn't take long to make, anyway

[Xela]

Nice

What is the plan by the way? I mean if you get this out of "messing around faze", where are you planning to take the design?

[KaiSakurai]

he is aiming to program a new WM version completely outdating the former versions and with it conquering the internet world!
........
.......
......
just kidding xD
but looks great so far =3

[DocClox]

Nice

Thanks

What is the plan by the way? I mean if you get this out of "messing around faze", where are you planning to take the design?

Well, at the moment I'm trying to restrict myself to reproducing the basic functionality of vanilla Whoremaster, if only to keep me from charging off and tilting at windmills. That said ...

The initial idea behind Abby's Crossing was as a sequel of sorts to the original WM.  The PC (who may or may not be connected to the PC in WM) arrives in a new city with the intention of extending the franchise by setting up a chain of brothels.

The city in question is Abby's Crossing: a minor trading city built at the junction of three desert trading routes. Not the wealthiest city in the Empire, but far from the poorest, it seemed like a good place to start. As well as trade, the city tends to attract scientific and technological arrivals in Mundiga. Sadly, science doesn't work too reliably in Mundiga, so there's a heavy reliance on steam and clockwork and other early industrial techs, which give the place something of a Steampunk character.

Of course, it's never that simple. What the PC doesn't know initially is that Abby's Crossing was founded on a terrible secret, one which will shortly come back to haunt the city. And as is the nature of such things, the PC will have a chance to be at the centre of those events and to exercise some influence over the final resolution.

In game mechanics terms, a more limited slave supply, more tech and less magic, a different story to "avenge your father's murderers" and a bit more developed story, with some named NPCs with whom to interact, maybe some events and/or quests beyond the simple generic objectives in WM.

[edit]

he is aiming to program a new WM version completely outdating the former versions and with it conquering the internet world!
........
.......
......
just kidding xD
but looks great so far =3

heh, cheers!

I'm absolutely not trying to conquer anything with this one, but I'm glad the look and feel seems to be working.

[Xela]

So basically the plan is to mimic WM's functionality in Python and add more story/gameplay elements?

[DocClox]

So basically the plan is to mimic WM's functionality in Python and add more story/gameplay elements?

It sounds dreadfully unambitious when you put it in those terms. But yes, I suppose so. With a side order of learning Python and Qt and a lot of fun making steampunk widgets with Inkscape