Jump to content

Common Runtime API


grimfang4

Recommended Posts

I've been considering which features should be implemented in SCMLpp (the C++ API). Let's put our heads together and maybe we can get a good feel for what features any engine API would benefit from.

Here are my ideas. I'll leave out the ones which are in the SCML spec, but not yet implemented in the plugins.

* Bone drawing

* Animation blending

* Runtime bone control

* Runtime inverse kinematics

* Object transform accessor

Bone drawing:

Mostly useful for debugging, but also for effects. For debugging purposes, drawing just a line for bones and a dot for joints works fine. For effects, there could be a way to ask the library for a list of the bone positions so it can use them however it wants.

Animation blending:

This is an important feature. It's not yet supported by Spriter (or SCML). What needs to happen is to identify the same objects between animations. Then one animation can lead into another smoothly. There are control issues that may need to be resolved, since it's common for automatic transitions to look strange (e.g. feet lifting off the ground during the transition).

Runtime bone control:

Simple control of bone parameters. Position, angle, etc. This can probably be integrated into the tweened animation process by creating temporary keyframes.

Runtime inverse kinematics:

Controlling a target instead of the individual bones. There are probably several parameters that might need to be controlled here, like constraints and joint directions. I've never messed with IK before... This could also use the temporary keyframes that the runtime bone control use.

Object transform accessor:

Get the absolute position, angle, etc. of a given object.

Do you have any other ideas or input on these?

Link to comment
Share on other sites

  • 1 month later...

Hi grimfang!

First off, disclaimer--I'm a college student with little game development experience that feels somewhat unqualified to make any suggestions, and some of what I say may be very naive. However I've been getting into 2d game development recently, and I'm really interested in what's been going on here with Spriter.

I took a look at your SMCLpp code and SDL renderer. First I'd just like to say, awesome work and thank you for putting in the time and taking the initiative to do the generic parsing and rendering! It's people like you that make the open source community so enjoyable, so thanks.

First off, I was concerned when I first read the code that the data structure might not be compact enough, but after reading over the spec again, I think I was just confused. Maybe I will try to write some explanation for some newbie developers like me.

In terms of reverse kinematics. All I can think about is Box2d Box2d Box2d..

For such an application, obviously runtime bone control and runtime inverse kinematics are important. The problem though is reverse constraints. How do we handle conflicts between physics and animation bone structure??

I think bone drawing would definitely be helpful. I also really like the idea of access to transform information. If I understand it correctly, this could make rendering in OpenGL more straightforward?? I think a cpp OpenGL-style renderer might be quite popular.

Lastly, I would love to see an open source xml standard for 2d games that connects Spriter animation, box2d objects, and scripting. Do you think this is feasible? I've started to think about how we could connect all these resources, and I thought you would be a good person to consult before I brought the issue to a new topic in the forums.

Thanks!

-brocktane

Link to comment
Share on other sites

Box2D is definitely an exciting direction to go with animation. I think the simplest way to have the physics and animation systems interact is through forces. The programmer would have to specify the max force and limits of each joint and those would be used to let the animations move through the motions as well as they can.

The transform info wouldn't make drawing any easier, since the underlying animation library should take care of that. What it would do is let you know where in the world an object is more for the purpose of in-world interactions. Say you want to spawn particles where the player's torch is held or you want to tell if the hand is near a button on the wall. As for rendering, SCMLpp can use SDL_gpu or SFML to render, which both use OpenGL.

