Hi, it's been almost three weeks since last update here. Now that's a bit embarassing, but that's fine. At least we made a few twitter posts, which I've linked here :)
- A proof of concept shader
- Box2D world, that ultimately remained pretty much unchanged
- Placeholder art, and camera movement
- First gameplay tweet
- Gameplay tweet with final art
Creating a game in a month (with us slacking off a bit during the holidays, it was more like a week :D) was quite neat experience. It pushed forward the practical, and forced us to pick something and run with it. That was really nice.
As the programmer of our bunch, I'd like to raise a couple of technical observations here.
Faking some physics
First things first. Physics is fun, ok. I enjoyed it a lot in school, too.
So I have to state that I cringe a tiny bit everytime I look at the classes GravitySource and GravityTarget. But hey, we went for the Angry Birds Space gravity, so that's fine. And I do cringe in a good way ;)
Box2D is fun, but play by its rules, and also prepare to tweak your numbers and stuff
At first, the fly that circles the planet, had its position set with setTransformation(position, angle). This was fine at first, but then we wanted it to drop a ladder that would be attached to it and drag behind it. A few joints and bodies later, it broke.
Setting the position of a body is like teleporting it, and it'll make stuff wierd in Box2D (and many other physics engines, I'm sure), namely here with the joints attached to the teleported body (Box2D calls this "unphysical behaviour" :)). Sure, I knew that. In short, teleporting the fly with a simple function (that alternated it's height with a simple sine function) was simple and safe, but didn't play cool with Box2D.
I then spent an afternoon tweaking some linear velocities for the fly, that would erratically move it up and down (kinda like an actual fly) around the planet. The fly would notice if it was too high or low, and correct its velocity. It turned out fine.
And of course, we finally decided that the fly would first stop totally, and then drop the ladder, rendering the above purely academical. But I like academia, so I'm not complaining :)
Animation is involved
I don't know what I was thinking, but I somehow managed to totally overthink the animation implementation. All I wanted was to make it simple to define animations, but good intentions pave roads and yadda-yadda.
The short version is that the current animation stuff in practice requires all animation frames to be exact same size (not in theory, but makes everything simpler in practice), and that's a bit wasteful. It also requires defining the origin draw point of the frame (the frame will be drawn to the "actor's" point in the world, what point of the frame should be "anchored" there). Well, this lead to the unfortunate anagnorisis that changing the sizes of image files would lead to quite a bit of remeasuring and json modifying by hand.
Before my next venture in game programming, I'll be sure to look into how other people have solved this particular problem of defining sprite animations. I'm sure there are a slew of wonderful solutions, we were just stuck with one particularly naïve one :)
Shaders are cool, I wanna learn more
In our very first get-together, we talked about how neat the "black and white" theme would have been too. We wondered if we could apply that theme as well, but not as that binding one as the actual theme.
I had just started reading about shaders (yeah, I know, don't make jam projects learning projects. I shouldn't have, but in retrospect everything turned out fine this time), and we came up with an idea. What if everything was black'n'white, but we applied a shader, that could change what black and white were in the texture! So a gradient from black to white, applied with our shader, could become a gradient from blue to red, for example. And it would be simple to change the colors on the fly. Heck, see the first tweet above. The shader more or less works as specified.
We just didn't come up with any actual applications for it! Sure, in one tweet, you can see the planet's colors pulsating a bit. We did end up applying it to the atmosphere of the planet, and shading it towards green the more polluted the planet got. But that same end result could have been achieved with basic blending (batch.setColor(...)).
But I did whet my appetite for shaders, for sure! I do have to mention Libgdx Cross-platform Game Development Cookbook for providing a good platform for jump starting my affairs with shaders. I'm sure I've only scratched the surface on them :)
Entities and their components
Ok, sure I've made some spike tests with Ashley. I've read about it and other ECS implementations. But it really didn't click until now how really awesome an ECS can be! Sure I knew they could/would be, but implementing a game even as simple as ours really gave me some really nice concrete examples I can wave at people who ask me about ECSs :P And I'm sure there's stuff to improve in how we applied Ashley to our game! I remember reading that "purist systems" are stateless. I don't know where I've gotten that idea, but our systems certainly have state. It didn't pose problems here, but maybe in some situations it would. I'm sure to return to at least that open question in future endeavours.
Box2D, one more thing...
Uhm, you can't resize bodies and fixtures in Box2D. That came as a surprise, initially at least. Setting the size to something would kinda be like setting the position, so that wouldn't play nice with other things in the Box2D World, so that's understandable.
So, having a fly that changes size would require to either:
- Make a body that has fixtures that curl around themselves and some neat joints to create a body that's circumference can be adjusted by adjusting the joint angles between its fixtures
- Destroy the body and recreate it with a different size everytime the fly changes size