New engine.

thingythekid · 03/01/09 17:03

Crystal Space 3D is a free, cross platform, open-source game engine that it might be possible to use. Strong networking capabilities too, I would guess, since it's used in PlaneShift. I think it's also already tied to ODE, a physics engine, but my memory may have failed me. It's also under the LGPL (wiki), so the source for such a project could still be closed, if needs be.

However, none of the above takes away from the fact that there would still be significant requirements in terms of content creation and so on.

Just my two cents.

wmjdgla · 03/16/09 21:03

**Disclaimer: I'm not a pro in the subject, whatever information or facts presented here are gathered from my own research due to interest in the topic. So I may be wrong about some things, and hence would welcome any correction.**

Humm...the prospect of having oni on a new engine is inevitably tempting...I was also like "Holy cow, won't oni look awesome on those engines!" when crysis and ut3 came out. However, while it is possible to build oni using a new engine, it is impractical to do so for the following reasons:

1. Oni uses little or no inverse kinematics(IK) - all combat moves are canned animations. So we have two options: Either replicate all the 2000 animations in the new engine or use the IK capabilities in the new engines, e.g. cryengine or unrealengine3 to create the combat moves. However, both are again, impractical for the following reasons:
If we were to replicate the animations, we would face the following problems: aside from the labor of manually replicating the 2000 animations( most likely using raw eye and hand power, since no software can transpose oni animation to a format recognizable by the new engine ), relations must be established among the animations. e.g. if I press a key, what animation will execute, if I release the key, what animation will follow, if I get whacked from behind/left/right/above while in the middle of another animation, what different animations will follow, etc. So with 2000 animations, we would definitely get more than 2000 relations - all have to be coded. Furthermore, all combat moves are assumed to take place on level ground. So what happens when you are fighting enemies on the stairs or slope? Canned animations are not going to care about the ground on which it takes place. So imagine: ut3 graphics with portions of the character's body embedded in the terrain when they get knocked down, or the feet steping on air with only the toes touching the slope. That would be......ewww......Of course you can create combat animations for specific terrains but not before we settle the original 2000.
So how about IK? With animations computer generated in realtime based on a set of parameter, it would definitely be able to solve the problem of ugly terrain interactions when combat takes place on non-level ground. It would also eliminate the occasional problem of non-contact throws or other moves which can occur in group fights( non-contact meaning the character grabs thin air but the combat sequence is still executed ). With the variety of combat moves and the need for dynamic interactions, especially in group fights, IK seems to be the perfect choice. A game with good IK that comes to mind is Assassin's Creed. Your character is able to grab ledges exactly where they are and when climbing, it really appears that the character is leveraging on the ledge to haul himself up, i.e. no slipsliding between the hand and the ledge, no matter which direction the character moves, and no, the hand doesn't look like it's glued there, but really placed there. But here comes the problem: IK code is embedded in the engine, are propriety, closed source and correct me if I'm wrong - inaccessible to modders. Even if it's accessible to modders, who is going to assign all the control points for the character's body and enter the parameters to reproduce the 2000 animations?

2. Aside from better graphics, another attraction of the new engines are their better physics cores, which could do wonders to improve the realism of h2h melee combat.

Ah...won't it be delicious to have Konoko run punch the annoying striker in the face and see his head jerk in whichever diretion the punch went, at the same time falling in the same direction and with the posture of the falling body affected by the terrain and original stance of the striker?

Mmm...that would be nice...hey, wasn't that supposed to be handled by the IK?

Umm...but the physics engine could also handle it, maybe even handle it better....after all you have to account for the force vectors and collision detection among the body parts and the terrain.

But what's going to control Konoko to do the punching? What if the striker blocks, then what happens?

Well....I guess you would have to use IK to do that....maybe canned animation for some sequences to reduce computational costs....

So you mean we'll use the physics engine, IK and canned animation to do the combat parts?

I guess...

Yahoo! More coding & labor!

To sum it up, Oni's engine is essentially built to handle h2h melee combat with shooting added on top of it, not the other way round. It is also built such that with its primitive technologies, pretty decent looking combat sequences can be generated. unrealengine3, for example is built to handle shooting with functionalities that can be used to create a h2h melee combat. That means we have to learn those functionalities and create the whole h2h melee combat gameplay almost from scratch, since so little of oni's resources are reusable by the new engine. Furthermore, with enhanced graphics, whatever approximation techniques in oni( be it for graphics or combat interactions ) are going to become glaringly obvious and ugly in the new engines should we diretly transpose the content. To eliminate or reduce them would result in more work.

So with these in mind, it would be more practical and economical for the community, who are non-professionals, to tackle things that are easire to handle, like textures, models, environment features that can be handled by the current oni engine. So to whoever out there who desire to have oni on a new engine, bear these in mind and if there are solutions or shortcuts around the obstacles I mentioned above, I believe everyone would be happy to hear them.

Gumby · 03/17/09 00:03

I must say, epic post right there.

Also, we currently can export animations to a format readable by say, XSI. But again, it would not be fun linking everything back together.

Pierre · 03/17/09 03:03

In case you forgot, recreating Oni's combat system (and more) "in a new engine" is exactly what I did in Konoko Payne. It would be technically possible to do the same in your favorite modern engine (Unreal / whatever). It's just a lot of fucking work.

The problem with IK is that it's typically fragile and unreliable for complex things. Just see how they failed *again* in the last Tomb Raider, to have Lara's legs properly interacting with the ground (which is not even a "complex" task). It's full of issues. Now imagine that in the middle of a throw. No, thanks They did it better in Assassin's Creeds but IIRC that animation system alone took a long time and a lot of efforts to develop. I don't see the Oni community replicating this anytime soon...

As far as graphics are concerned, maybe we shouldn't bother with the "Unreal" look that most games go for, those days. I would be happy with an easier Manga look, e.g. like in the last Naruto on Xbox. Would fir better.

wmjdgla · 03/17/09 03:03

Pierre wrote:

In case you forgot, recreating Oni's combat system (and more) "in a new engine" is exactly what I did in Konoko Payne.

Oops, really forgot.....my bad. Should change to "while it is possible to build oni using a new engine, it is impractical to do so, with the exception of particularly hardworking, dedicated and crazy individuals (see Konoko Payne)"

And yeah, the new Tomb Raider character animations are.....eww.....( e.g. with the legs passing through the statues as Lara drags them around ) So much for being next-gen. And they touted it being the first Tomb Raider game to use motion capture; like it helped.

On Assassin's Creed's IK, it's Softimage's HumanIK, propriety nonetheless. From what I've read, realtime interpolation among animation sequences was also used. Imagine the maths involved....

On the other hand, just for interest: Naturalmotion's euphoria engine (http://www.naturalmotion.com/euphoria.htm) looks perfect for melee combat games. Looking forward to games with the engine.

Iritscen · 03/17/09 07:03