An implementation to join Box2D, Spriter, and more would certainly work, but any work we do at this point is not going to be a popular solution. Whenever you go down that road, you have to make choices which either restrict flexibility (which scripting language do I use?) or increase complexity (any scripting language, but the setup is a pain and the support code is a mess). Box2D also does not support a high-level interface. You need to do a lot of work to write Box2D code that will work easily for multiple types of games. The end result once you bring in graphics, animation, audio, and scripting feels much more like Ogre or some other all-encompassing game engine that forces a structure and libraries that are hard to break out of. This early in the process (Spriter hasn't gotten to 1.0 yet), it is much more useful to write games that will act as concrete examples of how to use all these pieces together. As Spriter gains popularity, I think you'll see existing game engines incorporating it and you'll get all of those features by choosing one.

Link to comment
Share on other sites

My main objective with my Starling implementation of Spriter is to integrate it with a physics engine (most likely Nape, which is faster than Box2d).

The way other game engines accomplish this is having the character body parts be driven by animation data, with the physics bodies following along but not being effected by the physics world. Then, whenever the body needs a ragdoll effect or any other physicsy-interaction, the character skins switch from being driven by the animation data to the physics data. Certain games can even turn physics on just for certain body parts, while others continue to be animated with animation data!

Check out the mobile game Zombie Smash for an example of this.

There's a forum post from the developers about this here:

http://www.cocos2d-iphone.org/forum/topic/18075 (look for the post near the bottom by the user Zombie)

Link to comment
Share on other sites

  • 3 months later...

I too think that Spriter should incorporate Box2D and make use of it in the API, the reason being is... Well kind of selfish but, take this factor into consideration: Every single popular Game Maker type of API / App what have you, makes use of Box2D either the Web Version or the de-facto standard, for examples: GM:Studio uses Box2D, Construct 2 - Box2D Web, App Game Kit or AGK for Short from The Game Creators uses Box2D, Game Salad, and the list goes on and on.. I know that this does not take into account the other engines which don't, but the majority of them do, and the ones that don't, are more difficult by nature anyways, and as such the people who make use of those engines, are already more than familiar with how to program api adaptations themselves, so really there is no reason to take those into account when creating an all around generic API for spriter to interface with the more popular game engines / game creators if you will. But merely take into account that users could inherit from classes and use function overriding to replace functions and classes which make use of Box2D for movement and collision, such as for Revolute Joints & Prismatic Joints w/ Motors & Physics fixtures aka Physics Shapes which contain the objects, which will NOT support Convex shape data at least yet, so were talking Boxes & Circles, and custom shape data made up of multiple points and / or multiple boxes or circles. Basically all we need is a way when creating our animations & characters is a way to specify the physics shape of either the whole character or a box / circle for each underlying part of the character / vehicle / building / whatever, which could be supported by adding a checkbox to the project for either whole object physics shape or body part individual physics shapes, and based on what the user checks or selects during the new project creation process, will then allow them to either go about creating the whole character then define the physics shape by either laying out the physics shape points 1 by 1, in a clockwise order, until they right click and select finish physics shape, or allow them to draw a circle / or box type shape encompassing the entire shape if selected up front during new project create wizard, or if each body part is to contain it's own physics shape also selected at the beginning of the new project creation wizard, in which case you will allow the user to add each part to the project by selecting it from the project sprite folder, and once the body part has been added to the list, and the player adds it visually on the workspace correctly oriented based on joint / bone location, then we will allow them to either draw a custom physics shape around the part by adding custom points -> right clicking to select finish physics shape and / or allow them to draw a box / circle around the body part just added, and finished by right clicking and selecting finish physics shape to let spriter know that they are done defining the physics shape for this part of the project / object / character whatever...

Then when the project is exported to *.png files or whatever, we can also save the *.scml file which merely contains either the object as a whole object with the physics shape encompassing it, which will be specified right at the top of the scml file either object type: whole or object type: seperate in which case the data following this field will either specify the whole objects location data, physics shape data, and movement info such as joint info, motor info for part moving, or revolute joint movement specifying angles, translations and / or forces / impulses and sprite filenames necessary to recreate the object from, and which joints / angles / impulses / forces apply to this sprite portion of the object, now if it is object type: seperate then you will specify each sprite filename, type of joint / motor / speed / angle / impulse / force applied to this sprite / portion of the object also including the physics shape data for this sprite portion of the object, and will continue the format as such till you reach the end of the object definition all parts all physics shape data / joints / bones / impulses / forces / motors / angles and speed of each part, which will allow virtually all the main game creators / engines / tools / api's etc.. to easily load and translate the sprites & *.scml data easily into box2D physics enabled sprite objects..

On the other hand the other engines that don't use box2D should still benefit from having this data, and can most likely load the generic api done in C++ and convert to their physics engine by simply inheriting the classes, function overloading, operator overloading, maybe using templates would be an idea, this way generic drawing / rotation / other forces type member functions of the classes could have their data types specified by the user of the api by importing the template and filling in the different templated types with those from their physics library and or game engine sprite types, make use of their object references for loading, rotation, forces, collision checking, etc..

Templates might be the way to go, or a generic set of base classes from which we can derive our own types and override the base member virtual functions with our own, which the compiler can sort out on it's own as long as we change the parameter type information, or if your feeling extra energetic you could make an all encompassing c++ api, which simply lets the users select their engine by compiler pre-processor directives.. #ifdef AGK etc.. etc..

Sorry for running on so long, but I am just really wanting to get Spriter working for all of my engines, especially App Game Kit since it currently has to level / physics editor that is up to date and no way to create complete objects ouf of individual sprites w/ physics shapes and properties, PEP author is kind of busy with a game he is working on, thus the features are slow coming, and has some errors preventing us from daily use, also it isn't really for creating animated complex physics enabled objects.. Hey there is a thought, he is wanting to get PEP 1.3 added to the main distro of AGK, maybe you could talk to him about adding Spriter object support *.scml loading for each object or just individual objects you load into PEP for placement etc.. in the level.. TGC is already wanting to add Spriter support to the main AGK engine as it is inside the new features questionaire about which features are most important going forward with AGK, so it would only make since for PEP to support Spriter objects / sprites loading and he already has physics properties support added to PEP so it should be fairly possible to get this working, and as he is starting to utilize the *.xml file format, maybe you two could collaborate on a format to make it easy to snap in Spriter object support, and vice versa for adding *.xml support to the *.scml file format..

Anyways just a thought or many that is, sorry for running on, but when I'm programming my mind goes 1000 miles a minute, and I try to help out as much as I can.. I still don't have a subversion client installed so I can't check out the *.cpp sourcecode for the generic C++ API that was created, I'm going to try and set that up today and grab it, so I can see what I can do about at least making it work with AGK Tier 2 C++ support using NDK / Eclipse / Cygwin environment setup for Android Development inside App Game Kit..

Thanks for all your work on this though, I do appreciate it, I just hope we get all this stuff worked out before Spriter comes out of Beta..

Ciao' 4 now,

StOrM3

http://www.mypkegames.com/

Link to comment
Share on other sites

I want just mentoin some things to this topic:

Implementing inverse kinematics with the Box2D (or any other 2D physics engine) is quite a very nice idea.

But a step in this direction would make every plug-in too specific. Think of programers which want to use Spriter but do not need any physics engine (or do not want to use one, because of performance issues).

Or some which want to use a physics engine, but not Box2D.

I think it is good, if the plugin supports runtime bone/object control. If the plugin supports such a feature, it should be very easy to implement inverse kinematics.

I already added those two features in the generic java implementation and it was not that hard (have a look at it ;)).

Moreover I think you would get some performance problems if you connect a physics body to every bone.

You could e.g. just use some sensors (in Box2D) for the feet or hands (one sensor for a foot/hand) and if the inverse kinematics implementation is general enough, everything should work as you wish.

Just my opinion, but connecting Box2D bodies to every bone, just to get inverse kinematics working is a bit too much. Correct me if I am wrong.

- Trixt0r

Link to comment
Share on other sites

Let me point out that the topic here is for an API (interface being the key). Using Box2D is an implementation detail that only potentially applies to some plugins/engines. It's more important to have similar features and similar interface no matter what platform you use to display and manipulate SCML data.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...