Follow-up

Apparently 3d studio max 9 exports properly. This is disheartening, as it ties me down to either an older version of the software, or running two of them. Le-suck.

Oh well, at least this means proper animations might actually happen.

Argh. Well, I am at least certain what the issue with my animations is -- the finger bones aren't being positioned correctly in the base skeleton. Well, they are in 3d studio max, but not once they're exported via OgreMax. Thus, when the hands/fingers are animated, the bones' position/rotation offsets aren't correct.

Now for the big question: Why.

I suspect an issue with OgreMax.

Animation Woes

Progress -- and a point on which I am stymied today.

Did some work on the level format loader -- added in the ability to parse cameras and lights, for one. And to define some physical properties of objects in the scene. So the basics of level formats is in place -- I'll just need to work out how to handle some special cases (things like, say, a security camera. No, really. How awesome would it be to have security cameras in the level that render what they see to a texture -- which can then be displayed on a monitor in game or somesuch [The same computers which could, say, load up a web site to display.])

Still having issues with animations -- not that I've messed with it a great deal in a while.

(Slightly NSFW image after the cut. If, you know, this being a blog about a sexytimes game didn't really imply that boobies might show up.)

Mapping!

One issue I keep running into time and time again with the production of this game is my inability to produce quality art resources. It's unfortunate -- and due to the nature of the game, I am hesitant to ask for assistance in this regard. Perhaps later, when I have enough put together to actually post a download and really release it into the wild.

Been pondering how I want to handle the map. Currently, I'm using a section of the mall from Dead Rising, extracted from the game itself. The mesh isn't ideal for my purposes, though, for a couple of reasons -- though the layout is pretty spot-on to what I'd like to do. There doesn't appear to be any pre-generated collision meshes or anything, nor am I certain how the game handles NPC navigation.

Time for a Little Blathering

I know, I keep making blog posts but nobody's even aware this exists, so they aren't seeing it. Kind of makes you wonder what the point is, eh? Sometimes, I just need to braindump, and this helps. This is one of those times.

Firstly, I've been wrestling with what I want to do with stats and mechanics -- I want them to be present, I know. I feel like a game of the sort I'm going for needs some kind of character advancement. It's one thing to be slowly transformed into a bimbos, cow girl, or whatever and another thing to be able to increase your character's strongliness or stamina or whatnot.

Which brings me to an interesting point. Tempestreturns over on the TF Games Site forum made a comment in a thread about their own game, HERS-3X, that the health stat implies physical challenges, and having events that affect your health was getting too close to violence, which they don't want to write about in a sexytimes game. Reading that particular point in the post was kind of a 'well, duh' moment for me. It's one of those things that makes perfect sense, so why didn't it occur to me before? When I ponder what gameplay would be like in Bimbpocalypse, here, I lean a little too close to mimicking Dead Rising, I think. Wading through a crowd of bimbos and wailing on them with a baseball bat is probably not very appropriate for the overall theme of the game -- it's supposed to be sexytimes.

Wee!

The more I fiddle about with BEPU Physics, the more impressed I am with the library. It's written in .NET, so I already have a strongly-typed, managed way to access it. It's thread-safe, and has its own thread manager. It took me something like 10 seconds to set up multi-threading in my little test scene. About 10 more to have BEPU updating completely asynchronously from the render queue. 100 active crates? 280 FPS (which is kinda low -- but this is with an idletime rendering queue, rather than a dedicated render loop. A dedicated render loop would, no doubt, run much faster, but make it more difficult for me to let the OS handle mouse/window events. Perhaps that is an experiment.) 200 active crates, and another 60 inactive? 230 fps.

The only downside I can really see is its inability to serialize/deserialize mesh data. Granted, it allows for the creation of arbitrary meshes, I can't help but feel like pre-serialization would lower loading times -- passing the mall scene so far straight in is detrimentally slow. I've not actually had the patience to wait on it, but some of the chunks were taking 3 or 4 seconds apiece to generate a physics representation.

Granted, throwing some 350,000 vertices at it (among like 80 meshes) is a bad idea in general. The more I think about it, the more I can't help but feel like some sort of editing tool is warranted. Something that would allow me to configure a level layout, define/generate physics properties, etc. And some sort of actor studio, to let me make some preset configurations for NPCs or somethin'.

WE SHALL SEE.

(No, really)

Decided to take a brief break from working on the game, as I'd run into some issues with memory management. That turned into me getting distracted by life in general, but I'm getting back into the swing of things again.

Memory management is still a bit spotty at the moment. But I did implement a basic SSAO manager which has, like, no discernible effect at the moment. It seems to just kind of darken everything unilaterally. Will need to play around with it more -- and disable the skybox when it does its lighting pass.

Working on implementing some simple physics. I know, I know. Every game these days uses a physics library for no reason. But, you know, I really do like the idea of the player stacking some heavy boxes in a door to keep it shut or something. Emergent gameplay like that is all-but impossible without at least a basic physics simulation.

Moral of the story: No real progress, but code is hitting the table. And everything just keeps growing. Stupid textures directory.

Customization!

The next real step in setting up the engine for this game is to get characters walking around in the level. To that extent, I need to solidify my character asset workflow.

Since I'm using Oblivion's character setup, I at least eliminate the need to come up with that. It also opens up a slew of tools that already exist to make this easier on me. Notably a program called FaceGen. FaceGen can generate pretty believable face meshes and textures (and some not-so-believable), as well as process a photo or three to try and reproduce an existing person's noggin. You can even set up your own base models to use for the heads, and someone set one up for Oblivion's races -- it even exports very very close to seamlessly to my body mesh. There's a slight seam along the neck where it doesn't line up quite right, but it is very close. I can fine tune it some later. Or, at least, the seam will very often be disguised by clothing.

Still a-going

Not a whole heck of a lot to show off this time around. Some stability issues have been squared away, and I've just about removed the game's dependence on GUI elements being packaged with the application's resources and, instead, it draws them from the same resource archives it draws meshes and level data and whatnot.

This way, there is a single repository for almost everything that's displayed in the game. Currently, the splash image that shows is still embedded in the application repository, as that needs to be called before MOGRE and its resource management system has been instantiated. That is, in fact, the point of the splash logo. To display while these systems are initializing and loading, so the user knows that yes the program is launching. It just takes a few moments to load everything up.

Woo!

I feel accomplished. A few material tweaks, to improve alpha blending on the billboard-esque bits, fixing the UV coordinates on a couple of meshes.

Got a HUD system in place. Essentially, the in-game menu and HUD uses Awesomium to display an HTML page for GUI elements. Yes, it's me being a bit lazy in regards to making GUI elements interactive. Awesomium can handle javascript and CSS3, etc. Means I don't have to worry too much about hit testing and scripting elements and juggling overlays and all that jazz.

I don't have to touch the GUI handling code anymore, just tweak the HTML that handles it, woot!

Also in the process of setting up some basic character controlling. This necessitates some game resources sooner-or-later, and I'm trying to get an easier work flow for setting up the resources. I'd love to find a NIF plugin for 3d studio max 2010 64-bit. I've, thus far, been too lazy to compile one myself. Or I could work up my own character bit setup tool, I suppose. Read up on the NIF and KF formats (They're both file formats used by the GameBryo engine that Bethesda uses. NIF is for mesh data, and KF is for animations.) and make my own tool to import parts and export them as OGRE Meshes.

