DSE game in the works

[Megaman Z]

I'm sorry, Icekiss, but I don't think I can get any pictures.

[mikey]

Well, I gave it a try and it looks promising. Three day options plus one or two sub-options is already dizzying for me ^_^, but you can sort of nicely select what you want and the game unfolds accordingly. No unexpected thingies happened on my Win98, so that's a plus I guess.

The script felt almost exactly like the time I played Transfer Student, I have still a long way to go in DSs, most probably I was choosing the most uneventful actions - happened to me in TS that I just went to school and back and the game ended I wonder how long the full game is going to be though - I'd certainly welcome more happenings, but at the same time when they start to repeat due to daily actions, there could be shorter versions later on.

Anyway, keep up the good work! It's going to be an interesting game once it's done.

[Icekiss]

Thanks a lot for commenting, mikey!

most probably I was choosing the most uneventful actions

Well, since this is more of a techdemo right now, there is not all that much to discover. Mostly just trying all the different actions once or twice, and seeing what happens when you flunk school.
Since I am still developing the engine, it wouldn't be a good idea to have all that much events right now anyway, because I would have to change them all everytime my API changes. They are just there for me to actually see the framework in use, and where things are still to complicated, or the events can't get enough informations to apply to a wide range to situations.

That said, the story that is there will be the founding stone from which I develop the game content, so it's not a placeholder. I do have a concrete idea where I want the first story path to lead to as well. But before that, I'll have to be satisfied with the engine.

It's going to be an interesting game once it's done.

It's not going to be done. It's going to get content. Hopefully enough to not make the daily live boring for quite some time. But it's going to be wide open. I don't intend to provide an ending (except for dying). I want to get others interested enough in the universe to want to tell their own stories in it.
But unlike fanfiction, where every fanmade story diverges from canon, a game has the possibility to integrate all of them. And the possibility to do so is the goal foremost in my mind while developing the engine. What I want to provide is a possibility for a collaborative story.

And unlike 0.3, the current version on my computer is already layered in such a way that you can even step back from the universe I create(d) completely, and just use the engine as a "Super Lotsa Added Stuff DSE".

@Megaman Z: Thanks for telling me. I'll add in backgrounds whenever I get got photographies to process between my fingers...

[PyTom]

It's not going to be done. It's going to get content. Hopefully enough to not make the daily live boring for quite some time. But it's going to be wide open.

A criticism of this, though, is that if the game isn't going to be done, then how do we know when to start playing it? I, for one, try to avoid playing unfinished games (except as necessary to help with the debugging of Ren'Py problems). This is mostly because I dislike repeating large portions of the games, which would seem to quickly grow necessary in an open-ended game that is released more than once.

[musical74]

I'm the same way as PyTom on this...I tend to avoid unfinished games and demos (unless someone asks me for my opinion on it) because I'm not much for *OK this happened and now...*WAIT FOR UPDATE #2* or something like that...I would much rather play a game all the way through and then try a different way - for me part of the fun is trying different things out and seeing what happens if I do B instead of A...demos tend to only have choice A and I like experimenting and trying everything out on a game...that's just me, though

[Icekiss]

how do we know when to start playing it?

Well, it's of course everyone's own decision whether to play a game.
What I am intending to do is to announce when new content has been added, how much, and at least a hint were it starts from (so an informed choice is possible).
Storylines are independent from each other. While they are influencing each other ( e.g. one storyline may result in you gaining a friend, and in another, you might do something together with your friends ), you won't have to complete one just to see the other.

