A new vore game - Small Tech Demo

[ImaginaryZ]

How about some better examples, so ya'll understand what I said (I sure hope you've played these games, or seen em...)
(Prerendered 3D + pseudo 3D style, 2D game)Donkey Kong Country
(Next Gen Texture Tiles in 2D, pseudo 3D)Odin Sphere
(3D levels + 2D sprites)Mischeif Makers
(2D levels + 3D/2D characters)The new Super Mario Brothers DS
(2D/3D levels + 2D/3D characters)(youtube)The New Super Mario Brothers Wii

As a side note, "2.5D"(Note the ambiguity and inexactness of the article) originally referred to 3D styled arcade games using 2D sprites to simulate depth, like Teenage Mutant Ninja Turtles, Pole Position, The Simpsons Arcade, and probably many many more very successful titles. Be sure to clarify what you mean by "2.5D" with examples, since the term itself has no set meaning. Just like any good industry buzzword, eh? XD

BUT!

I was thinking of the last option, the 2D/3D levels and characters. A orthogonal perspective (see bold wii mario bros link) was what I was thinking, not "2.5D". I prefer characters to be 3D, since that makes vore animations way easier and much more flexible + detailed. Plus, adding 3D model support does not 'force' the game in either direction; It could still just as easily use 2D sprite based animation as well as 3D animations. In fact, since JfishSoM is badass enough to be using OpenGL, OpenGL is ALREADY fully 3D + 2D at all times, so to be technical, the game is 3D already. (In other words, the same calculations are used when in 2D mode as in 3D mode, its still projection * modelview matrices. '2D' is a orthogonal projection matrix rather than a perspective projection matrix.)

The result? We'll have to see what JfishSoM decides.

-Z

[Elle]

Hrmm, you make good points, of course. 3D characters would be fine in a 2D world, as it does look nice and all. I've made both 2D and 3D animation systems as well, so that wouldn't be too much of an issue on the coding side. What this whole project hinges on right now is the artwork, and as it's Kiyoa's idea that we're working with while at the same time Kiyoa is the one doing art, I'd say that the title of lead designer/lead artists would probably go his way.

I'm going to have to talk with him about that, of course, since I do think he has some 3D art that he's worked on before. However, I don't know if it'd quite fit the...style that was planned for this project. Here's the thread that had his drawings: viewtopic.php?f=79&t=16339 Actually though, Kiyoa was mentioning that Odin Sphere was one game that he liked, if I remember correctly. I personally don't know what's needed for something like that, but if we could figure out how exactly they do the work, I think it'd work pretty well for us. =3 Still, gotta talk with Kiyoa. X3

[ImaginaryZ]

