Hey every seven of you! We’ve officially opened up the Dinowaurs beta to the first wave of the Kongregate community. We’ve been floored by the response from everyone and we’d like to thank everybody for their interest and excitement for Dinowaurs.
In other news we’ve hit 1000 commits. I even recorded a video of the whole boring process, but turns out, it was more boring than youtube could probably handle, so instead we bring you this much more exciting “Speed-paint” of Mike coding up the Dinowaurs menu from about two months ago. Now Feast!
Bit o’the old update fer you fine folken. I been workin’ on PP:AFAA and, by extension, Melba Toast pretty good the past couple days, and boy oh boy is she startin to come ’round. I s’pose it’s been a long while since muh last post, so I reckon I start at the beginnin.
Separating your timestep from your framerate! I found a good post on gaffers blog about physics and fixing the timestep to ensure stable and consistant physics. Previously I had thought that using a delta time variable would ensure correct integration of physical movement in my physics simulation, but not only is that not enough but I was using the most horrible integration algorithm possible as well as allowing for wild fluctuations in the delta time variable. Gaffer has a two parter, here’s the second part, on physics simulation.
The first part is all about using RK4 integration to figure out f=ma, I didn’t take the time to really understand the algorithm because apparently I’m a bloody idiot and think Euler is fine enough for PP:AFAA. Also integration scares me. The second part details a simple method to ensure the delta time variable used in your physics simulation is the same regardless of the actual framerate. Put simply, you wait until a minimum amount of time has passed, for me its 10ms, until ticking the simulation. If more than 10ms passes during one frame, then tick the physics simulation as many times as you have to in order to “catch up”. Its bloody simple and increased the consistency of the prof’s movements considerably. And no need for scary integration. I’m still using Euler mostly because its faster than RK4, and when I have more time I’ll implement both and see if the increased accuracy is really worth the performance hit.
Vector Art All Around! Yeah, there was some discussion about using raster or vector art for the assets in Flash, I was thinking that bitmaps would be faster than vector arts and after doing some simple tests trying to display about 3000 PP:AFAA boats in vector or bitmap of multiple sizes and small bitmaps did prove to render faster than vector stuff. It was a difference of about 10 fps, and in return we got boats and a professor which look like dogshit when rotated. In short I’ve decided to go vector for everything which is gonna work out great for scaling, rotating all all that fun stuff. I was even thinking today about dynamic zooming and got all excited. Not sure how that’ll fit in with the tile management system, but damn it would be cool.
Sweet Console Command Stuff Spent a bit of time today with my console, trying to figure out how to do console variables for in game tweaking. The end result? Now I not only have the “fps” command, but you can set the prof’s accleration variable with the command “porpAccl=X”. Also I fit in a command history thing so you can cycle through all the commands you did throughout the current game.
I was trying to find a good way to register console variables and the best I could come up with was to create a new child class of Console, PorpConsole specifically for PP:AFAA which has a reference to the prof object and then I hardcoded the parsing for the “porpAccl” command and the variable it changes on the prof. This isn’t so cool, what I originally wanted was to give the base Console object a dynamic list of handles and function calls which could be registered at run time, this way each object which needed a console variable or some other kind of console functionality could just register it remotely and this could be turned on or off from each object individually. The way I have it now, all the commands and their functions are controlled set right in the parse function of the PorpConsole class, its all centralized and crappy.
Also Splashing He splashes when he gets in the water. Neat. And I drew some clouds. they are pretty.
Finally squared away the actual movement for the Prof himself… This was actually really agonizing and horrible more due to my lack of experience working with the trig functions of Flash than anything else, but damn this took a long time. I tried about 4 or 5 different methods for controlling the Prof both in and out of the water and I finally settled on a hybrid of vectors and degree modification. In actuality, the player is only in control of the directional vectors which move the Prof around in the gameworld, this allows for the easiest level of switching between aerial and aquatic maneuvering, though moving through the air and moving through the water are very different.
Essentially there are two modes of interaction, one for in the air and one for in the water. When the Prof is in the air, the player can “pull up” or “push down” similarly to a flight simulator. Pulling up will create a certain amount of lift, which is always less than the effect of gravity so the best you can do is glide a bit. Pushing down will increase the downward force in addition to gravity and lets you plummet to the ground more quickly. This is the simpler of the two control schemes, as you just have one acceleration vector which has both directional and magnitude. The rotation of the sprite is calculated by a simple trig function.
When the Prof is in the water, however, it gets horribly complex. First off instead of one vector there is now a scalar velocity value and a unit vector which is the Profs orientation. The rotation of the sprite is calculated with trig using the directional vector, just like above. This is the crux of what I was going for, so that the vectors controlling acceleration would be in control of the rotation of the sprite and not vice versa.
I ran into a problem, however, as previously in order to rotate the Prof in the water I could simply rotate the sprite and re-calculate the directional vector. Now that I wanted the vector to determine the rotation, I had to figure out how to change the vector to simulate an rotational object and maintain it as a unit vector. I’ve never used this kind of math before so I was fairly out of my element and I wrote about 3 different methods to attempt to change the rotation smoothly, all of which created a total clusterfuck of random rotations and what have you. I never really figured out what was wrong with those algorithms, even though I spent a few hours trying to fix them. I eventually decided to use pure math to control the vectors with a much more elegant solution.
Here it’s gonna get triggy and wavey, so bear with me. I created a new value, a 0 - 360 control value which represented the current rotation of the Prof while in the water. From this the directional vector could be calculated and from them the actual sprite could be rotated. Why this is better than simply using the rotation of the sprite as my guide I really don’t know anymore, though they seem to be essentially the same thing.
Anyway… The Y component of the vector, which is vertical movement, is determined by a sine wave with no offset. Essentially I use my new rotation control value and feed it into a sine wave every frame, and the control value determines where along a single period waveform the Y component of the vector is. Essentially this means a control value of 90 will make the Y a maximum, a value of 270 will make the Y a maximum negative value and values of 0 and 180 make it zero. The X component is determined the same way, using the same control value, except its waveform is offset by 90, so where Y is zero, X is a maximum (either positive or negative), and where Y is a maximum, X is zero. This is all pretty basic trig, but it took me a while to get up the nerve to trust myself to use it and figure it all out.
The final step was to make the transition from air to water smooth… which was more frustration, but I got it.
This was a pain in the ass, but now it’s pretty much what it needs to be. Now it’s pretty much all about tweaking for proper results.
ALSO, if you play around with the jumping out of the water, you can see that when the framerate is really low you can jump much higher than when it is high. This is ’cause I haven’t decoupled my physics from my framerate… I never had the problem well illustrated to me until this, so It’s neat to see the problem in action.
So, I spent some time getting back to PP:AFAA today and worked out some hacky solutions to the floaters. Getting buoyancy to look good was actually fairly challenging for my tiny brain, however I created a fairly convoluted algorithm which should supply all the requirements for the prof. This got me thinking hard about the purpose (porpoise? haha!) of Melba Toast and what exactly I am trying to accomplish with the engine. The original intention of the engine was to create a fast, reusable codebase which I could go back to for multiple games and maybe share with other developers (though i’d probably have to start commenting…) who are trying to accomplish similar goals. This is especially important for Intuition as our goal is to create multiple games on a shorter time frame in order to iterate on lots of cool ideas, find a broad market and have fun.
The problem is that engine development is not quick, it takes a lot of work and research to find optimal algorithms for every facet of functionality, and while I can work with the unfinished engine to create quick games like PP:AFAA, I have to fill in the missing functionality with hacks which don’t take as long to research and work fine enough in the mean time. So this gets to my point, which is I am struggling with deciding whether to take a longer time to write solid code now and take a lot longer on development for negligible short term benefits (i.e. PP:AFAA don’t really NEED collision based on separation of axis theorem or a spring system) or do I just hack it up and get it out the door? I need to learn how to do it the hard way, but I’m also a lazy american who wants it and wants it now.
The obvious third option is to use an open source physics library like APE or Motor (though i’m not sure Motor is going to be freely available) though the obvious down side of third party physics solutions is that they are not tailor made to my specific problems and I don’t know their interfaces…
For now I’m hacking it, and if I need to I’ll fix up the code later. That’s generally the accepted choice of game development, from what I understand, but as a programmer I still hate writing code I know is bad and needs to be replaced.
We’ve been working full steam on PP:AFAA tonight, and I’ve finally gotten back on track with Melba Toast and breaking out teh codez. I actually started out on prototyping water yesterday and thought I’d have an easy time of getting some wave action going… Boy was I wrong.
Actually in theory, it would have been pretty simple to just throw a line on the screen and use a sine wave to do some nice wave effects and the just move on. However, I have decided to use Melba Toast in the most responsible manner possible and that means avoiding shitty shortcuts and hacks. I determined that I wanted my water to be a tile, which means it has to be subjected to all the culling algorithms I wrote for my MelbaTiles. This set me right in the face of one of the two problems my tile engine currently has, the other of which is I have no faculty for actors which are able to move across the tile sectors (see Tile engine tutorial to get an idea of how the tile system works), and I only register tiles with the sector that contains their registration point, i.e. the upper left corner. This second issue is a problem for any tile which overlaps two sectors or especially tiles which are larger than a sector. I decided that the water shouldn’t be split up into multiple objects, a decision I may change later for efficiency, which forced me to solve the problem of super sized tiles before I could even make my water show up on the screen.
So anyway, I came up with 14 different cases of tile orientation on a single sector and was about to write up a massive nested if() clusterfuck when I remembered the collision lessons the Metanet Software crew (makers of N, check it out) released. Using their “Maths”, I was able to reduce the statement to about 8 lines of code and was very pleased with myself.
Long story short, there is no longer a limit to the size of tiles Melba Toast can support, and we got neato water effects, though it’s not too dynamic at the moment. You can use the arrow keys to scroll around, but you can get lost quick.
Also, tilde brings down the console, though the only command right now is fps.
You are currently browsing the Intuition Games weblog archives for the mike category.