I can't add much to the "new engine" discussion except to agree that IK is overrated

Pierre wrote:

As far as graphics are concerned, maybe we shouldn't bother with the "Unreal" look that most games go for, those days. I would be happy with an easier Manga look, e.g. like in the last Naruto on Xbox.

I've always liked Oni's minimalist look. Lots of detail, like cramming busy textures into every corner of an environment, offends my eyes. I still remember how impressed I was with the Oni trailer when I first saw it. What was most impressive? Not the combat, or the characters, or the music, or the (hints of a) story; it was the environments. I was fascinated by the clean and simple architecture. (The second most impressive thing was Konoko's walk at the end; I'm an incurable aesthete, sad to say.) So I totally agree with Pierre. I think that the super-slick graphics of today would actually be out of place in Oni -- contrary to the spirit of the game.

The Naruto games that I've seen have some impressive cel shading; at some point perhaps we will get back to that whole idea that geyser started us on, seeing as we've been able to simulate cel shading in the Oni engine.

Jazz Ad · 03/17/09 16:03

My feelings exactly.
Oni works well in minimalistic environments.
Actually now that I think of it, Konoko would be perfect in Portal.

Gumby · 03/17/09 22:03

Jazz Ad wrote:

My feelings exactly.
Oni works well in minimalistic environments.
Actually now that I think of it, Konoko would be perfect in Portal.

GlaDoS wouldn't stand a chance.

TomeOne · 03/18/09 09:03

I'm glad this thread didn't turn into the equivalent of "I can has engine?"

onimotoko · 03/28/09 02:03

well aware of the work involved in this, but I don't wanna skimp out just cause of that.
If I had all the people I needed, (animators, modeler, etc.) the work would be reduced significantly.

onimotoko · 03/28/09 02:03

wmjdgla wrote:

**Disclaimer: I'm not a pro in the subject, whatever information or facts presented here are gathered from my own research due to interest in the topic. So I may be wrong about some things, and hence would welcome any correction.**
Humm...the prospect of having oni on a new engine is inevitably tempting...I was also like "Holy cow, won't oni look awesome on those engines!" when crysis and ut3 came out. However, while it is possible to build oni using a new engine, it is impractical to do so for the following reasons:
1. Oni uses little or no inverse kinematics(IK) - all combat moves are canned animations. So we have two options: Either replicate all the 2000 animations in the new engine or use the IK capabilities in the new engines, e.g. cryengine or unrealengine3 to create the combat moves. However, both are again, impractical for the following reasons:
If we were to replicate the animations, we would face the following problems: aside from the labor of manually replicating the 2000 animations( most likely using raw eye and hand power, since no software can transpose oni animation to a format recognizable by the new engine ), relations must be established among the animations. e.g. if I press a key, what animation will execute, if I release the key, what animation will follow, if I get whacked from behind/left/right/above while in the middle of another animation, what different animations will follow, etc. So with 2000 animations, we would definitely get more than 2000 relations - all have to be coded. Furthermore, all combat moves are assumed to take place on level ground. So what happens when you are fighting enemies on the stairs or slope? Canned animations are not going to care about the ground on which it takes place. So imagine: ut3 graphics with portions of the character's body embedded in the terrain when they get knocked down, or the feet steping on air with only the toes touching the slope. That would be......ewww......Of course you can create combat animations for specific terrains but not before we settle the original 2000.
So how about IK? With animations computer generated in realtime based on a set of parameter, it would definitely be able to solve the problem of ugly terrain interactions when combat takes place on non-level ground. It would also eliminate the occasional problem of non-contact throws or other moves which can occur in group fights( non-contact meaning the character grabs thin air but the combat sequence is still executed ). With the variety of combat moves and the need for dynamic interactions, especially in group fights, IK seems to be the perfect choice. A game with good IK that comes to mind is Assassin's Creed. Your character is able to grab ledges exactly where they are and when climbing, it really appears that the character is leveraging on the ledge to haul himself up, i.e. no slipsliding between the hand and the ledge, no matter which direction the character moves, and no, the hand doesn't look like it's glued there, but really placed there. But here comes the problem: IK code is embedded in the engine, are propriety, closed source and correct me if I'm wrong - inaccessible to modders. Even if it's accessible to modders, who is going to assign all the control points for the character's body and enter the parameters to reproduce the 2000 animations?
2. Aside from better graphics, another attraction of the new engines are their better physics cores, which could do wonders to improve the realism of h2h melee combat.
Ah...won't it be delicious to have Konoko run punch the annoying striker in the face and see his head jerk in whichever diretion the punch went, at the same time falling in the same direction and with the posture of the falling body affected by the terrain and original stance of the striker?
Mmm...that would be nice...hey, wasn't that supposed to be handled by the IK?
Umm...but the physics engine could also handle it, maybe even handle it better....after all you have to account for the force vectors and collision detection among the body parts and the terrain.
But what's going to control Konoko to do the punching? What if the striker blocks, then what happens?
Well....I guess you would have to use IK to do that....maybe canned animation for some sequences to reduce computational costs....
So you mean we'll use the physics engine, IK and canned animation to do the combat parts?
I guess...
Yahoo! More coding & labor!

To sum it up, Oni's engine is essentially built to handle h2h melee combat with shooting added on top of it, not the other way round. It is also built such that with its primitive technologies, pretty decent looking combat sequences can be generated. unrealengine3, for example is built to handle shooting with functionalities that can be used to create a h2h melee combat. That means we have to learn those functionalities and create the whole h2h melee combat gameplay almost from scratch, since so little of oni's resources are reusable by the new engine. Furthermore, with enhanced graphics, whatever approximation techniques in oni( be it for graphics or combat interactions ) are going to become glaringly obvious and ugly in the new engines should we diretly transpose the content. To eliminate or reduce them would result in more work.
So with these in mind, it would be more practical and economical for the community, who are non-professionals, to tackle things that are easire to handle, like textures, models, environment features that can be handled by the current oni engine. So to whoever out there who desire to have oni on a new engine, bear these in mind and if there are solutions or shortcuts around the obstacles I mentioned above, I believe everyone would be happy to hear them.

I realize that UE3 was not truly designed to handle those complex anim's, but as U stated, the possibility is there for anyone to take advantage of if they are willing to put a significant amount of time into such an endevour.
And thank U soooo much for an intelligent reply, your insight is most appreciated.

onimotoko · 03/28/09 02:03

Pierre wrote:

In case you forgot, recreating Oni's combat system (and more) "in a new engine" is exactly what I did in Konoko Payne. It would be technically possible to do the same in your favorite modern engine (Unreal / whatever). It's just a lot of fucking work.
The problem with IK is that it's typically fragile and unreliable for complex things. Just see how they failed *again* in the last Tomb Raider, to have Lara's legs properly interacting with the ground (which is not even a "complex" task). It's full of issues. Now imagine that in the middle of a throw. No, thanks They did it better in Assassin's Creeds but IIRC that animation system alone took a long time and a lot of efforts to develop. I don't see the Oni community replicating this anytime soon...
As far as graphics are concerned, maybe we shouldn't bother with the "Unreal" look that most games go for, those days. I would be happy with an easier Manga look, e.g. like in the last Naruto on Xbox. Would fir better.

