Game-off: Day 28

Here I am again, in the final stretch of a very long game development cycle! This time, I have learned a lot about Chipmunk-js, especially its shortcomings. I've also studied a lot of new mathematical concepts and failed at art.

With just over one hour remaining in the Github Game-off, I think I've completed about as much as I could have.

Here's the list of items completed today:

• Created a Balloon class that draws "teardrop" shaped balloons.
• Implemented general item cloning (only enabled for balloons).
• Clones can be attached to some items (only the player, for now).
• Added an air flow current, represented by the ugly AC air ducts.
• Added tutorial objects that spawn after 15 seconds, intended to help players understand the controls.
• Added an electric zap from the flying saucer every time it creates a clone.

Game-off: Day 27

First two scenes are ready. The game starts in a white room, with some scientists observing your every move!

The scientists vaguely resemble human silhouettes... I came very close to scrapping all of this work before I decided it would just add some INDY CHARM.

The controls are not yet finalized, but I finally removed the keyboard controls and made the flying saucer controllable by dragging it to the location you want. I'll have to add those thought bubbles to complete these initial tutorial scenes.

The balloon is still using my basic circle class, which is why it still has the radian drawn. I'll be making a Balloon class that extends Circle, and draws more like a balloon! The Balloon class will also implement the clone controls.

Finishing scene 2 will also require a fan (or something causing an air current ... maybe just an AC duct?) that will push the airborne flying saucer over the barricade. It won't be possible to move the ship left or right while in the air.

If all goes well, I'll have the start of a real game by tomorrow, when the contest ends! :x

Game-off: Day 26

I'm still trying to develop the game style while working on the first stage. (I'm calling it a "scene" ... at least internally.) The first few scenes will serve to teach the game mechanics, so they will be very simple puzzles. I think teaching the controls will be the trickiest part, but I should be able to pull it off through dialogue and thought bubbles.

The dialogue will be spoken by observing scientists. They should be able to unintentionally provide hints to the player. The thought bubbles will come from the flying saucer itself, as if it's thinking about how to overcome the challenge.

I've chosen to do much of the art as silhouettes using basic circles and polygons, since I have no time to do a lot of drawing. It will still be very tricky, but it might also add to the creative design if I can manage to do it all well enough.

My first stab at the first scene is quite embarrassing. I'm not nearly ready to show it. Once in a decent state, I'll use all of the same renderables to create the rest of the initial stages. This should be ok. Still, I don't think I can actually get enough done in the remaining two days. :(

Game-off: Day 25

Today was a long day, since I went back to work. Actually I started early, left late, and went to see Book of Mormon. (Highly recommended!) I just didn't have time to get anything done on the game. :( I did show it to several people though, and they all liked what I had done, and what I have planned. It's just a matter of getting the rest out the door!

Game-off: Day 24

Tonight's update:

• Ambient lighting (not in use yet)
• Scenes (will act as different stages ... also not used yet)
• Blipjoy logo
• The project has its own README now
• And it's own name!

The logo is the only part you will notice. It's just something I threw together at the airport this afternoon. The invader was drawn (by me) from memory, in an attempt to avoid any possible copyright infringement. I'd like to have some different chip tones play as each letter appears to give it a more fun feeling while keeping the retro theme.

I also finally got around to modifying the README today. It gives a little bit of information about what I would like to accomplish to turn this into a game. Along with the README, I also named the game! One of my criteria for choosing the name is that the domain name is available to register. And where domain names are concerned, smaller is better.

The name is: Alienauts!

I've registered the domain, so that's ready to go. I was surprised to find that available; prior to that, I tried "saucernauts", which is already taken. And "teleclonesis" which is just too hard to say.

I also have some ideas for a title screen, which I will be working on soon. I'm considering implementing it as a procedural function, instead of an image. Much like the flying saucer animation. The advantages include making a scalable image without the SVG disease, and keeping the content nice and compact; less to download.

Game-off: Day 23

Tonight's update is another in the series of visual improvements. I have added circle shadow projections (turned out a bit different from what I expected, and I don't like the way shadows are projected from polygons now), and light levels.

The light levels are difficult to capture in the screenshot, But basically the shapes are nearly black if they are unlit. And the closer they are to a light source, the brighter they become.

Also difficult to capture in the screenshot is the light source flicker. The light on the left is created with "flicker" set to true, so it randomly turns off and on. I grabbed the shot at the right moment when the light was off, so you can just barely notice the black outline of the bulb. The background color is near-black now, it's exactly #111 in 3-digit CSS color notation. It could also be said to have an intensity of 17 on all RGB components (where full-back is 0 on each component).