So basically you just have to restart the game, and discover the new story path (e.g.: Talk to a crying girl, read a certain book in the library, ask a person a specific question... Since everything is multiple choice, it shouldn't be too hard to discover those entry points).

I still have the hope of figuring out how to make it possible to carry over your old save to a new game version with new content. The problem is that currently the objects aren't initialized in "init:" sections. I'd have to figure out a way to place them there, and create any objects not appearing in the save game...
(And of course this will only work once the engine is stable)

What I have in mind is basically a bunch of stories told in the same universe. How many stories do there have to be before you start reading? Do you reread the ones you already know to more fully enjoy the new ones? Do you start reading before you are sure there won't be added any more to this universe?

In terms of games, I would say that online rpg's do something similar: There isn't an "end", but new content is added, and all you need are directions to the new area.

[PyTom]

BTW, when is this project going to get a name? It's somewhat confusing to not have anything to refer to it as.

So basically you just have to restart the game, and discover the new story path (e.g.: Talk to a crying girl, read a certain book in the library, ask a person a specific question... Since everything is multiple choice, it shouldn't be too hard to discover those entry points).

Saying it's multiple choice isn't really much of a reassurance, however. Multiple-choices can get big pretty quick. I mean, if you have three days, three periods per day, and two choices per period, that's already 512 paths. A fourth day gives 4096, a fifth give 32768. In a week we've passed 2 million paths, and in fortnight it's 4,398,046,511,104.

Now, games manage that complexity, but it's important to explicitly do so, as otherwise it can quickly grow out of hand.

I still have the hope of figuring out how to make it possible to carry over your old save to a new game version with new content. The problem is that currently the objects aren't initialized in "init:" sections. I'd have to figure out a way to place them there, and create any objects not appearing in the save game...
(And of course this will only work once the engine is stable)

Hm... Right now, Ren'Py isn't really set up to produce the game you're trying to make. I can probably help out some by adding an after_load_hook, that lets you update the data structures after a load, but that only gets us part of the way.

But really, you need to consider writing your own load/save system, if inter-version compatibility is important. Ren'Py does include quite a bit of support for compatability of changed scripts using the same Ren'Py version, to handle the case where there's a bug in a script. But changes to Ren'Py itself can break load/save compatibility.

There's also a problem of how to distribute a changing game. The current method of extracting a new dse directory isn't ideal for a released game. (This is a problem all episodic games share, and it's not really one I know how to handle well.)

What I have in mind is basically a bunch of stories told in the same universe. How many stories do there have to be before you start reading?

As little as one complete story, but there does have to be a dramatically complete story there. It doesn't have to be completely conclusive, but I would like to know that if you get hit by a meteor the day after I read it, I won't be left hanging for the rest of the story.

Also, it would suck if you got hit by a meteor. Just making that clear.

In terms of games, I would say that online rpg's do something similar: There isn't an "end", but new content is added, and all you need are directions to the new area.

Hm... I think a difference is that VNs/DSes are more story based, while a RPG is more based on the fighting and so on... Then again, I've never played a MMORPG, so I wouldn't know.

[Icekiss]

BTW, when is this project going to get a name?

Most likely while I outline the first storyline. Because at that point I have to pin down the universe, at least in my own head. Earlier if I have a good idea.
But I can christen the game engine right now: SLAS-DSE (aka Super Lots Added Stuff DSE). How about that? *grins*

Saying it's multiple choice isn't really much of a reassurance, however. Multiple-choices can get big pretty quick. I mean, if you have three days, three periods per day, and two choices per period, that's already 512 paths. A fourth day gives 4096, a fifth give 32768. In a week we've passed 2 million paths, and in fortnight it's 4,398,046,511,104.

I'm not sure what you are getting at. If I would make the discovery of an entry point dependent on a specific path taken from the beginning of the game, I would be completely insane.
All you will have to do will be: take a certain baseaction a few times.
Example: I give the hint that there is a new story path starting in the library. So you start a new game, and study at the library. And the third time you do so, the librarian starts a conversation with you.
And even if you didn't have that hint, you'd probably have gone to the library thrice during the first week, and would notice the conversation that wasn't there before anyway...

I can probably help out some by adding an after_load_hook

After having thought about it some more, yes, this is exactly what I would need. With that, I will be able to get to the state where only Ren'Py itself can break load/store compatibility.
And if I correctly understood you, Ren'Py's save/load compatibility breaks if I saved a data structure that changed. The only data structure from Ren'Py I save (that I can think of) are Character objects. When I tackle the whole load/store problem, I'll search for a way to avoid even that, without making things to complicated for event scripting. I rather like being able to write "tim 'Hello!'" right now... (and that only works because GameChar subclasses Character *sigh*)

Circumventing Ren'Py save/loading entirely, on the other hand...
That's a thought that doesn't appeal to me at all. I like to think that the system that is already there is way more sophisticated, and battle-tested, than anything I could write myself in a reasonable time frame.

There's also a problem of how to distribute a changing game. The current method of extracting a new dse directory isn't ideal for a released game.

Once the game has real content, I'll provide normal downloads (i.e. renpy+game). That means that save games have to be copied over, but big deal.
I know there are more elegant methods, like providing a download option from within the game, but that is way to sophisticated for me.

Also, it would suck if you got hit by a meteor.

That's good to know. Thanks!

VNs/DSes are more story based, while a RPG is more based on the fighting and so on

I know there are differences between the genres. Otherwise they wouldn't be different genres, now would they.
The preconditions to make such extensions work, are that the engine has it's own understanding of the game world, and that the character has the ability to explore. And those are fulfilled in both DS's and RPG's. (While VN's don't match them)

[PyTom]

And if I correctly understood you, Ren'Py's save/load compatibility breaks if I saved a data structure that changed.

No, that's not true, really. It breaks when _any_ data structure that is saved changes. The problem is, there are a number of Ren'Py internal data structures that are saved in the save file. One example of this is the object that keeps track of the currently playing music. That'll be changing drastically between 5.0 and 5.1, and so 5.1 will not be save-compatible with 5.0.

Unfortunately, I don't know a good solution to this problem.

[Icekiss]

@PyTom: Ah well, I'll just have to live with it. And on the gripping hand, I can use those times to break binary compatibility myself. I am sure there are always things that will come up...

@all:
I'm looking for a few opinions. I spend the last days implementing everything to display Characters in a flexible way (among other things). I have separated the actual drawing code from the events.
All the events do, is tell the engine who is there, and what mood they are in.

While going through the events and inserting this mood information, I tried to assemble a list of sensible facial expressions. Here is what I have right now:

Code: Select all

        #Moods
        createAppearance( 'thoughtful', None        , 'mood' )
        createAppearance( 'smiling'   , 'thoughtful', 'mood' ) #when happy or encouraging
        createAppearance( 'sad'       , 'thoughtful', 'mood' )
        createAppearance( 'tense'     , 'thoughtful', 'mood' ) #when expecting danger
        createAppearance( 'very_happy', 'smiling'   , 'mood' )
        createAppearance( 'wistful'   , 'smiling'   , 'mood' ) #when imagining or wishing
        createAppearance( 'apologetic', 'smiling'   , 'mood' )
        createAppearance( 'smirking'  , 'smiling'   , 'mood' ) #when saying something ironic
        createAppearance( 'evil'      , 'smirking'  , 'mood' ) #when enjoying revenge
        createAppearance( 'crying'    , 'sad'       , 'mood' )
        createAppearance( 'frowning'  , 'sad'       , 'mood' )
        createAppearance( 'startled'  , 'tense'     , 'mood' )
        createAppearance( 'sighing'   , 'tense'     , 'mood' ) #when exasperated
        createAppearance( 'determined', 'tense'     , 'mood' )
        createAppearance( 'unsure'    , 'tense'     , 'mood' ) #when asking a question or not understanding
        createAppearance( 'sceptical' , 'unsure'    , 'mood' )
        createAppearance( 'intense'   , 'determined', 'mood' ) #when bringing forth a strong argument
        createAppearance( 'angry'     , 'determined', 'mood' )
        createAppearance( 'repulsed'  , 'angry'     , 'mood' )
        createAppearanceClass('mood', 'thoughtful')

Every line defines a facial expression, and what it defaults to if no specialized picture is available.
Example: "createAppearance( 'smiling' , 'thoughtful', ..." defines the facial expression smiling, and that it defaults to thoughtful (meaning: If there is no picture that shows the Character smiling, he is shown thoughtful instead). By the way: "smiling" is better than "happy" because you can smile for different reasons, but the facial expression is always the same.
On the other hand, often the name for the facial expression and the mood are the same, so that's what it gets called then.

What I'd like to get input about:
-Are there any important expressions missing?
-Can you see better ways to organize the tree? (Ideal is, if the tree is neither too flat nor too steep, so that the most can be made out of any provided picture, and if the defaults keep as close as possible to the actual expression)
-Can you think of better names (like smiling instead of happy).

I can't really have 'too many' expressions in this list, because they don't consume much processing time, nor do they take up much space. But having nearly identical ones in different parts of the tree is of course dumb as well. And there is no need to clutter the tree without reason. After all, one has to scan it from time to time to check which expressions actually exist.

I don't have many events now, so it's no big deal going over them and refining the expressions. But I would like to get this list finalized, so that that isn't necessary once there are hundreds of events.

So, input, anyone?