Monday, June 1, 2009

Water Physics

Ya so I'm back on work today. Well for interesting stuff today. I polished up some aspects of the level editor before, it wasn't very screenshot-worthy but I put one up on the log anyway. The editor is divided into 3 parts. The "Level Editor" is for designing the parts of the level that can be described by a triangle mesh (that's land, water, and no drop zones). The "Object Editor" is for placing interactive objects. The "Environment Editor", which isn't in yet, will be for decorating the level. Anyway, the land editor is pretty good so far other than a few bugs with undo levels and other minor things, but the object editor OMFG. I didnt do any buttons or menus, so changing what you'd place and properties of them was controlled by a long list of keyboard keys (dubbed hotkeys). Of course, this was fine if just me and jon were to use the editor (which was sorta planned. The editor will be in the final PCMac builds of the game, but it will be hidden). However, I ran out of hotkeys to use (yes it was very confusing) so I had to do something to ease up the pain, which I did by adding in a circular menu for selecting the current "brush mode". It makes it a little better, as I no longer have conflicting hotkeys, although they are still used to switch the state of the currently selected object. It's not a big deal right now, not until the "polish" phase of development.


Anyway I hacked in some water / swimming physics today. It was fairly simple stuff. If the object is in water, change its gravity and friction (character, orbs, and the key float right now, and balls sink. gonna make keys sink now that I think about it). Of course, it's not an ideal solution at all right now. The character gets "diving" abilities in water. The diagram below shows where the motion is at right now, and what I want the motion to be like for final.



So like, it's not really that that motion is too difficult to implement in code. It's pretty basic stuff to do really, but the problem comes in the resulting collision/restitution physics. Physics suddenly gets much much more difficult when you introduce rotation. That's why the character doesn't rotate yet, and why I only have balls and not boxes as interactive physics objects right now. I don't half ass my work though, so one of my long term goals is to implement the Box2D physics engine into the closure engine. Of course, that's no easy task either. Box2D works best with static environments or ones where everything can be described with simple geometry. Closure isn't like that, the walkable area is constantly morphing with the light and spotlights, which makes for an exceptionally difficult job to implement box2D. Essentially, I need box2D to work with bitmap collision maps, which aren't present in the current engine, meaning I can't just plug in and play box2D, I need to hack the functionality I need right into the core engine.

Would it be simpler to just code my own rigid body physics engine? I've tried. 3 times. First try was years ago in flash, and it "worked" but was extremely unstable. The second was c++, and it worked, but had some small stability issues and was extremely inflexible. The third was extremely flexible, but had stability issues which I half-solved in the previous two, so I gave up realizing that the end result would be the same. Box2D is a lot better than anything I could do at this moment, plus what I learned from 3 tries at a physics engine will really help when it comes to hacking additional functionality into box2D.

Anyway, physics are only gonna be a minor part of this game. In my opinion, as fun as physics games can be, I much prefer a game where the physics supplements a different core mechanic, rather than being the main mechanic itself. Physics puzzles are way too random for a game like this, and I have to set up a ton of space-filling machinery in levels involving physics to ensure that the ball rolls the same way every time, and falls in roughly the same place every time. Sure, I could go all out with physics and stuff to the point where people become frustrated, but that's not what this game is about. As a result, physics will be a small part in some of the levels as opposed to a major part in all of the levels. Crayon physics is a fun game, but this isn't crayon physics.

5 Comments:

Blogger Katz said...

oooh...
water should be neat...

June 1, 2009 at 10:09 PM  
Blogger Andy said...

I really want to see a video of this in action.

June 1, 2009 at 11:36 PM  
Blogger Kevin Gadd said...

Thanks for sharing your experiences adding water so far. I've been thinking about how to implement it for my game so having your experiences to inform my design will be handy, since our physics systems are similar :)

On an unrelated note, I'm slightly disappointed to see that the new (OpenGL, I assume) Closure engine doesn't have that awesome saturation effect the flash version did - looked like Dodge blending? I'm guessing it might not fit with the new visual style you have in mind, but for me it added a lot to the feel of the original's visuals.

On the other hand, the new additions (fog, gnats buzzing around light sources) are brilliant and add a lot more atmosphere.

June 3, 2009 at 9:42 AM  
Blogger Tyler Glaiel said...

"classic graphics" will be an option, but it will be hidden

June 3, 2009 at 10:14 AM  
Anonymous Anonymous said...

This will be a great option

Online Tutoring,Home Tutor,Private Tutor

August 25, 2010 at 11:37 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home