Lights can also be individually colored, recolored, strobed, etc. I can make a full disco-tech with it. ahaha! Though the one thing that's missing for colored light is blending those colors with each lit shape.

Also on the TODO list with lighting is making beams. Like when emitted from flashlights, and lamp shades. This I think will not be difficult. I can just pre-render light through a clipping region.

I think I still want to adjust the visuals a bit. Might be cool to turn the shapes into silhouettes by darkening them while brightening the background. :) The background should also be more or less silhouettes, as well. Since its all I can really do as far as art goes. And I had a game concept in mind (not this game) that would use all of the lighting code that I'm making for this one.

Anyway, you should really try the demo, because the screenshot doesn't do it justice.

For the final week of the month, I will be focusing more on the gameplay elements. Especially the cloning gimmick. The attachment gimmick will also be important, but that's pretty much done already. I have a plan for doing the cloning... It will be interesting to see if I can come up with a nice little transition effect for it.

Game-off: Day 22

Sadly I haven't heard anything from our artist at all, so I'm assuming we won't be getting any help from the art department on this project. That said, I decided to start taking the visuals a little more seriously (as if that wasn't obvious from my last few posts!) I first changed the "Player" rectangle to a nice deep indigo purple. But that wasn't enough.

Then I began to investigate options for drawing ellipses with the canvas API. (Note: context2d is getting ellipse soon, but no user agents support it yet.) I found a relevant post on StackExchange which linked to this interesting document: http://www.tinaja.com/glib/ellipse4.pdf The post also included some code that I sniped. ;)

With an ellipse function available, I started to animate it. First by adding a slight rocking motion with rotation, and second by stretching the ellipse slightly vertically, which gives it the appearance of a circle laying on its side in an unstable gyroscopic spin. Then I added a line that spans the diameter of the circle, to provide some context for the rotation. A small dome cap and "hover beam" complete the look of an animated vector flying saucer from the 1950's!

I also adjusted the colors of the dangling poly, and rope. The rope also looks better with a bit of stroke. Dimming the lights also adds to the ambience, so that's a nice touch.

Finally, it still runs acceptably well on iPhone 4S!

Notably, the flying saucer does not cast a shadow. ;) That's because circle shapes are not yet supported for shadow projection. These should be a lot easier than polygons, because I just have to calculate the tangent lines from the circle shape. And I already do that for the lightbulbs! (Also needs support for line segments for shadow projection.)

Game-off: Day 21

Mostly fixed the vertex bug in shadow projections. There's still a rare case where it chooses a vertex incorrectly that is at a very similar angle to the optimal choice. It's probably just a calculation error, something like using asin when I should be using atan. I don't know just yet.

I also have multiple light sources working well on iPhone 4S. The demo runs at 45 fps on iPhone 4S with two light sources that both have an intensity radius of 100px. The heaviest operation is the radial gradient, so a smaller radius is much better. When I start doing beams of light (flash lights, lamp shades, etc) I can experiment with linear gradients, and see how much better they perform. Not that they will look as convincing. ;p

The screenshot above shows an interesting side-effect of computing the shadow projections from individual objects instead of treating the light as a single flow; beams of light appear through the "cracks" between two touching objects. I don't mind it, though. The last remaining vertex selection bug is more annoying.

Game-off: Day 20

Still doing the lighting thing. I have the vector selection (and tangent lines to the light source) mostly working, but there are a few kinks left. When this is done, it will definitely look more realistic. The next item could be bump mapping, but I might just be wasting valuable time working on the presentation instead of game mechanics.

Game-off: Day 19

This morning I fixed the problem with the negative shadows. I decided to replace the clipping region with a back buffer that draws the gradient and then subtracts the shadows (using globalCompositeOperation). It fixes the bug and allows multiple light sources. Performance starts to drop in iPhone 4S when a second light source is added.

The second thing to fix is choosing the correct vertices to project the shadows from. I think the best way to do that might involve voronoi regions, but it still won't solve all cases.

A second idea is calculating the angle between the light source and each vertex in the shape. Recording the min and max of each. For more accuracy, I will have to use the radius of the light source instead of its center of mass. That's something I haven't really thought about.

Game-off: Day 18