Perhaps you know of an open source engine that includes an editor that can do that? If so, let me know.

onimotoko · 03/28/09 03:03

Iritscen wrote:

I can't add much to the "new engine" discussion except to agree that IK is overrated
Pierre wrote:
As far as graphics are concerned, maybe we shouldn't bother with the "Unreal" look that most games go for, those days. I would be happy with an easier Manga look, e.g. like in the last Naruto on Xbox.
I've always liked Oni's minimalist look. Lots of detail, like cramming busy textures into every corner of an environment, offends my eyes. I still remember how impressed I was with the Oni trailer when I first saw it. What was most impressive? Not the combat, or the characters, or the music, or the (hints of a) story; it was the environments. I was fascinated by the clean and simple architecture. (The second most impressive thing was Konoko's walk at the end; I'm an incurable aesthete, sad to say.) So I totally agree with Pierre. I think that the super-slick graphics of today would actually be out of place in Oni -- contrary to the spirit of the game.
The Naruto games that I've seen have some impressive cel shading; at some point perhaps we will get back to that whole idea that geyser started us on, seeing as we've been able to simulate cel shading in the Oni engine.

A new engine doesn't have to mean that the environments have to be crowded full of crap. Look at portal, that's what I want as far as graphics are concerned.

wmjdgla · 03/29/09 20:03

Humm....if I were to start a recruitment drive to create/clone a game using a new engine, I would first start out visualizing what the end product should look like and subsequently list all the required technical features necessary to make my vision come true. E.g. I want Konoko to be able to do parkour, to counter enemy attacks, to be able to use melee weapons, etc. So the required features would probably be accurate bodypart-specific collisions, physics based interactions, IK, canned animations, etc, regardless of the degree of complexity or technicality required. If I'm unsure of what technical features are required, I would go to www.gamedev.net to do some research.

Once the list is done, I'll take a good look at all the engines out there and see which ones possess the most number of features that I want. A few free and/or open source engines are:

game engine:
www.delta3d.org
www.crystalspace3d.org
www.openscenegraph.org
www.visualizationlibrary.com
www.gameblender.org
irrlicht.sourceforge.net/
www.ogre3d.org/
physics engine:
www.bulletphysics.com
www.ode.org
developer.nvidia.com/object/physx.html
www.tokamakphysics.com/
www.physicseditor.com/
www.adrianboeing.com/pal/index.html
software.intel.com/sites/havok/
www.newtondynamics.com/
www.deltaknowledge.com/chronoengine/
www.trueaxis.com/
spehome.com/
www.rowlhouse.co.uk/jiglib/
www.sofa-framework.org/

Some game engines takes care of both graphics and physics. Others don't, but allows 3rd party physics engines to be added on. Depending on what's on my list of technical features, I'll have to do some research on all of them and find the optimal combination of game/graphics/physics engine. Or, I can just stick to ones commercially available, like unreal engine.

Having picked my choice of engine, I'll now have to make changes to my vision, since not all of the technical features required are inside the engine I chose and even if they are inside, they may not be accessible for modification (especially commercially available ones). Then, I'll take a good look at the remaining number of technical features left and ask myself: which ones can be realistically handled by me and the community and which ones cannot, i.e. given the skills and resources available, which features can be realistically tackled? So I may have to start to throw out features like IK (if the engine I chose supported it) and place less emphasis on features like physics based interactions (since it can become too technical) and instead focus more on canned animations. That means further changes to my vision. At the end of the day, I would look at the modified vision and ask myself: Now, with this so different from what I started out in mind, do I want to continue? Is this going to be worth the future effort I'm going to put in? Are there alternatives out there that offers comparable results with less work (e.g. Oni: AE)?

So depending on my choice, I would go down different paths. But now suppose I chose the most difficult one - to continue with the new engine. I would now have to do research to find whether if relevant, similar works have already been done. E.g. if I chose unreal engine, I will start finding if there are already mods to character animations, character-to-character interactions, character-to-environment interactions, melee weapon mods, etc. If those mods exist, I'll use them as a sales pitch - to recruit modders out there. Only then would I would say: Hey, look here, this is my vision, these are the required technical features, these are the required skills and that the goals of this endeavor are realistic as so and so similar works have already been done in this and that area (substantiated with videos, project sites and technical information gathered through my research). So, who's on?

Now, that would be a convincing sales pitch and if it's good enough, it can even be inspiring. But if little or no relevant works are done, then I will have to begin the long and arduous path of creating them myself. Or, I would say: Hey, look here, this is my vision, these are the required technical features, these are the required skills and I honestly believe that this is possible. So, who's on? Less convincing definitely, but probably could still gather a few people to help me make the long and arduous path less painful. Only when I/we have laid a firm groundwork demonstrating that it is indeed feasible would the recruitment momentum gather.

Ah...a long and tedious process. But hey, no pain, no gain.

**Well, the above is what I would probably do given my limited knowledge and experience. Would welcome any comments and suggestions on improvements **

Loser · 03/30/09 14:03

Finally I can log in (thanks Iritscen):

my opinion on this thread: STOP THIS MADNESS, please.

I kindly ask you all to stop trying to search for new and new engines which "could" emulate ONI's combat system. Instead, I ask you: Can you create your own?

Can you create your own engine and make all these amazing ideas reality? If yes, DO IT, we will help you as much as time will allow us. And if no, then...keep dreaming. Forever.

I see you think about improving visuals of combat. Why IK engine? While it is good, do you really think such a high caliber is needed for a game like Oni (not taking into an account possibility of obtaining it)? I have thought about it endless times and still I keep thinking out how to stich it together to look good but not be over our heads.

While I am still too weak and unable to code it and make it reality, I think I know the solution:

Attacks are pre-canned animations.
Why bother more with it? We don't need euphoria-like simulation. Make character execute animation. If animation hits another character, evaluate which (pre-canned as well) respond animation to use, depending on which part of body was hit and from which angle according to victim character's facing. Knockdowns are exception, will talk about them later.

Blocks are depending on where attack hit, from which direction and which block response is called from blocked attack. So they are treated the same as hit responses from code point of view, only with altered mechanics ( it is block, not hit response ). Again, these block animations are pre-canned. Why bother to make it more difficult when this works very well? Just polish it.

Grabs
should be trated more precisely than in ONI. First of all, check if height difference is not higher than some specified value. Can be read as a value from grab animation file. Thanks to that, aerial grabs and ground grabs can be quite easily implemented next to standard ones.

