Behind the Curtain 1
Wed 6 Jul 2016
I'm going to start with the "That New Game by Fugue" short episodes again once I get past this part of the "Dr Diggler" work. Parts are tedious, and I don't want to lose track of my place, so I've been putting all my extra hours toward Dr Diggler, even the ones when I'm supposed to be chilling in front of the TV. Or doodling up images for TNGbF.
(Oh, and by the way, I didn't change the "Contest of Wills" scenes radically, but I did revise them so that they should be just a little more visually interesting now :) See revised version above, and old version below. Sorry, I couldn't help myself from trying to improve slightly on those scenes.)
We're coming up on almost a year that I've been trying my hand at games and graphic-novel works, so it's not a bad time for a small bit of reflection on what has and hasn't worked well, at least with the way I compose such works. This will be a little more technical, sharing what I've found for anyone else that is interested in trying their hands at this. For those that just want to keep the magic of the story, feel free to skip this and pay no attention to the man behind the curtain :)
A Lot Less Drawing Re-Use than Expected
When I started this, I expected to make a huge amount more use of common images. Don't get me wrong, I do carry the same image forward over multiple pages, but nothing like I expected.
I expected to have .PNGs for, let's say, a table. And the background setting. And perhaps a chair, and for Dr. Diggler in this pose, and for Trish in that pose, for example -- and then to just position and overlay the .PNGs to assemble the final image. I figured a lot of work would go toward keeping track of which component image was what (e.g. this is Bryan smiling and facing front; this is Bryan smiling but looking left; this is Bryan scoffing; this is Trish leaning back in a chair instead of sitting up; etc.). I expected multiple outfits could be overlaid over Trish, as long as both the outfit and she were in the exact same pose.
Well, overlaying multiple component .PNGs into the final image for a page sorta went away when I revised Ganesha (the javascript engine I use for these iStories, and eventually to be made freely available) from version 1 to version 2. At that time, I changed it so that instead of having a semi-consistent size for the main image at the top of the page, it lets you scale the hell out of it. Well, that blew "overlaying component images" all to pieces -- after positioning the component images for a particular sizing of the browser, resizing the browser jostled everything about so that things were not in the right place anymore. Trish's pretty dress is mostly still on her, but hovering a quarter of an inch towards her right -- yikes! Things like that definitely break story flow/game flow.
At this point, I do still have background "setting" .PNGs (e.g. Trish's bedroom, Diggler's office, the B&W Shoppe, etc) that I use in the background. But all the foreground components for each scene are "baked" into a single .PNG that overlays the background "setting" .PNG.
Others may have better luck than I did with overlaying component .PNGs, especially if they use different tools, but I just wasn't able to get it to work right with the effort I put into it, so nowadays bake all the foreground objects into a single .PNG for each scene.
A couple more Behind the Curtain observations to follow in the next post ...
(P.S. Hmm, if I were going to try the "overlay component images" route again, I think I would make every .PNG a fixed size -- say 800x600, even if it's just a little hat that Trish is wearing or just a book that Bryan is carrying. Things might all scale consistently then. But instead of having to track component images by what they are (Trish's dress1 or dress2 or bikini1) and their pose (this is Trish's dress1 in a sitting position instead of a standing position), you would also have to track them by their position in the final image (this is Trish's dress1, in a sitting position, but not on the left or center of the image, and not 75% of the way toward the right, but 80% of the way towards the right). That's sort of making tracking all the component images more effort than they might save ...)
Behind the Curtain 2
Thu 13 Jul 2016
The image attached is a teaser screenshot of a scene I'm working on in Dr. Diggler, part of Patricia's modeling a bikini for Bryan in level 2.
Below is more of the sharing of technical things I've found out over the last year, for those interested in trying your hands at writing games too.
I'll have another teaser screenshot or two in a few more days for you guys! The story's getting fun now that we're starting to loosen Patricia up a little.
Fugue
Game State is Multi-Multidimensional
Game state is obviously multidimensional. If the whole game just went from state 1 to 2 to 3 etc., it would be a pretty boring game.
I originally thought I might track game state as a set of sequential state variables, perhaps per character or per situation. For example, Alice, the university brainiac might first of all snub our hero; after that, she might get caught sneaking out of Dr. Diggler's office after a quickie; after that our hero might catch her sneaking out of Diggler's office half-dressed, in just jeans and a bra; etc. Or our hero might catch Alice in the B&W lingerie shoppe initially; the next time he visited, he might catch flat-chested prof. Gatsby; next time, he might catch Alice getting exposed in public a little by Dr. Diggler; etc.
However, even that -- a set of N linear variables -- gets messy for the kinds of games I want to write. In the above examples, I might not want the B&W Shoppe variable to reach the 3rd state (Alice getting publicly exposed) until after the Alice variable gets to state 2 or 3 (i.e., she ought to get caught sneaking out of Diggler's office before he publicly exposes her in the B&W Shoppe).
For me so far, at least, tracking the cross-feed between the N linear variables out-weighed the benefits of using linear variables. So I've switched to just using binary variables (i.e., has this event occured in the game yet or not?) and a significantly larger number of them. I won't promise I'll stay with this "big set of binary variables" approach, but so far it's working better than the "N linear varaibles" approach.
Feel free to comment if you have other approaches to maintaining game state!
Behind the Curtain 3
Wed 20 Jul 2016
Attached is a screenshot of upcoming Diabolical Dr. Diggler ver. 0.6. In this arc, valiant, heroic, and, uh ... yeah, pushy, Prof. Digby takes a stand against the lewd behavior of Dr. Diggler's harem of bitches. Hmm, wonder where that's going to get her ...
Below is more reflecting on Fugue's path to game enlightenment. My game engine is a lot like Ren'Py, and this quickly touches on why -- but feel free to skip if not interested.
More teasers and a couple more reflections on the Path of Gaming to come soon ...
Fugue
I Like Ren'Py's Approach
This is strictly personal preference -- everyone will have their own game preferences, but I happen to like the approach of Ren'Py (https://en.wikipedia.org/wiki/Ren%27Py). First of all, the first game that caught my attention that games can powerfully tell a tale was Akabur's (http://www.fuguetales.com/blog201607.html#) Princess Trainer, which was written in Ren'Py (and Akabur did a memorable job with it!).
Second of all, I come to these games and iStories from a writing background, and Ren'Py seems to emphasize the story and plotline more than a lot of other game/interactive fiction engines. I think many other engines might have more complex visual effects (though Xaljio (http://www.fuguetales.com/blog201607.html#) teases some amazing effects out of Ren'Py itself!), but I still like the story emphasis.
There are two aspects of Ren'Py that I didn't like (and thus have written my own engine, Ganesha, that I'll release in a few more months, free for anyone wanting to write their own game/istory; and you can rest assured that it is not a theoretical engine, but has been use-tested on hundreds (probably more like thousands) of pages of istories by the time it is released).
First, Ren'Py DOES have a little bit of a peephole feel, what with proceeding through narrative and dialog just a single line at a time. I wanted to be able to show several lines, a short paragraph or two, at a time. I also wanted to color the text according to the speaker. Ren'Py lets you include a small image of the speaker by the line of dialog, but not every screen has that image, and colors just seem to make it clearer who's speaking (at least to me).
Second, Ren'Py requires the player/reader to run an unverified executable (or at least a python program, even if you're somewhat expert), which makes a lot of people nervous these days in the age of malicious viruses. HTML5 and Javascript/jQuery have made browsers much more powerful, still with an emphasis on a safe sandbox to trap/prevent the spread of most malicious code. So with most of the power, better emphasis on security, and certainly widespread general use, the browser is an attractive place to build a game engine.
This is why I describe Ganesha as being like "paragraph-oriented javascript-based Ren'Py" when someone wants a one-sentence description.
Behind the Curtain 4
Tue 26 Jul 2016
Since I'm working on the sequence in the Dr. Diggler game where our heroine Patricia models hose and gloves (and nothing else) for Bryan, I'm really wanting to show you guys a screenshot from there :)
BUT ... I already started the discussion last post about Prof. Digby daring to get a little pushy and self-righteous with Dr. Diggler. How did that work out for her? Wellll ... see attached. (Compare to her previous image from the last post, before she started to irk The Dig, if you'd like.)
Hmm, not so well ...
There's one more piece to the outfit that she has to wear (in order to learn her lesson not to bug Dr. Diggler, of course). I'll post that next time, and probably a hose-and-gloves image the next post after that.
Another reflection on game-making follows below. As always, read further if interested, or just enjoy Prof. Digby's comeuppance if not.
So Far the "Index" Idea is Proving Useful
For the last Dr. Diggler release, I had the idea to organize little plotlines in the game as "errands", and to have an Index page in the game that showed you the ones you've completed (with links to revisit), and a count of how many still remain undiscovered. So far, I'm liking this minor technique -- it's accomplishing three purposes.
First, it shows players/readers what still lays in the game to be discovered. This is especially important considering the way I want to release games in fairly frequent cycles. If you've already played the previous version of the game, how do you know where the new content lies? The index page helps a lot with that.
Second, it lets players/readers revisit sequences they've already visted. If you've already had Patricia model the naughty teddy for you, and you just like a couple of the images, or the plotline there, you SHOULD be able to go back and replay that sequence if you've already made it past that in the game. The Index page let's you easily revisit errands you've made it through.
Last, it also provides a "safety." With multiple releases of the game, it is possible that a bug could slip through in one version, where the player could get trapped in a series of pages that just repeats because of the bug. So far I don't think that has happened, but it's just something that worries me, that it ever could. So in previous versions, I left an "escape hatch" link over on the menu bar that you could click to jump to the main AM or main PM menu, just in case you get stuck in a little Fugue accidental version of Groundhog Day. With the Index page, multiple such "escape" links are always open for players.