Advice on making a dating sim

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.

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.

That's what she said? ;)

Quote:

"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.

I see your point there pictures do take up more space as far as data.So you don't think it's bad form to have code that's super long then?And is the case approach the best way or is there another way of doing it that's better?

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 Ovan35 I see your point there pictures do take up more space as far as data.So you don't think it's bad form to have code that's super long then?And is the case approach the best way or is there another way of doing it that's better?

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.

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.

Quote:

Original post by Kwizatz Quote: Original post by Ovan35 I see your point there pictures do take up more space as far as data.So you don't think it's bad form to have code that's super long then?And is the case approach the best way or is there another way of doing it that's better? 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.

And if you want to get really fancy, you could use a scripting language to separate the 'dialog logic' from your base application code too.

And if you want to get really, really, fancy and are using something like xna where it's fairly easy to make a content pipeline extension, you could make a custom pseudo-scripting language where you control all of the elements and attributes and control how it interacts with your game through a reader class. GL!

I would use (XML) XPath for the content, then all the 'real' program has to do is loading and displaying some files or strings returned by the XQuery-proccessor.

Or if you want to get REALLY fancy, you could add an awesome 3D engine to it, and support all of the latest video cards and shaders and it would be SO EPIC!

I agree with things like not having your dialog hard-coded, but keep yourself focused on the end goal. Don't make it complicated for yourself.

Quote:

Original post by Valkoran Or if you want to get REALLY fancy, you could add an awesome 3D engine to it, and support all of the latest video cards and shaders and it would be SO EPIC! I agree with things like not having your dialog hard-coded, but keep yourself focused on the end goal. Don't make it complicated for yourself.

Other than in case there is no 3D content to be displayed nor is there a need for higher framerates then 2D accelleration can give you - unless maybe you write a vector graphics proccessing vertex/fragment pipeline programm to relay the rasterization to the graphics processor and save some CPU cycles...

Furhtermore, every real dating sim player knows 2D friends is superior to 3D ones.

One of the things you might want to do first is simply draw a flowchart (or rather an activity diagram) that shows all conversation and action flows.

That way you will findout what is needed in text and what kind of decision logic you need.

And indeed, do not hard code the dialogues. Find a way to transform the flowchart and text into code. By hand or automatically. That will make it a lot easier to maintain the game.

[Edited by - ernow on January 5, 2010 11:59:23 AM]

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.

My fault for not keeping up on this thread I guess.Well I was thinking about hard coding because I didn't know of another way.I looked around the site and saw someone mention LUA files which I think is something like what you were thinking about.I'm not sure how to do XML but I am willing to learn it.

Quote:

Original post by ProPuke 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

I actually have ren'py.But I wanted to learn how to program one.Call me a glutton for punishment.I wanted to start small and it seemed like a generally easy project dealing with putting pictures , text, variables and if statements.

Quote:

Original Post by ernow One of the things you might want to do first is simply draw a flowchart (or rather an activity diagram) that shows all conversation and action flows. That way you will findout what is needed in text and what kind of decision logic you need. And indeed, do not hard code the dialogues. Find a way to transform the flowchart and text into code. By hand or automatically. That will make it a lot easier to maintain the game. [Edited by - ernow on January 5, 2010 11:59:23 AM].

Makes sense.I did write out some of the dialogue.But already from what I wrote I can see that it could get messy if you don't keep track of the story flow.I appreciate everyone's input.I'm going to take a look at how to get XML files into mt game project for starters.

a quick defense of my earlier post about using a content pipeline extension is that it allows you to create a personal pseudo scripting language. This means that you don't need to learn (or be fixed into) the rules of xml coding and instead focus more on your game. You can define your own custom format and the reason that I bring it up is that I think that learning how to extend the content pipeline is a fairly simple process and is well worth it (for a lot more than just xml files). I didn't mean to suggest an unnecessary amount of work, just helpful advice. However, using a text file approach I think would be more suited to your current needs. Do what you think you can and then (as long as you don't have a timeline/budget) branch out learn as much as possible. Once Again...GL!

Most definitely do not put the onscreen text into the game code -- it must, must, MUST be in a separate file (or multiple separate files).

Quote:

Original post by Nick0523 a quick defense of my earlier post about using a content pipeline extension is that it allows you to create a personal pseudo scripting language. This means that you don't need to learn (or be fixed into) the rules of xml coding and instead focus more on your game. You can define your own custom format and the reason that I bring it up is that I think that learning how to extend the content pipeline is a fairly simple process and is well worth it (for a lot more than just xml files). I didn't mean to suggest an unnecessary amount of work, just helpful advice. However, using a text file approach I think would be more suited to your current needs. Do what you think you can and then (as long as you don't have a timeline/budget) branch out learn as much as possible. Once Again...GL!

I wasn't writing you off.I think XNA is a pretty good program with enough reference material and books to help you figure out how to do something if you don't already know how.I wanted to use Dark GDK because of the simplicity of getting pictures, music and other media to play in your game without much in the way of programming knowledge.The problem with Dark GDK is that there isn't much material on it if you're trying something new(like adding xml files for example).I did look into it and alot of people from The Game Creators site suggested TinyXML to parse with.From what I can find there's only a few tutorials on the web and far fewer books on the subject.So XNA might be a good choice.

Quote:

Original post by Ovan35 I wanted to use Dark GDK because of the simplicity of getting pictures, music and other media to play in your game without much in the way of programming knowledge.

I was recommending xna just because its something that I'm familiar with and I didn't think that you said what you were trying to use any particular language or devkit and if you did earlier I apologize. That said, I'm not recommending one over the other. If you want to go with Dark, I would definitely say that incorporating resources is easier. I'm not too familiar with that devkit and so I don't know how you would go about doing something like this but definitely go for it. Just learn about file I/O. Just because you want to add scripting doesn't mean that it has to be xml based. A text document will work with a little effort (though due to decision making conversations, it would probably have the same feel as xml). Put your mind to it and you can get it done.

P.S. I do think that while adding images/textures into xna is fairly simple, doing anything remotely complex with music (like not just adding a background playlist) is a little overcomplicated. However, it can be done if you feel like spending half an hour playing around with the 10 different sound data types and finding a structure that works, even if it gets a little brute force.