You're not seeing things; I actually did skip a day of my daily blog! Oh, I'm so ashamed. :(

My only excuse is that I was preparing for a flight, while studying some vector mathematics so that I could do simple 2D shadow-casting. So I slept only 4 hours, then I started coding on the plane. Welp, it just started working about an hour ago!

It works pretty well, and the performance is even great on iPhone 4S.

It's important to note this is not dynamic lighting; it's faked using canvas clipping regions to draw only outside of the "shadow" area. There are a couple of known bugs: First, the shadow will be cast from an incorrect vector when the lightsource is very near to a solid shape. And second, when two shadows overlap, it will display as a beam of light instead.

The first bug seems like it will be kind of easy to solve; The shadow projection is done from the body's center of mass. It should really be projected from the vector nearest to the lightsource. The second bug may be very difficult to fix. I'll have to investigate some options for that*.

The difficult part of implementing this was getting the math right. It essentially just casts a bunch of rays at the solid objects within the light radius (using Chipmunk-js vector math functions). To calculate the width of the shadow, I used the vector normal (perpendicular to) the axis between the lightsource and the solid shape. A dot product on each of the vectors within the shape creates a projection on that vector normal, and we can use these projections to find which vectors project the farthest distance apart. (This is very similar to the projection step used in the Separating Axis Theorem for collision detection with convex polygons.) Then just cast some rays away from the lightsource, starting at the two vectors at the edges of the shadow.

* The "beam of light bug" is caused by using the clipping region to "render" the shadows. There's a default region which covers the canvas, and then each shadow is created as a polygon with reverse winding, so that the areas covered by shadow won't be drawn when I fill the radial gradient. Any reverse-winding sub-paths that overlap will alternate between hiding and showing the pixels within those regions.

How to fix it? With a single lightsource, I can just use point queries to detect whether a vector on a shadow appears within another shadow. But with multiple lightsources, things will get too complex to solve, I'm afraid. Maybe there's a way to fix it by fiddling with different windings?

A better option may be using globalCompositeOperation instead of clip. ;)

In any case, it's a good start, no?

Game-off: Day 16

Weekend over. Did nothing. I suppose you could call it "research" rather than "development". There are still some ideas floating around, but until they manifest, there will be nothing to speak of.

Game-off: Day 15

Null

Game-off: Day 14

Weekend is here. Two weeks in. No progress at all during the latter half of the last week. There has been some discussion here and there, though. So we haven't all given up just yet. Tomorrow (after a REALLY good sleep-in) I'm going to begin developing the transformation functionality, controls and GUI. I have an idea in mind that should be pretty quick to implement.

It seems like we'll also start on the server API, which is exciting. I'm interested to see how that will work out!

Game-off: Day 13

Heard back from two of the four people I'm working with. Everyone has just been busy with other things, probably more important things. Myself included.

I want to spend all weekend trying new stuff with the engine, and finding a "safe" limit to number of Chipmunk-js bodies and constraints for iPhone 4S. There are some puzzle concepts I'd like to experiment with, at the very least to rule them out "early". We'll see how that goes!

Game-off: Day 12

Nothing today! Just work, work, work, work ...

Game-off: Day 11

Nothing for tonight.


I talked with David today, and he has some really good ideas for early puzzles. I can begin to implement them, but I would like it all documented to ensure I don't miss anything.

Unfortunately I didn't get anything coded. I was researching an idea to make asynchronous programming better, when I got side-tracked and started researching Go. But enough of that. It's time to sleep, and maybe imagine some fun and interesting physics puzzles! :]

Game-off: Day 10

I spent some time today looking into the performance issue again. All I came up with is that disabling physics helps a lot! (How obvious is that?) I couldn't necessarily rule out collision detection as the culprit. I was able to rule out drawing operations as a problem; they are all incredibly fast!

In any case, more than 10 bodies and more than 10 constraints in the space is enough to start slowing the simulation on iPhone 4S. That's a very unfortunate limitation that I'll probably just have to skip for now. I'll come back to it later for sure, because I want to do mobile games, too.

In other news, my partners in this project have gone silent, so I guess I'll be lone-wolfing it. Dunno what I'm going to do with it, however.

Tonight's build only has an updated copy of Chipmunk-js, which fixes a bug in the collision callbacks (not that I'm using them yet, but I ran into it while developing Neverwell Moor, so I'm glad it's resolved now!)

One thing I need to work on soon is the README. I'll just put some basic details about what the game is supposed to be, and hope it can get to that point by the end of the month.

Game-off: Day 9

Performance woes!

A large number of Chipmunk-js shapes on iPhone 4S (running iOS 5) can cause unplayable frame rates. I didn't anticipate that when I added the chain; all those rectangle segments kill my poor phone. I spent tonight unsuccessfully trying to solve that. First I created a new Line object, hoping that changing the chain into a series of line segments instead of rectangles would improve things. It did not.

