Quote:Original post by Ovan35
The hardest part to me seems to be the dialogue and how to get all the words that have to go into a dating sim in your program without making it super huge.

"Hugeness" must be subjective, because in my opinion, text is not nearly as big as graphical data. You can write a lot of dialogue text and still have a fairly small program. It's the number of images, audio, and animation that can make the program big.

Hmm.. An intriguing genre. Not played many dating sims (well, only played a few mini doujin shoujos)

I know you weren't looking for coding suggestions, but have you looked into Ren'Py?
I've not used it, but I know Katawa Shoujo is being made in it; & since it was designed for graphic novels it may be worth trying it out, or just going over the docs & examples to get an idea of how that kind of code is structured.

Off the top of my head this is how I'd probably lay it out: (my terminology and stuff is probably totally wrong - I apologise)

I'd probably manage the game using 2 key elements - story arcs, & weights:

A story arc would be (as you described in the case of a scenario marker) the stage you were in the game.
Each arc would have its own section of code, & would end by switching to one of several other possible arcs.
For instance: You might have the "intro" arc, would can end with either the "cafe" or "school" arc.
Of course you wouldn't want _too_ many, & there's nothing to say that sub arcs can't rejoin back to main story arcs again (infact they should).
I'd split each story arc into a separate file, & draw out a biig diagram to map out the different ways the story could go.

I would also have "weights" - would could be your emotional standing with the different characters in the game, or rankings in certain areas.
Within a story arc different lines could be read depending on your standing with that character (although the basic layout of the story would remain more-or-less the same), & possibly affect which further story arc you end up with.

Decisions within story arcs which lead to different paths would still be kept within the same arc. I would just use temporary variables to keep track of roughly where you are in that arc.
Arcs would be mostly linear, but with varying sets of lines within, & but the decisions you make inside them would affect your weights, & the eventual destination arc you end up in.

Obviously you'd want a pattern which doesn't get your code too complicated.
I noticed you gave the example of using literal numbers as your scenarios. I'm not sure if this was just you simplifying, or was a thought-trend based on the language you were using.
In C++ I would use classes for different story arcs, that inherit a base interface.
Each story arc class could customise a virtual run() or update() method with different code.
When the arc was due to change I would use something similar to:

if(day_has_ended){  game->arc=new storyarc::Day_2(game);  delete this;  return;}

Upon each update loop of the game object it would run the virtual method in the attached arc property. I would leave arcs responsible for deallocating themselves & allocating new arcs in replacement (it is safe to do as long as you are certain about when access to objects cease).

Apologies if I went off track on that last bit (that may not be familiar territory for you).
But I totally wish you the best, & would love to be updated on the status if this project takes off. (also if you want any technical advice & feel I could be of help)

Quote:Original post by Kwizatz
Seems you're thinking about hard coding your dialog, don't. Instead write code that reads text formatted in such a way as to keep the flow of your game, for example you could use XML.

Actually Kwizatz could be right there. I'm perhaps a bit overly keen on embedding code :P
Take what I said last of all with a pinch of salt & find the mix that works best for you.