Dev Log 004 - triple penetration and code talk

Holy crap you guys I'm excited to be working on this again. I kept convincing myself all my patrons would abandon me because of the lull in updates, but my Patreon is actually still growing! :'D

<3 to you guys. We'll make this game happen. It'll happen hard. 

Er, anyway, in the last couple of days I wrote a system capable of switching between any configurations of multiple penetration. It looks clunky right now, but it'll polish up. Huzzah!

Also there'll be a playable build soon, probably! I'm rethinking the gameplay and structure, so progress might make the game uglier for a little while.

#clopgamedev time! (I'm making this a thing)

tl;dr games are hard

Okay so I've been real busy, but I think that was good for me. Being forced to step away from LC's code gave me some time to consider one of the two constant problems I run into with this game: structure.

Structure is a real meanie. Let's start with the basics of R34 game design and work up from there.

Most R34 games are a sequence of animated scenes. You click the "Next" button and the next animation plays. It loops until you click "Next" again. When you click "Cum", the orgasm animation plays, and a restart button appears. There's often variation, including buttons to swap out a character's skin or clothes, or maybe a slight branching structure to the scenes. It's easy to hold this structure in your head.

If you're interested in making a game like this, try it! You animate the scene in Flash, usually with a lead-up animation and then a loop. Loops are made by putting a line of code on the last keyframe that says "go_to_frame(#)" (this is pseudo code). You add a "Next" button with similar code, or a bit of logic, and make the game transition to the next scene. Rinse and repeat. Learn about how to jump to specific frames, how to switch out one sprite for another, and a little about checking variables, and you have the tools to make your game.

On to LC. We need to have a player with multiple stats tracked. We need three orifices and a way to generate unique dicks to fill them. We need to swap those dicks in and out in unpredictable configurations without breaking scene. We need to track stats on the dicks too. We need multiple player characters, RPG-like upgrades, dynamic dialogue... and suddenly, it's a lightweight indie game. God help me.

So how do we structure it? Some things are easy calls to make- we need a Player class to track stats, handle animations, etc. We need a Lover class to instantiate for each dick. I made a Slot class so that each orifice can act as a logical in-between for the Lover and Player classes. I abandoned Flash for animation and code - they were too restricting. Instead I use the FlashDevelop IDE and Spine2d for animation.

This seems simple so far, but it gets complicated quick. Who handles what? Does the Lover have a thrust() function that decides to play each thrust animation? Or does the animation just play, and send an event to everyone every time a thrust is completed? Whose responsibility is it to handle a Lover engaging/disengaging from a Slot? And... uh oh, Lover animations and Player animations technically have to be the same set of animations, because that's the only way I can figure out how to make a penis go into the player, rather than clipping in front of or behind her. So now the Player's animation holds Lover animation logic. And oh, crap, when the Lover disengages from the Slot, whose responsibility is it to check and make sure his disengage animation is done? The Slot? The Lover? The Player, because it's actually her animations playing?

There are actually a few more pieces in this puzzle that I left out. The Lovers line up in a Queue, which has a UI element. There's a Hotbar with Items, which have to be able to interact with the Slots in the same way as Lovers. There's the game Stage that contains all these elements, and it catches events bubbling up from them, which means an additional route that information has to travel through, further muddying the logical clarity of the game's structure.

Here's what started all of my thoughts on this: My latest release of LC had a couple bugs when you tried to restart the round. If a Lover was engaged with a Slot when you triggered the Collect sequence, his Slot and Queue were having trouble resetting everything when the round restarted. Fixing it was a pain in the ass. Despite my attempts to put together a simple Lover -> Slot <- Player structure, I'd made small adjustments to handle all the additional complexities I described above, to the point where I simply couldn't find the set of functions I'd written to properly disengage the Lover.

I felt like an idiot for that, but it was just a symptom of a larger problem: My own conceptions about how to logically design these systems weren't based on experience. The Player-Slot-Lover idea makes sense on paper- you have two entities interacting, and a Slot in between to handle that interaction. I'm pretty sure this actually is a good approach, but it's missing the greater context of games are complicated.

To any serious game devs out there, this is basic stuff. As a programmer, but not an experienced game developer, I've had to learn the hard way. There are no tutorials on how to handle clipping in penis-in-bodily-orifice animations. Not many games center around a stationary player with no shooting, physics, or puzzle elements. I've learned every nugget of knowledge by smashing through the process blindly. It's a messy and amazingly fun process. And there's an ever-present danger-

You either under- or over-engineer your solutions to the problems you encounter. If you do something quickly just to get it done and release a playable build, you might find that it can't handle the next feature you want to put in. If you methodically plan it out and try to make it modular, it might end up overly complex and fuck you over in ways you hadn't considered. It's an eternal balancing act of getting it done vs doing it "smart".

So where are we now? I realized that, while Starling is a great rendering framework, and Spine is a great animation tool, I need something that will provide me with a logical, consistent structure. I need a game engine. Enter Citrus, an AS3 game engine that can render with Starling and utilize Spine animations. A game engine has its own ideas for how you structure your game, and gives you tools to solve common problems so you don't have to create every solution from nothing. So far, this has been a positive move, and easier than my switch from Flash to Spine.

So there you go. LC is now being built on a Citrus-Starling-Spine stack.

I'm changing my approach a bit, too. Instead of a set feature path, I'm trying to build every planned feature as early and as quickly as possible. It means the game might not be pretty for a while, but I'll have a basic foundation upon which I can add content. I'm also secretly hoping that by the time LC is solid enough to start adding new characters and art, my Patreon will be doing well enough that I can afford to hire a skilled artist :3

I mentioned way at the top of this that structure was one of two consistent problems with LC. The second is gameplay. It's what I'm working on right now, so I think I'll dive into it in the next dev log.

That's it for now, folks! <3