I ended up repurposing the Line object to draw the floor and slope (finally!) The performance problems persist.

I may have to attempt porting the spacial hash to Chipmunk-js to get some decent performance out of it. :(

No screenshot; looks the same as yesterday except the floor and slope are drawn as straight lines. I spent a lot of time on this tonight and did not get the results I was hoping for.

Game-off: Day 8

Chains and pulleys.

I had a feeling adding support for chains would not be too difficult. However, it took just over 4 hours to get it all working. The difficult part with this one was positioning the chain segments properly. When they are placed incorrectly, the physics simulation corrects them by applying forces, which causes horrific jitter.

(Clicky for make big)

As part of the positioning, the rotation of each segment is also important. For this, I just used Chipmunk's excellent vector methods. The first step is getting the difference between the vectors, normalizing them to 0..1, and finally converting the resulting vector to an angle. For the position, I just use Chipmunk's built-in vector linear interpolation function. It's excellent!

There's one known bug that the segments nearest to each point on the chain are initialized with an incorrect rotation, and the positions are non-optimal. It creates a little bit of jitter, but it's not completely broken! It could be better.

The pulleys are just circles which are anchored to the default static body with pivot joints. Friction causes them rotate as the chain slides over.

The other obvious change for tonight is that most objects (but not all) are initialized with a random color. This was part of an API update for the object constructors.

Game-off: Day 7

Touch controls.

That is the theme of tonight's update. I know, I know... these updates are very sparse! I'm trying to spend time outside of game development and work. For the past two nights I've only spent a total of an hour hacking on this project!

It's not worth showing a screen shot tonight, since it looks the same as yesterday's build. The only thing that changed is the addition of mouse and touch controls. It should work on touch devices now. Move the large pink rectangle left and right by touching the sides of the screen!

That's all.

Game-off: Day 6

Player controls!

Tonight I added a really basic "Player class" that creates a fairly large pink rectangle that is controllable with the keyboard. (Sorry! No touch support yet for mobile devices... That's on the TODO list!) Keyboard controls are left/right arrow keys OR A/D keys to move the rectangle left and right. It's pretty easy to get the simulation into a low entropy state because of the limited control you have over the Player entity. ;(

However! This is part of the plan! The Player entity will be able to change its physical properties, such as mass (heavier or lighter), elasticity (bounce!), and attraction (magnetism). These, combined with cloning and attaching to clones with ropes will add some much needed game mechanics to make the world less static, more interesting!

(Clicky for make big)

Yep, please take note the ugly "programmer art" makes the game uncomfortable. Even if I had a static background and a player sprite with 3 frames of animation, it would look like the game was 50% complete. Instead it looks like 10% of a pre-alpha build! :p

I'm waiting for our artist to come through with some sweet graphics, soon. But all I can really do is bang out some more code while I wait...

Game-off: Day 5

Day 5 is done, and this blog post is late! (Typical, really.)

Today was all about integrating my rope implementation into the game.

(Clicky for make big)

The ropes are pretty much the same, except I can now attach them at arbitrary points on the bodies (not just the center point). I also changed the damped spring (between the two control points) to a normal slide joint. The damped spring was too difficult (impossible?) to tune such that its max length would be 1/3 of the total rope length. That's because the actual length will depend entirely on the forces moving the control point apart, and the strength of the spring. A slide joint works well enough anyway.

The most difficult part was getting the rope to draw properly with the offset anchor points. And that's because when the bodies rotate, you need to rotate the anchor points as well. I knew Chipmunk provided a function to rotate vectors, but I didn't know how to use it until I spotted this forum post. The body.rot property is just a vector composed of the cos() and sin() of the body's rotation angle. So simply rotating the anchor vector by the body.rot vector makes it all magically come together. It's a thing of beauty! :D Thanks Chipmunk! I love you.

Game-off: Day 4

I'm so ashamed! Didn't get anything done today at all. :(

Been thinking a lot about how to make the ropes work properly. The demo shows some promise, but there are still a lot of unknowns. It will require a lot of tuning to look decent, I think.

The game design at the moment is very poor. There's no documentation to speak of, so no one really knows what we're supposed to be building. It also doesn't help that a lot of us also have previous engagements that we can't break. The concept sounds easy in just a sentence, but the details are all a blur; what kinds of puzzles/challenges will the player face? Can we always guarantee a solution when dealing with the unpredictable nature of physics simulation? Who knows...

Erica asked something today about Tornado, so it's really cool to see her getting into that. I'm hoping she can integrate Pymunk into it for some server-side physics simulation. That would be amazing.

One week down. Three to go. No game at the moment.

Which reminds me of this highly accurate graph:

(Source: https://twitter.com/BenjaminCousins/status/233175644127756288)

Self-explanatory, I think. But this is how game development is. We're about 1/4 from the left on the time scale, where it should be about 1/4 away from shit (the red line). But it's still exactly at shit (the blue line). So far, all is going according to plan!

Game-off: Day 3

Suppose it's about that time, again!

Today I decided to try my hand at drawing a decent physics-based rope. I didn't spend a whole lot of time on it, so the result is pretty surprising for the time investment. :)

Clicky for make big:

This example renders two objects (a blue circle and a yellow circle), a black rope, and the two "control points" (used to draw the curve for the rope). In a game, you wouldn't render the control points. They are here only for debugging purposes. You can click and drag the blue and yellow objects around, and watch how the rope stretches, bends, and twists with the physics.

It's far from perfect (you can break the simulation easily by forcing the objects through the floor, and the rope will happily stretch to infinity if you let it) but it's a good demonstration of how easy it is to do fairly complex things with Chipmunk, melonJS, and a little creativity.

How does it work?

The shapes (four circles) are attached with joints in a specific order, and rendered with a cubic Bézier curve. The two object circles make up the end-points on the curve, and the two control circles are used for the control points. The blue circle (aka P0) is attached to the red circle (P1) with a slide joint that has a min length of 0, and a max length of 100. (I initially tried an even simpler pin joint, which has a fixed length, but that caused real badness when the control points collided with the ground, making the rope go in odd angles.) It's the same slide-joint-setup between the yellow circle (P3) and the green circle (P2).

With this configuration, the rope acts really unnatural, because the control points can (and often do) move in arbitrary and independent directions. My solution was attaching the control points with a damped spring joint. In the demo, I used a rest length of 0 on the spring, and set the strength and damping to 10. This makes the spring act a bit like a pneumatic pump; it takes a good bit of force to slowly pull or compress it, but it wants to compress completely.

The end result is fairly convincing. In fact, we'll probably use this rope-rendering technique almost verbatim in the final game! I'll be using it for the "attach" gameplay mechanic. Expect to see ropes attached between rocks, balloons, rubber balls, etc. It should be fun to play with!

Game-off: Day 2

Today I added some more physics objects to the demo:

• Circles, which can be heavy or lighter than air (act as balloons)
• Joints, which I've used to attach balloons to squares, so they get carried off, and a pivot to create a very basic catapult.

It might be difficult to tell what you're looking at in the screenshot, but everything is color-coded anyway, so we can use that to explain what's going on!

(Clicky for make big)

• The long "olive green" rectangle is the catapult. It's anchored to the space at its center point.
• The "royal blue" square is a very massive (heavy) object.
• The "salmon" colored rectangle is a very light object, which has just been thrown by the catapult, due to the weight of the royal blue square.
• The small red square is a weight attached to the dark green balloon.
• The light green rectangle is weighing down the dark green balloon (along with the red square).
• The blue square is attached to the orange balloon, and the purple circle is weighing down the balloon (same as the other group of objects)

You may have to refresh the demo if you've tried it before.

This demo shows that it's remarkably easy to add new physics interactions to the space, so that's very promising! We'll have to make these objects classes a little more useful, but they get the job done for now.

Game-off: Day 1

Today we came up with a game concept, and I began the process of bringing the game engine and physics engine together. I added a super simple class that creates boxes and drops them onto a slope (an invisible slope!) to test the physics.

Here it is (clicky for make big):

WIP Blog... Migration Imminent

My old Lightblog, while very lightweight, is a hassle to maintain. So I've decided to move to a hosted solution. WordPress wanted $13 (per year!) just to allow my domain to point at their service. So I didn't give them a chance beyond that. (Note to service providers: Don't nickel-and-dime me for features which cost you nothing! For the record, I have the same problem with github and their private repos; though that costs $7 per month.) Tumblr has the worst uptime of the major blog providers, according to Pingdom. LiveJournal is old hat. Etc.

It turns out, I created this blog (Blogspot/Google Blogger) way back in 2007, and never used it. Google doesn't care if I point my domain at it. It can be made fairly minimal (sort of). So, what the heck... I'm moving the blog here!

Since Lightblog uses a proprietary sqlite schema, I'll have to write a quick converter to get my old posts migrated. In the meantime, the old blog is still available, just at a different URL: http://oldblog.kodewerx.org/