The way Odin Sphere's animations work is exactly like http://www.bit-blot.com/aquaria/ 's animations (I've hacked Odin Sphere a little to figure this out, and I bought Aquaria), but unlike Aquaria, Odin Sphere / Muramasa can swap UV coordinates and 'tiles' during an animation, which pretty much requires a custom animation program. It's most similar to flash animation, and I call it 'UVS' animation since it is only 2D alpha tested texture quads with the ability to change UV coordinates as well as rotate, scale and distort. Imagine a normal 3D armature flattened; That's really all it is.

The problems with UVS animation systems is that they require the artist to make a empty 'armature' and ultimately paint broken apart pieces, like a front thigh, front leg, front foot, front toes, and so forth, then move them around to connect them as joints. This is similar to how most any generic 2D animation program works; so the obvious limitation is the tenacity of your artist; If they are willing to make more pieces, the end animation looks better. If not, it looks shitty and would have been better as static frames. UVS animations are custom per creature, so doing swaps with other morphology's is generally not possible. It also means that your GPU may be taking a harsh load with the alpha blending, so you may have to be careful with how much of it you use (be creative with using your depth buffer/shader and alpha test; drawing front to back solves this problem to a high degree)

The benefits are UVS systems are immediately intuitive and super simple to code, requiring nearly 0 work on the programmer, most of the load is on the artist. They can be re-used in other projects, and are a common type 2D animation. They are certainly very quick to update with new animations, and since they are made of pieces some effects can be performed on them to shock and awe your audience (IK systems, exploding bodies, weird warping distortions, ect...). Also important is the ease of adding things like 'grapple targets' and 'weapon attach points' and other 'nodes' to your animation, thus allowing the artist to more finely control detailed animations (like vore!)

Make sure that both you and your artist completely understand the 'art format' you are intending to use, including it's limitations and how it works! That's caused problems for me on a few occasions.

Another side note, and something I experimented with a little in Blender, is using a fusion of the above techniques and actually making a '2D' mesh that is stuck on a 3D armature (the picture in this post should explain it) . Code wise, it's just a 3D model that has the vertex data sorted by a 'zlayer'. It's pretty stupid simple, and has more limitations than a UVS system since it is difficult to animate changes in texture or mesh shape (using blender 2.48 that is >.<) but it is at least a start in helping you develop your own ideal animation system. Note that if you use a UVS system, you'll be needing to make your own animation editor, simply because there isn't one out there that'll do what you need. :/

Till next time!

-Z

[Elle]

Alright. o.o I'll tell Kiyoa to start working on making fingers and toes first. *nodnods*

X3 Kidding aside though, that's pretty much how I figured they were doing it, or it was my first guess at least. I believe that some of the enemies are 3D though. They just didn't look quite...2D... Still, Kiyoa and I were talking about something like that. It seemed to me that occasionally they swapped out one arm for another and so on, which it seems was right. =P Still, like you said, it's going to take a bit of work. X3 We might have to see if we can get some good animators in here. That way, Kiyoa can just draw the stuff and someone else can make it move. =P Hopefully it'll all work out. ^-^

Oh, and I keep forgetting to work on that tentacle! o.o *schedules that for tomorrow*

[ImaginaryZ]

Here's an example to make it crystal clear for both artist + programmer:

(And no, all the enemies in Odin Sphere are 2D; They just have amazingly detailed textures! AKA: 2048 x 2048 pages )

[kilaa0007]

great blog

[doomdog91]

actually, to make a website for free you could go to http://www.50megs.com just sign up and create your website, although the free sites have ads and banners, but you can get rid of those for a year for around 20 dollars, oh and you can have as many domains as you have email adresses

[Elle]

Mhm. And then you pose them and animate them through keyframes I would guess, interpolating the various skews, rotations, and so on from one frame to the next. So really, it ends up kind of like many 3D animation systems, which is cool. =P Also, since you're not making a full frame with every piece in it for every single keyframe, but rather a series of pieces and positions for them, it should save a lot of space when it comes to assets.

Interesting that none of those creatures were 3D, of course. They did some amazing work. o.o

[randomer]

Hello there, I've took a small look at your program. Seems you're off to a good start. There were a few things I thought you may wish to change though before your next build (it'll improve performance slightly).

In your main loop, you call glLoadIdentity and then your scene drawing function. In your scene drawing function you have

Code: Select all

... draw_scene_function(...)
{
   glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
   glLoadIdentity();
...


The first call to glLoadIdentity (the one in the main loop before the call to your scene drawing function) is made unnecessary by the second one above.

Also, when exiting the program, you should be sure to free any allocated memory (free(...) and delete, etc) and release all the drawing contexts.

For example, perhaps consider putting

Code: Select all

wglMakeCurrent(NULL,NULL);
wglDeleteContext(rc);
ReleaseDC(hWnd,dc);
/* where rc is your return of the call to 'wglCreateContext'
   and dc is your return of the call to 'GetDC'
   and hWnd is your return of call 'CreateWindowExA' */


somewhere before your WinMain function ends.

You may also want to watch where you put your glPushMatrix and glPopMatrix calls. You may forget that one of them is inside another function.

Perhaps if you're using 2d graphics, try using glVertex2i instead - it will reduce the number of bits that's being pushed onto the stack and will improve performance on slower computers.

An alternative to using the following

Code: Select all

glEnable(GL_TEXTURE_2D);
...
glDisable(GL_TEXTURE_2D);


is, slightly nicer,

Code: Select all

glPushAttrib(GL_ENABLE_BIT);
glEnable(GL_TEXTURE_2D);
...
glPopAttrib();


This way, if you enable anyother opengl flags then you wont need to trail on to the end of your code to add a glDisable(...) all the time.

Also, instead of using a loop of GetAsyncKeyState to get each key state, maybe look at GetKeyboardState ( http://msdn.microsoft.com/en-us/library/ms646299(VS.85).aspx ) which gets all keys at once into a nice buffer, for example

Code: Select all

BYTE keys[256];
int index;
...
for(index=0;index<256;index++){
   keys[index] = (BYTE)GetAsyncKeyState(index);
}
...


would become

Code: Select all

BYTE keys[256];
...
GetKeyboardState(keys);
...


I look forward to seeing this project of yours progress.

[Elle]

Hrmmm, well, I just threw this together pretty quickly, to tell the truth. =P Most of the code is a mish-mash of bits from old projects, so I guess it could use a bit of cleaning. X3 I'll take those into account. =3

Also...I didn't post my code anywhere... Were you using a program to figure out what function calls I'd made? o.o


ImaginaryZ: I was just wondering if he had a more...humanoid sprite part set that we could look at as reference. That, and I wondered if you'd ever seen a program for animating these sprites. I'm almost definitely going to make one of course, but once again, references would awesome. =3

[randomer]

I had a small peek at the assembly

[Elle]

I figured as much. X3

[Xen]

I gotta say it's got a nice feel to it. and the lid animation actually felt really nice.

Now if you can keep up the quality through the iterations you'll be okey dokie

As far as sprite animations go I have to say that I'm almost always incredibly impressed with Konami's work on the Castlevania series. They have nice, smooth character animations, and all but pioneered the multi-piece monster sprite animations.

And yeah, if you look at sprite sheets, I think all of them but order of Ecclesia had the protagonist animated frame by frame. No joint separations, no funky rotation tricks, just dedicated tedium.

And even Ecclesia only used piece-edits for things that had the same pose, but a different hand action...

I'll see if I can't dig up Shanoa's sprite sheet, brb edit inc.

EDIT here it is. Uber spritegasm.



EDIT EDIT A 'simpler' sprite sheet



And a nearly primordial sheet.



As you can see, sprites are nothing to make light of. Even if you did animate piece by piece, You're doing pretty much the same amount of work, and the result will probably look like crap anyway, at least, from what I've seen. It takes a really talented animator to make either method work.

[Elle]

Hrmm. o.o Well, thanks for those. =P I think they'll definitely come in handy if we're trying to make simple 2D sprites. However...I was thinking the sprites would be larger and more detailed, as well as probably adding in the Odin Sphere dealie. Hrm...but larger and more detailed does mean that you'll have less space on the side where you can see... I guess we'll just have to see. Thanks, in any case. =3

And I'm still wondering if there are any sprite sheets for humanoids like the ones out of Odin Sphere. X3

[randomer]

I can give you some tips and a hand at cleaning and speeding up your code if you'd like, pm me. But I can understand that you may want to keep the source code you make to yourself :3

Edit:
Also, ImaginaryZ's idea of splitting a rendered model into parts which can be animated is a really good one. The pros against the likes of sprite images obviously being that the animations aren't based on fixed image data and so can be customised easily 'on the go' (eg during runtime usage with a 2d rag doll system). Also, because the parts are based on a skeletal structure, the animation data could (and should) be stored separately meaning that other characters could inherit these animations with little need to open up ms paint and pixel-by-pixel alter everything. The cons would be that you actually need to be able to make these sheets in the first place which aren't as simple.

Best of luck

[Kiyoa]

Xen,

At the scale of the sprites were likely doing, the 'dedicated tedium' route probably wouldn't work. As for it looking like crap, looking good or bad depends on how well we can implement it.

I'm not expecting it to be anything other than difficult, but frankly it will allow us to implement certain things much more easily than if we were to come up with sprites for every animation. I'm definitely aware that in order to make this work that I'll need to do more than just just make a bit for each part, that this will require some animating before the animating (if that makes any sense). And while I also admire Konami's recent spriting efforts with the Castlevania series, we're going to almost certainly be working on a larger scale, which, again, seems like it would render this method more practical.

I'm not really sure what else to say. Sorry if I came off as a bit abrasive.

[Elle]

I can give you some tips and a hand at cleaning and speeding up your code if you'd like, pm me. But I can understand that you may want to keep the source code you make to yourself :3

Thanks. At some point, I'll probably open up the source code to the masses, but not quite at the moment. =P I'd rather not have others messing with my code while I'm trying to write it. X3 Too many cooks in the kitchen, you know? =P But, of course, what you suggested probably sped things up a little. I know I definitely don't like the whole 'set up' phase of making a game, as there's so much fairly complex code that you don't often write at that point. As you could see, I skipped freeing the window and all since shutting down the process tends to do that for you. It might not be perfectly correct, but it works 99.99% of the time. X3

Right now, I'm just trying to get everything up and running in a way that feels nice. Once I'm done, I usually go back and clean up a little bit. =P At that point, I may enlist your and others' help if it's necessary. For now though, I'd rather keep this thing right where it is.

Edit:
Also, ImaginaryZ's idea of splitting a rendered model into parts which can be animated is a really good one. The pros against the likes of sprite images obviously being that the animations aren't based on fixed image data and so can be customised easily 'on the go' (eg during runtime usage with a 2d rag doll system). Also, because the parts are based on a skeletal structure, the animation data could (and should) be stored separately meaning that other characters could inherit these animations with little need to open up ms paint and pixel-by-pixel alter everything. The cons would be that you actually need to be able to make these sheets in the first place which aren't as simple.

Best of luck

Actually, the sheets should be a lot simpler than the ones that have been posted. Figuring that we have a head, two arms, two legs, and a torso, along with a few different things those can do, we'll probably have a sprite sheet that happens to be about as large as the dino sprite sheet that Imaginary Z posted. Or...well, maybe it'll be a bit smaller. =P The dino one has a larger character, but the sprite sheet is only 513x396, whereas the other is 940x2065. That's about...oh, 8 times as much texture space for a smaller character, both sitting on your computer and loaded into the memory at the same time. Along with that, you have to take into account that the dino sprite sheet uses probably 150% of the space it needs or more, meaning the dino sheet is even smaller than it appears. The animation file won't be large at all, and together it should save quite a bit of space both in memory and file size while at the same time giving us more flexibility in creating and tweaking animations. Oh, and animating isn't quite as tedious or long as spriting, if you ask me, so the over overall work load should be smaller. =3 If we do it right, animations should work for one character or another, meaning we may only have to do one set of animations for lots and lots of different characters, adding a few moves here and there for variety, most likely. Overall, the method Odin Sphere uses just looks better...so long as you use it right. But if you can't use something so simple in the right way, you probably won't be able to do sprites manually either. =P

And when I start talking about something like this, it's hard to stop. o.o *zips lips*

[Superblah]

if you're going to go high end on this thing, then a simple game design doc is mandatory, things like how to approach each animation is very important if your going to use something like 3d scaling and rotation for animation, both the artist and the programmers have to be very involved so you need to have something concrete to refer to that is explicit.

[Elle]

Oh, we're definitely documenting as we go. =P Still, I prefer to talk about things and get them fairly well nailed down ahead of time before jumping in and trying to do it, myself. I find documenting to be good for the general notes that it provides, mainly so you know the direction you're heading and where you've been, but the formal design docs that I've seen and the ones I've had to make... Well, it always seems that I end up deviating in the end. o.o The end product isn't here yet. The program isn't solid, so putting how things work into words already just seems...premature I guess. =P It's like trying to predict whether Schrodinger's cat is dead or alive before you see it. X3 But yeah, we'll definitely be documenting some things and writing up what we're needing to do to give us a roadmap and record. =3

Oh, and I've changed my name. I'll be changing my avatar soon as well. =3

[randomer]

Are you and Kiyoa working with others or between yourselves at the moment?