If this condition is met, check whether there is enough space to execute the animation. Then decide (according to result of environment check) to
1) enough space -> execute standard version of selected grab
2) wall/obstacle in a way within some interval -> execute nearwall version of selected grab
3) not enough space + other special conditions -> execute close version of selected grab

Here more delicated stuffs comes into account. When grab is executed, connect participants of the grab via function. In grab source animation file, tell engine which bodyparts of grabber's body are connected to which bodyparts of grabbed's body. Remember, we have 19 bodyparts.
Next, when bodyparts connections are specified, do more delicate placing of grabber's selected bodyparts via x/y/z positioning, where origin of those x/y/z (place where it is 0,0,0) is origin of grabbed guy's bodypart which was specified to have connection to some grabber's bone, as was specified. Thanks to this grabber will always grab grabbed guy as he is supposed to (collar, wrist, waist).

In order to make previous paragraph a reality, we need some skeleton model with specified joints, which is already present in ONI as far as I know. Oni uses it as a blueprint for building characters (joining specified 3D models of bodyparts). Such a structure can be modified to serve for another purpose - to tell where are connections between bodyparts. Also, limit angles between bodyparts in selected joint could be set.

With such a creation, we have grabs which are adjusted to look as they should even if there is uneven ground between grabber and grabbed guy.

knockdowns are treated as simple ragdoll mechanics. Just give info where on the character impact occured + strength of impact and rest is handled by ragdoll system. Depending on health of knockdowned character, it either interpolates into fallen animation (char is still alive) or it is left as it is (char is dead).

Loser

Last edited by Loser (03/30/09 15:03)

Gumby · 03/30/09 16:03

While IK might not be neccessary, it looks very nice for hit animations. No more worrying about how to decide which canned animation to use, and we can have multiple hits, etc.

onimotoko · 04/03/09 13:04

My original intention was to create a battle system that was so deep that it made soul caliber look like crap.
This would involve THOUSANDS of animations, much more than the original oni game.

I know that it's not realistic. Even if I had a huge studio with a thousand animators working day and night, it would still take a long time.

MY biggest problem is that I am a perfectionist. I like all the ridiculus details, and wild camera angles. But I'm looking at this from the perspective of an artist, not the poor bastards that would have to create my ultimate animation system.

I can definitely agree that IK is NOT the way to go. But surely there must be another way? For example, Assassin's Creed did have a very complex animation system, but there where still collision problems,( body parts showing through clothing, people going into walls, getting stuck on terrain, etc).

SO, I now ask, what can WE make that will actually work? Is making a new engine even a feasible idea?

I personally don't know enough computer theory or mathematics to generate a rendering environment of any kind.
Do any of you? Didn't think so.

Gumby · 04/03/09 16:04

There are two members of the community who can (and have) done such a thing.

Pierre, who made http://wiki.oni2.net/Konoko_Payne

and

Neo (maker of Onisplit) who made some sort of rendering engine for Oni data. Can't recall the name of it.

Pierre · 04/14/09 05:04

I didn't do "Serious Konoko", I did "Konoko Payne" Speaking of which there has been a lot of progress since the last release, I must find the time to do another one...

But it's still nowhere near a complete game. It just takes too long when you're alone.

Gumby · 04/14/09 09:04

Yarg! My bad. What have you added in?

Pierre · 04/15/09 02:04

I don't have time to go through the log and extract the real new features, but you know what, just for fun, I'll copy-paste it right here. This is the exact changelog between last release and whatever I have now, uncensored, unedited, in all its "frenglish" glory. Now you can see why it takes forever: the log is huge but still, if you would be playing the current version you wouldn't really notice big differences compared to the previous one. Only more polished, bugs fixed, etc. I guess the biggest addition was something called "Puppet Master", in reference to Ghost in the Shell (both the anime and the PS2 game): you can now take control of any NPC in the game (under some circumstances). I also started a "real" level in MAX, better looking than the "prototype" level I was using so far. There's actually a lot of MAX stuff that is not included in that list below.

If anything, it might give you a good idea of the amount of work needed to make "a small game". Doesn't matter what engine you use.

Oh, and the TODO list looks exactly the same, but it's a 200K text file with pretty much one thing to do per line. I'm not kidding. Welcome to my world

- decals on/off
- foot hit when shot in the foot
- when going to camera mode and picking something, shouldn't destroy our selection in mesh mode
- SetHit/GetHit => does it have to be virtual?
- Bug with mesh selection:
    - camera mode, move a bit
    - press F3 while moving => selection window starts from top-left corner => many objects selected suddenly
- walking sound = f(surface)
- run diagonal, jump, press SHIFT => orientation foireuse
=> et aussi attaques en crouch
- tweak angle weapon par rapport à l'horizontal quand on shoote => ArmPitchOffset increased to 0.3
- doors don't all open in same dir
- event_wall when touching other character => bof
=> in particular after a daodan dash when the NPC collides with the player!
- "head 2 wall" from Loser! ==> test in Striker_SpecialMoves.txt
- Make sure striker's charge can't be rotated
- weird bug (?) when jumping on an NPC. Because of the new CCT???
    - looks like a BUG in sweep capsule capsule for character interactions
    - behaviour not the same with USE_ICE_CCT
    - also check PERSISTENT_SWEEP_TEST
    - disable recovery offsets in InteractionCharacterCharacter to debug this
    * also make players fixed, they seem to be moved away for some reason
    ===> it's the capsule/capsule culling in IceSweepTest.cpp!
- CCT: reduce the CCT volumes in crouch mode
- Rotation stuff:
    - Pause, rotate camera N tours, unpause, see the player rotate like crazy => miss a "reset" when paused
- Diagonal issues:
    - can't jump while running back diagonal => seems to be a DirectInput issue, see IceInputSystem.cpp
    => and indeed, if we use "L" instead of "Space" to jump, it works! ....
    => no DI, no Win32 ==> LL Keyboard issue!!! => unfixable
- demo-mode: sound volume dépend de la position du player?
- Redo Thug starting from ComGuy. No taunt. No throws.
- Add Test level: door
- decals on dynamic objects: can't we just do an extra SetWorldMatrix() before rendering ?
- dos debug console
- make console work on platforms
- fix shadows on platforms
- platform sound
- CRASH in GenericCache when it returns null. Same as VDG bug???? => probably not
- "vdg bug": seems to crash in void KW_VanDeGraaff::Render(Renderer* renderer), then calling IceCore. Maybe allocation?
- Portal problem: consider a big room with 400 objects. THEY ARE ALL IN THE SAME REGION. So, if we reach this region, the objects
will all get culled one by one against the current planes. Count 1000 cycles for one test. That's 400.000 cycles directly. Oops.
We need a way to put some hierarchical culling inside the portal system. Since the culling planes planes are constant for each
traversed region, it should be quite easy: just use an AABB tree in each region. That being said the usual issues with dynamic
objects apply.
- add small glow when taking an hypo
- glow 0.04 0 0.08 => NICE
- fade out glow color
- Portals: instead of output prunables, just have a callback and let user decide what to do ? => that's how it works now!
- Portals:
    - portal object interface: ("Portable"! :))
        - get world aabb
        - output prunables