The most tedious part of this is the NIF importer for 3d Studio Max doesn't seem to be capable of handling multiple animations. So to set up different animations on a skeleton, I'm having to import an animation, export the whole skeleton, convert it to XML, and copy+paste the transformations for that animation into a combined skeleton XML, then convert that skeleton to binary. Tedious! TEDIOOOOOOUS.

Either way, have a screenshot: This time, the mall so far in-game:

In the interest of showing off the game's progress, here's a quick render of a potential protagonist/NPC.

Things are, in fact, progressing!

Unfortunately, at this stage in the game (ha ha, see what I did there?) it is really difficult to show any real meaningful progress. Suffice it to say that the core framework of the game is in place -- that is the basic rendering systems are in place, and I've got my state management and input management implemented. Going forward, I'll actually be implementing things in the game that are much easier to show off.

I am, however, still waffling about actual gameplay mechanics. I picture the game playing much like a survival horror type game -- the player is stuck in a mall, and must venture out of their nice, safe, not-very-well-stocked back room in order to find food, water, and potentially other survivors. All-the-while, they must brave the sex-crazed vixens that occupy the mall and want nothing more than to throw open their legs and fuck until the player is one of them.

La la la

Taking a break from fighting with the Dead Rising level data -- the whole point of ripping that was to plug in a temporary mesh and continue on, not to bog me down for a few days.  I can get the mesh and whatnot to load,  but there are some major z fighting issues that I can't seem to wrangle.

I might roll back to a simpler test level model, unfortunately.

Started working on code to set up characters.  A single character in the game will be comprised of a set of meshes -- currently one for the torso and arms, one for the hands, one for the legs and waist, one for the feet and some number for the head (I am as of yet undecided on that.  Likely one for the structure of the head, one for the eyes, one for the ears, then one for hair), as well as a skeleton that handles animating the body parts.

At least it's importing well!  Still working on the specifics to linking each segment of the body to the skeleton and animating it, but it's nice to see some boobies.

Because I feel bad ...

... about not having fancy-pants pictures in the last post:

Willamette's Parkview Mall

I might have spent the last couple of hours ripping the map data from Dead Rising.  What better to serve as a placeholder level for a mall apocalypse game than ... a mall.

Musings on AI and Events

As I work on getting some placeholder assets in, I'm brainstorming just how I want gameplay to go.  As far as 'enemy' AI is concerned, I'm leaning towards a memetic, event-driven, scalable system.  That's a lot of buzzwords.

A 'memetic' AI is comprised of a series of memes.  A meme is a transferrable behavior (also a funny cat picture).  Memetic AI works wonders for instinct-driven, or mindless actors.  Memes are self-contained, encapsulated behaviors.  Things like:  Forage, Patrol, Chase, Flee.  Actors can pick up behaviors from their neighbors.  In practice, it is likely that each AI actor in the system will use a weighted decision system, and the memes its neighbors are performing will weigh more heavily than others.  In other words, in a group of bimbos, if one flees the others are slightly more likely to also flee.  If half of them flee, then the remaining are very likely to also flee.

What do I mean by event-driven?  At certain points through the game, things will happen, of course.  Dead Rising is actually a fairly good analog of what I'm planning.  At certain points throughout playing either game you get a call to tell you something's going on in some part of the game world.  These are events, of course.  In Bimbpocalypse, an event might be a busted water main in the main corridor, or another survivor shows up holed up in a shop.  Each event will be more-or-less self-contained, and should show up at semi-random points in time to keep the game dynamic.  Events will have a set of criteria dictating when they are able to show up, however, so that their contents can be more tailored to the current state of the game.  Is your character female, and dealing with a bit of a lactation problem?  Perhaps there's some sort of milk farm event that might fire in such a situation.  This ties into my next point.

Scalable AI?  Inspired by the 'AI Director' Valve used in the Left 4 Dead games, a scalable AI is simply one that alters the difficulty of what's going on based on metrics used to determine how well you're doing.  These metrics will likely be rather broad -- if you're low on health, high on lust/arousal, getting pretty far along in one or more transformations, low on food/water, then you are doing poorly.  At this point, the game should decrease the chances of spawning a bimbo horde to come terrorize you, and increase the chances of you finding edible or potable things.  Alternatively, if you are doing well then maybe it's time to knock you off your high horse.

Mixing the scalable AI director with a system of events lets us do some interesting things.  Because then our events can react to how well the player is doing as well as the state of the game.  HOOLAY.

Work Begins

Progress!
I've established a basic state machine and rendering engine, based on code I've done in the past.  I'm working on ripping off converting some Oblivion assets to use as placeholder meshes, until such a time as I can either A) make my own (I'm not a terribly amazing modeler, trust me) or B) Find someone to do so.

Sample character mesh with rigging.

Why Oblivion?  The theme of the game isn't quite right for what I have in mind, but there are a bajillion mods already out there and the mesh and animation formats are well-documented.  Additionally, there are already tons of adult-oriented mods, adding some sexytimes animations or various body shapes which will be useful in development of Bimbpocalypse.  Also, one of the commonly-used skeletons for character animations really covers the bases as far as bones go.  It includes arms, legs, fingers and toes as well as bones to animate a tail, two separate sets of bones to cover two styles of wings, nodes to attach weaponry/items, and bones to animate a skirt/dress and hood.  And hair.

So, wee!  Things happen.

Main menu WIP shot

Welcome!

Welcome to the development blog for Bimbpocalypse!

What is Bimbpocalypse?  Well, Bimbpocalypse is a survival game of an adult nature.  Yes, this means there are sexytimes in the game.  You play the role of a survivor trapped in a mall after some sort of civilization-destroying event turns most everyone else into a hyper-sexed bimbo.

Think:  Zombie apocalypse mall, but with vapid, sex-crazed wimmenz instead of brain-eating zombies.

The game will feature several methods of transformation, as the Bimbo condition is infectious in nature.  The nature of the game, then, becomes to survive unchanged (or as unchanged as possible).  Perhaps you hole up in an abandoned restaurant, living off of the nonperishable food stores.  Perhaps you raid the nearby shops for water -- is it safe to drink?

Will you succumb to the bimbo horde?