- portals & shadowcaster
- ICE: optimize ram in portal classes (like Region and its containers)
- CRASH: feb 23 2008: after disarming the fury and started shooting with the VDG while she's still falling ==> probably "VDG bug"
- CHECK CCT OPTIM TO FETCH PORTAL/SURFACE SOUND => seems to work. New console command to enable.
- CRASH when killing Barabas with VDG, seems to be in VDG hit cb. Not in debug.
- VDG doesn't hurt Barabas?? Lifebar doesn't decrease
- strange bug once with lifebar suddenly going to infinity or something
- get back correct modulo3 macros, use in quat<>mat conversions
- automatically leave inventory when enabling shield / invis?
- DemoMode: better level? ====> helipad
- DemoMode: infinite ground instead of room ==> or just a better looking room
- "demo mode pas compatible avec invisible" <= not sure what this means now
- collision check when crouching up doesn't work anymore! => only on helicopter, probably because it's "dynamic"
- GameStats: add throws
- SlowmoOnKnockout: add throws
- SOUND: Fury => 1.14 times faster ======> done except for death sounds, and I changed the -pitch-, not the speed
- killed when restored on lower ground (as if we were falling)
- platform sound when restoring them?
- display game stats at end of level
- demo mode music
- ca.ReadByte()!=0 ===> ReadBool()
- LEAK: cutscenes from consoles, not deleted
- disable tab while in cutscene
- the iron demon cutscene is not replayed after a restore
- stop timer during cutscenes ==> at least for shield & invisible
- AI: if moving suspicious & touch us, should react
    ==> doesn't work well, probably because:
    a) the attack transitions may not exist in "walk" mode (use a modifier???)
    b) or they exist but not all attacks are available when sneaking => use just vanilla punches
    c) when the player bumps into an idle guy, the idle guy may not have the right collision flags
        In any case, they should attack in 4 directions and also react to sounds maybe
- "burnes" ++
- glow on invisible looks very cool
- glowmanager serialization
- Strikers now do weird things when we approach them from the back (because of suspicious/invisible changes?)
- missing sounds for thug's special moves
- reactivate hit foot, as loser did (striker's foot ouch)
- stop sounds when hit:
  - play some voices with the same channel (special attacks, taunts, hits & deaths sounds...)
  - store channel inside character (or in a manager but later)
  if ( stored_channel != INVALID_ID and IsPlaying(stored_channel))
    StopChannel(stored_channel);
  stored_channel = play new sound ()
- stop rise of fury sound when hit!
- GetGroupInfo() => has a N^2 part :(
- patrolling test
- new level info managers
- check fire stops interruptible sounds
- expose ambient occlusion params, add light multiplier
- make a test sniper scene
- VOID helper don't relocate junk objects??
- si sentinel touches en jump, pas d'effet
- SENTINEL don't hit if we have a gun in idle protecting us ==> should be fixed now
- Names à la Jet Set Willy for each "room"
- add fade on region names
- pain sound for hit jewels
- The laserwall sweep-test problem:
    - it must stop the player with low framerates
    - it must not stop it if he has a shield
    - it let the player pass when the wall is "open" by crates

We could try to put custom aabbs (like CCTs) beyond the laser segments but it's true that the sliding might
just break everything

easier to just do that as a second pass and kill the player if any impact is found?

For each laser segment
   compute intersection between swept segment (motion from player) and laser segment "vertical" plane
   if the player crosses the plane, register a kill
=> only if no shield, it's ok to tunnel if the shield is there!

the particles against the shield could be seen as a dynamic point light with variable range (range = f(number of particles))

========================================================

    - bug when we dash back through laserwall
    - passe au travers avec slow framerate!
    ----------
    - swept lines for laser CD => add tris to CCT => hmmm but then the body parts will never touch the laser
    ----------

    Character through laser wall:
    - detecting tunneling is not enough
    - we need to add a vertical segment inside the CCT, and sweep it against the individual laser segments (in a collide-and-stop fashion). Then the CCT would be blocked inside the laser wall and the normal code would then finish the job. We need to disable CD between the usual volume and the laser-wall... ie if we add laser segments as geoms in the CCT, the box will get blocked against them immediately, as against a wall. But the character wouldn't die since the lasers may not touch body parts anyway.

    So it's ugly but it looks like this:

    if swept volume intersects laser wall
        do CCT move including extra segment & laser geom
    else
        do normal CCT move

    ...talk about a generic character controller...

    Anyway the central segment might be reused to compute the portal ID.

    The segment query can be done in a completely separate pass using only the laser geoms! So it's actually just a bunch of sweep-tests without all the CCT logic. It overrides the CCT result if something is found. However it must be performed between the original position and the new position returned by the CCT, to avoid wrong results. Hmm, can still be wrong when the character has been sliding a lot against the wall in a single move. So this second pass must be performed for each CCT iteration.

    - another idea: just add laser geoms offset from the actual laser wall. Offset depends on what side of the wall we are..
    => does that work when we cross with a shield ???

========================================================
- BUG: laserwall: probably multiple hits
- LASER: burnt sound when hit
- Laser: the front/back test is wrong, we should use the LASER's plane and the CHARACTER's witness point!
- BUG: laserwall: front/back attack for laserwall not perfect
- laser: can pass through when front/back status not correct
- put laser in region, don't test if not same region as character
- difference between mSavedSkeleton.mPos and mPreviousPos? => none
- BUG: laserwall: no blending when knockeddown ?
- save/restore saved skeleton
- don't recompute TBV for each laser! ======> put this in interaction map?
- reset position to laser wall when tunneling is detected
- serialize skeleton data
- serialization of patrolling state doesn't work => not all the time. Seems it works from suspicious state, but if the guy is in
player aware mode it doesn't properly restore the patrolling state! => maybe because the resetai stuff doesn't work
- revoir tous les KP_RenderText() => use align flags
- IK: problems even with arms only, when doing kick/punch moves while holding a riffle
- microthreads manager + deletion + serialization
=> "resurrect" doesn't "work" because the AI is fallen, and hence immediately switched to player aware loop
- patrolling test: the guy sees us immediately because he's spawn too high
- patrolling test: when he starts firing after the delay, his arm suddenly moves up towards the player (when standing on the small wall)
- sniper: in depot, he should stop firing when path is blocked
- check why IK is not enabled when we start the sniper test
- big pb with sniper in depot, sometimes stuck when visibility has been lost & reacquired
=> collides with "rambarde" in front of sniper. Seems we use a bad source point! => fixed
- there's a "mega hit" sound when character is touched by a laser while already fallen ??
=> also when a huge firerate sniper hits us twice in sniper test
- no sound anymore when player is hit by a gun? no sound for gun impact?
- no sound for turret/sentinel hits
- weapons don't cast shadows
- gun shadow: clean/refactor code, test all shadow types
- shadowmap: recenter rendered objects to use resolution better
- invisible: make weapon invisible too
- if restored from invisible to normal, invisible sound doesn't disappear
- flybys: use a back plane instead of an afro?
- flyby
- better "volume lines"
- add correct per-weapon flyby sounds ===> there are none! Just 3 different ones for the MB
- sound volume screwed up for gun impact in sniper test
- the sniper isn't restored with a weapon!
- check visibility status of weapon after a load/save while invisible
- write a piece of code to detect missing transitions to hits ==> "MissingTrans" in console
- enable throws from taunts
- sort transitions to find them quicker "by ID" <=== impossible, they're already sorted by priority
- save/restore crash: probably just because it's not done at the right time
    => but doesn't happen in Debug so there's also a compiler thing somewhere
    Disappears if we skip this: void UpdateWeapons(const TimeInfo& time)
    ==>    KW->Update(time);
    ==> void KW_MercuryBow::Update(const TimeInfo& time)
    ==> seems to work with rewritten code. Maybe because "StabbedFace" doesn't initialize its members?? Still looks VERY WEIRD.
    I don't know why the FindBulletHit() returns null the first frame
    => explains the "compiler thing" though. StabbedFace should just initialize its member.
- SOUND: add a big big "land" sound when falling and dying
- save/restore shield/invis while blinking doesn't work - actually blinking doesn't even start the second time
- stick all characters to ground before starting
- build times, special exe for that
- trilinear filtering in options
- container with stack alloc
- KonokoGlow.Cpp
- optimize glow (val2=0, etc)
- put region in wall lamp depot, change level name
- glow culling: Portal culling glow meshes:
    - put glow meshes in portal system
    - mark them inside the portal system
    - when rendering, parse the list from the portal system itself, where both the timestamps and the glow bit are then available
    => NEW_GLOW_PIPELINE
    => works except for door locks?!
- FX: combine glow & invisible ==> hmmm, doesn't do what I wanted ==> but still combined now while invisible
- portal: on peut utiliser le résultat du CCT pour trouver la région courante!
- running lariat from back side? => no
- different footstep sounds on different materials => "done" now
- "void" pos in the middle of the helico ==> use void helper
- SOUND: make sure loop sounds are not played twice when called twice without a stop call. Cf gInvis
- shield only protecting from guns & ringwave
- Shield issues:
    * BUG: can't hit enemies anymore with a shield!
    * sphere gets rendered
    * sound issue when disabled on laserwall
    * billboard stays & can go through laserwall at end of shieldtime
    * sound issues with multiple shields ==> shield sound only for player    
    * fix serialization
- blood puddle when falling from high ground
* camera manipulator should work with grid
* use object ptrs as GUIDs in load/save => we kinf of do that already
* OVERPOWER: activate ovp only when starting from full glow
* OVERPOWER: can't access console anymore
* OVERPOWER: lock target remains active when touched by sentinel while overpowered
- stick to ground avec un flag per anim? => useless now
- check portal update is correct for character in empty room
- check why UpdateSentinels is so slow => ViewIsBlocked()
- check initial memory assert... new... because of IK? => can't repro
- detail texture matrix in material
- "preserve shadow vertices" option in vertex lighter
- envmaps chient ==> y'a pas de normales dans le VB!
- redo cutscenes in consoles
- debug mess with TextParser::Parse (USE_STACK_ALLOC) and SUPPORT_BASIC_CONTROLLERS and the weird sound bug!
- better sound for opening door vent
- check we can still fire at barrier. raycast camera != raycast weapon <= indeed, can't fire at them anymore
  We need 3 different things:
    Weapon ray => DisableRaycast
    Camera ray => DisableCameraRaycast
    CCT    => SetNonCollidable
- add a special group for detail meshes (skid marks, etc) => no collisions, no raycasts
=> include posters, postits, orange border in corridors
- Optimize surface sound selection
- transition to "falling state":
    * falling knockdown not working... ? => only when jumping forward! ???
    * falling anim => konokojump_flail
    * only register flag when motion goes DOWN
    * issue with circular scripts:
        * we want to be able to switch to "falling" from any state
        * we want to enable all hits?
    * falling anim for NPCs
- also, konoko's blue bboxes aren't visible when "free pruner" is selected? Isn't everything moved tho the octree anyway?
==> maybe not for objects spawned from the console
- sometimes it looks like the mb goes through far away npcs => definitely ==> only for "free" objects?
Because of max dist?? Very weird, even with a much bigger max dist it still fails. The weird thing is that
the reticules are not rendered all the way (but that's normal => MAX_NB_RETICLES), and especially that the NPC can shoot us anyway, which
suggests the raycast actually works. Maybe it's just impossible to really hit the npc from far away without target lock
Distance is ok, the hit happens around 2000, and the back mountain (iceland) is 10000
Looks like there's really an accuracy issue. Maybe simply this when max_dist is big:
        Segment Seg(ray.mOrig, ray.mOrig+ray.mDir*max_dist);
=======> fixed with "iterative raycast"....... hmmmmm...... definitely accuracy stuff :(
=======> but now we can't shoot anymore when NbIter is 0. WTF. => fixed
==============> SegmentSphere looks guilty
- SegmentSphereOverlap still screwed up
- "unlock camera" completely, ie also when pressing ctrl
- check #cells in octree................
- crash when kicking with no sound
- memory leak!!! => looks like it's in the FindReceivers() function??
- remove allocs in StabbedFaces
- INSANE sniper bug. Some raycasts just don't work anymore. FindImpactPoint must be broken.........
- remove allocs in 
bool RMScene::FindStabbedObjects(ControlModeID pool, const STABCREATE& stab_info, StabbedFaces& stabbed_faces, udword group_flags)
- re-enable local containers => and do missing ones
- Ray-sphere: "Robust" version still weird sometimes in the ventilation duct.
- backspace => gives all weapons

This one is useless:
    ParameterBlock(const String& str);

This one creates a temporary string:

OUCH: char* to String to char*

ParameterBlock::ParameterBlock(const char* str)
{
    Create(String(str));
}

inline_    udword                Create(const String& str)        { return Create(str.Get());    }

udword ParameterBlock::Create(const char* str)

- done twice?
    // Remove TABs if needed
    if(IsSet(BFC_REMOVE_TABS))        CurrentLine.Replace(ASCII_TAB, ASCII_SPACE);

    // Remove TABs if needed
    if(IsSet(BFC_REMOVE_TABS))        CurrentLine.Replace(ASCII_TAB, ASCII_SPACE);
- Optimize:     Container Projectors;
- Optimize:    mRenderer->GetViewports() <= in scene loop
- Sniper shouldn't be "surprised", really
- sniper nevers tries to pick up his weapon again, in sniper test => maybe just missing ground_mesh!
- Striker: transition too fast when evading backward and continuing moving back
- foot-hit-ouch: vertical offsets not correct for NPCs: comguy, tanker, Ninja, Thug
- BUG: no reaction when npc shot in the foot from backwards (!)
- GAMEPLAY: E key to drop weapon
- key to drop weapon => C? X?
- Function for this:
mPrevBodyYawTarget = mBodyYawMemory = mBrain.mAIAngleToTarget;
- use sweep test for camera!!!
- CAMERA:  use a swept capsule instead of raycast, ie never let the camera go too close to player?
- cam's ray should be shot from a fixed point (not dependent on anim), else possibility of jitter => or use a swept sphere
=> or use multiple rays
- revoir serialization crates (new glow variables)
- crates à durée de vie limitée sous les lasers? ====> maybe with an increasing glow
=> tweak max time + glow color, then test in game
- remove glass objects from picture analysis
- ban going to console when intercom is pending
- fix mess with intercom starting while console text is displayed
- GAMEPLAY: code needed to unlock door, written on a postit
- pic analysis: remove black bands!
- weird camera hiccup when fallen hit, with sweep test on. Maybe the starting sphere intersects the floor
- USE_SENTINEL_LOS_CACHE
    => some sentinels fire because there are holes in the walls, and the ceiling is not double sided so the player is actually exposed
    => disable backface culling?
- shadows not rendered while intercom is on?
- Dialogs as in Xenosaga 3
- disable raycast/cd on shadow quads
- fix initial mess with new intercom in proto
- fix intercom bug when digicam is on => would get fixed naturally without pause
- selection widget à la max
- *use* selection dialog
- no need to update shadow maps each frame?
- err.... blurred shadows.... just render at 32*32 and display larger???? ====> doesn't work at all :)
- "void objects" are put in static pruners, bad
- shadow is rendered on invisible void objects!!!!!! Insane bug
- Importing Consoles.zb2 may not be useful anymore
- huge performance hit with portals on platform => probably because of shadows!
- check speed of this stuff:     rnd->LightOff();  =======> or just remove all lights when game starts
- can't shoot on all muro monitors
- select mesh(es)
- task manager: frame memory leak AGAIN. FindReceivers again? => apparently not
=> disappears if we remove the portal callback:
#ifdef DEBUG_LEAK
//    scene->Enable(SRF_VFC);
//    return true;
#endif
- make a "texture blurrer" class directly in DX9 layer, exposed as tool

//Blur Weights
static const float BlurWeights[cKernelSize] = 
{
    1.0f / 4096.0f,
    12.0f / 4096.0f,
    66.0f / 4096.0f,
    220.0f / 4096.0f,
    495.0f / 4096.0f,
    792.0f / 4096.0f,
    924.0f / 4096.0f,
    792.0f / 4096.0f,
    495.0f / 4096.0f,
    220.0f / 4096.0f,
    66.0f / 4096.0f,
    12.0f / 4096.0f,
    1.0f / 4096.0f,
}; 

//Horizontal Blur
float4 HorizontalBlurPS(float2 uv : TEXCOORD1 ) : COLOR0
{
    float4 Color = 0;
    
    for (int i = 0; i < cKernelSize; i++)
    {    
        Color += tex2D( g_SampTex, uv + BlurOffsetsH[i].xy ) * BlurWeights[i];
    }

    return Color;
}

//Vertical Blur
float4 VerticalBlurPS(float2 uv : TEXCOORD1 ) : COLOR0
{
    float4 Color = 0;

    for (int i = 0; i < cKernelSize; i++)
    {
        Color += tex2D( g_SampTex, uv + BlurOffsetsV[i].xy ) * BlurWeights[i];
    }

    return Color;
}

The shadows in Max Payne 2 look nice, with its soft edges. How is this achieved technology-wise?

It’s a render-to-texture shadow with a pixel shader blur. The shadow is blurred and faded depending on the distance from the
shadow caster. Additionally, the shadow direction and sharpness is calculated by sampling the environment. Shadow casting
direction is determined by the primary light direction and sharpness by the light ambience of the environment.

- Should be const:
bool BoolRS::operator==(const BoolRS& obj)
- In creation structures like MotionTransition, could probably be const char instead:
String    mName;
-----------------------------------------

Shared transitions:
    - different sources
    - same destination & same blend params (ex: hit anims)

- create transition with no source owner. Stored in a shared pool.
- when looking for new transitions, check shared pool first? But this can be done for some source cells only (not all of them)
 and it might break if transitions are pre-sorted by priority. Actually if we store transition pointers inside the cells,
  we could just add the shared pointers to the cell like for other transitions. We just don't own them.
- remove "GetSourceCell" and the source cell pointer in Transition, for this to work

------------------------------------------
 Now implemented using "shared transitions":
    - "group" transitions (N to 1)
    - all hit transitions have the same params (because of templates) => store them all in the same struct or something?
    - transitions "from" and "to" to group similar transitions together?
- remove recoil when camera is unlocked
- put gLastSharedTrans in SMC class
- share crouch hits & others when possible
- Pb with "Empty" call in FindStabbedObjects() => creates one alloc despite the Local buffer ...
- do the exceptions in debug disappear if we don't create the dx-level state blocks? =====> nope
- disable all camera controllers when game starts (they're all active right now). Activate them when cutscene starts.
- "mDeltaTM" in TimeInfo => store "30" or "60" instead to avoid division & loss of accuracy ==> forget it
- investigate slow camera motion inside compound => because we hardcoded a "C->SetDeltaTM(1.0f/20.0f);"
* "jump flail" => loop is now screwed up. SIGH.
* but if we run against a console after accessing it the "jump flail" starts... correctly!
=> maybe there's a new "falling" event sent over and over again?
* accessing consoles still doesn't work, we get blocked all the time =====> might actually be fixed now!
- there's still a console bug when jumping immediately after accessing one => blocked ====> should be fixed
- check the weird player up motion in cutscene after console?! ====> should be fixed
- control room console door: check weird vertical motion after accessing it ====> should be fixed
- AI: the enemies don't grab weapons anymore?! => because of the local containers!!! "GetEntries" now return a valid pointer instead
of null! The test must be changed everywhere. Probably used instead of "GetNbFaces" because it has one less division
- camera zoom for people without mouse wheel
- ENGINE: optimize custom lists in IceRMCustomDefs. Creates lots of strings for nothing. In particular the customlist could use static char* instead of dynamically created strings.
- play "watch radio" anim when incoming call? - KONOKOwatch_radio
- INTERCOM: find a way to render it on top of glow?
- render overlays on top of glow
- Puppet master:
    * turrets still shoot us
    * wait a bit after NPC death before returning control
    * make NPC visible when leaving PM
    * can the NPC carry stuff back to player? Figure out what to do when the controlled guy picks up powerups, datapads, etc
    * controlled NPC can't access consoles....
    * AI should react when controlled NPC starts killing them
    * leave npc in suspicious state?
        * when leaving, the NPC can continue running or stay blocked in crouch
    * special anim when starting => doesn't always start
        * we should only start from IDLE, otherwise the player may continue running while the PM starts
    * ban death effect when controlled NPC dies
    * ban inventory
    * restore control when NPC dies
    * leave PM when player dies
    * build the feature on top of already existing "gControlled" feature:
        * we control with the mouse/keyboard current gControlled
        * the "player" is a different character, never changing, i.e. Konoko
        * the AI can target the player or gControlled, if it's different
        * add a digicam effect when controlling a "NPC"
        * when controlled NPC dies, go back to normal player control
- ban file loading after init
    - crash on exit after file access ban
- AI: make AIs run straight when PE data not available
- skybox DDS
--------------------------------------------------------------------------------

* colored energy bar
* slowdown = portal aabb tree creation? ==> nope!
- refactor "mNbCells"/etc code (use powerup enum)
- make health display shake when hit. Shake should be slow-motion-indep
- make camera shake slow-motion indep
- Barabas: revoir camera shaking when death
- AI: I saw Muro do a back flip !!!!! What a bug ! => obsolete
- AI: in suspicious mode, random punch when close to invisible player => behaviour is ok now
- AI: sometimes the striker does a daodan dash when the throw can't be performed => can't happen anymore
- collision volumes instead of meshes ? => naaaah
- bug: PM doesn't work after restarting the level from a checkpoint? => mDeadTime not serialized => should be fixed
- make sure the camera "distance to player" is always properly reset when puppet master leaves
- investigate slowdown in depot 03 ==> "register" stuff, for some reason
- AI: when walking in suspicious mode and colliding with another NPC => don't react!
* "bottom quad color" section crashes => stack overflow
* UnrealSkinWalk crashes at loop time
* UnrealSkinWalk not added to list of files! => because loading "fails"
* barabas energy bar overlaps weapon icon
* display a weapon icon (fading in and out) in the bottom left corner
* display number of ammo & clips nearby ====> check it's reoslution indep
* preload weapon sounds
- textures des weapons en vignette pour sélection
- ICE: select "ragdoll" test and try "select meshes" ===> UI bug ===> var wasn't initialized, that's probably it
- shake boss lifebar when hit => make a shaker class => and clean that code

Gumby · 04/15/09 02:04

Epic changelist there.

Just wanted to point one thing out I found:

Sniper shouldn't be "surprised", really

That bug is around in the original Oni. I've been meaning to "fix" it for AE, but forgot. Thanks.

Also, last time I played Konoko Payne, the controls were a bit buggy seeming. I don't know if you quite know what I am talking about, but have you improved the control system in the last few months?

Also: post download link.
EDIT: I mean release download link...

Pierre · 04/15/09 05:04

Also, last time I played Konoko Payne, the controls were a bit buggy seeming. I don't know if you quite know what I am talking about, but have you improved the control system in the last few months?

Probably not in significant ways, no. I kind of like the controls right now, so I'm not sure what I should improve If you have a more accurate description of what's wrong....

TomeOne · 04/15/09 10:04

Great work on Wanted, Pierre.

Loser · 04/15/09 10:04

Harry was faster than me ^_^. So, good job with Wanted:Weapons of Fate.

I was able to make it run on my laptop even tough it is at rock bottom of system requirements ( and my integrated video card is not really friend with games). It was laggy as heck, but was good enough for a glance at the game. Better than Watchmen:The end is Nigh, which completely refused to run.

Anyway, I have read your ToDo list. Quite a lot of work, respect. I have seen my name a few times in connection with h2w and combat system. Allow me to react:

"head 2 wall" from Loser! ==> test in Striker_SpecialMoves.txt
Be sure to create check for AI whether it is too close to some wall to use this move (maybe give it some percentage chance to perform headbutt dash even if in danger zone?). Otherwise it looks really stupid, when Striker uses that move while standing literally with his nose inside the wall.

reactivate hit foot, as loser did (striker's foot ouch)
I don't know what exactly do you mean by that, but here are some tips:
- Create mirorred version (grabbing the other leg) as well. In Oni it looks weird when you kick clearly right leg and they still grab left ^_^
- Set transitions so if character performs this hit response (or hit_jewels as well) and is hit again with attack which induces one of these stuns (foot_ouch or hit_jewels), this character is automatically knockdowned. Prevents unfair spam.

And one crazy idea of mine, which I propagate whenever I can:
Create location-based hit responses, so if you hit victim into head with low shin kick (tanker style, attacker has upper ground), vitim plays head_ouch hit instead of foot_ouch. Again, in Oni it looks silly when you perform attack which induces hit_foot_ouch, you hit somebody in head because you are higher than him (stairs) and then...victim starts grabbing his foot ^_^.

I hope I don't want miracles. Just set of these animations:

Hit, Hit_behind || Hit_ouch, Hit_ouch_behind || Hit_stagger, Hit_stagger_behind || Hit_Knockdown || Hit_knockdown_behind

for three areas of the body (head/chest area, mid/pelvis area, upper/lower legs area). That would look good enough IMO.

Thank you for reading this post from somebody who has problems to create simple VCL application ^_^.

Loser

Oni Central Forum

#26 03/01/09 17:03

Re: New engine.

#27 03/16/09 21:03

Re: New engine.

#28 03/17/09 00:03

Re: New engine.

#29 03/17/09 03:03

Re: New engine.

#30 03/17/09 03:03

Re: New engine.

#31 03/17/09 07:03

Re: New engine.

#32 03/17/09 16:03

Re: New engine.

#33 03/17/09 22:03

Re: New engine.

#34 03/18/09 09:03

Re: New engine.

#35 03/28/09 02:03

Re: New engine.

#36 03/28/09 02:03

Re: New engine.

#37 03/28/09 02:03

Re: New engine.

#38 03/28/09 03:03

Re: New engine.

#39 03/29/09 20:03

Re: New engine.

#40 03/30/09 14:03

Re: New engine.

#41 03/30/09 16:03

Re: New engine.

#42 04/03/09 13:04

Re: New engine.

#43 04/03/09 16:04

Re: New engine.

#44 04/14/09 05:04

Re: New engine.

#45 04/14/09 09:04

Re: New engine.

#46 04/15/09 02:04

Re: New engine.

#47 04/15/09 02:04

Re: New engine.

#48 04/15/09 05:04

Re: New engine.

#49 04/15/09 10:04

Re: New engine.

#50 04/15/09 10:04

Re: New engine.

Board footer