@mmachida The scoring was determined a bit like par times in Doom. While with Doom they made par times a bit longer than what the designers could beat their levels, we made the par time (100% time score) a bit faster than what we could beat the game. This was just in case someone would be better at the game than us - which clearly just happened, since our high score is 96%. Congrats on beating our high score :D
Recent community posts
First my two cents: Software has requirements, which could be hardware, other software, or even access to external services (eg. OpenGL 2.x capable GPU, wget binary in $PATH, or a Twitter access token, respectively). I don't see how requiring a Python or Ruby interpreter or a Java runtime environment would be different.
That said, pragmatically, you can easily have very good reasons to statically link and/or bundle as much of your requirements into your final distribution as possible. If we're talking Java, you could check out LibGDX's wiki on Bundling a JRE (there's not much LibGDX specific on that topic). The wiki page warns that your distribution's file size will grow abou 30 Mb, which may improve with Java 9.
I'll continue a bit upon that previous post. Let's elaborate a bit on the end product, just a bit. I'll be uploading it to itch.io soon-ish, but let's gum about it a bit first.
So the initial theme was Robinson Crusoe in Space. We wanted to stick to the theme "Life in Space", and avoid "Deathbringing in Space", but that was just our design choice.
Of course the initial plans were crazy big with a planet with complex ecosystems of flora and fauna, and some exploration thrown in the mix. We quickly started to cut features, 'cause "the last 10% is 90% of the work" or something like that.
Eventually, after the new year's we were settled on the final concept: An alien creature (alien = not human) shipwrecks on a planet. There are plants whose fruits you have to feed to flies to make them grow. The goal is to not kill the planet, and to grow a single fly big enough to fly home with it. We decided that the feature list would not grow from that.
We did cut features from that, though. And it was all for the better! There was no an infinite bag of fruit that the alien carried with them, and there was just a single fly. You couldn't hurt the planet direclty, but you could ruin its atmosphere with too many fruit spore. We told ourselves that we'd return some cut features if there was time to spare. Of couse there wasn't, but we can always continue this project in some form in some point the future, so there's always hope.
We wanted to apply a gravity like in Angry Birds Space. I do remember being excited about how to implement that, that's for sure. It didn't end up playing a huge role in the game, but you can achieve a game over via leaving the gravity field.
The one neat thing that I like was the camera. You'd run around the small planet and the camera's position and angle would be fixed on you, not on your environment (see "Yoshi's Island's Raphael" in the second post of this thread). I was really excited about that, and how that would - especially with some interpolation mixed in the parameters - lead to some potentially disorientating visuals. I think it turned out great, but I'm sure you could do so much more with a camera like that. (Now that I think about it, a 2D Descent could have a camera like this :P)
Well, that's it for now. There's still a couple of hours left of the jam. Make the most of it, everyone :)
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
Ok, Christmas celebrations are beginning to be behind us. That unfortunately means it's been a bit of a slow start. But that's fine, the wheels might be slow for now, but they are turning :)
What I've done during Xmas is refamiliarized myself with Box2D, and it should do just fine for us. And one picture is worth a quite a few words, here's
two three(?) demonstrative images on the stuff we're going for. (And yes, in first two of those pictures there is a global gravity in space pointing down :P)
If that reminds you of Yoshi's Island's Raphael the Raven and Angry Birds Space in the slightest, then I'd say you know what we might have been thinking of during our kickoff (nice going, comparing our tiny jam game to two big name games...)
Well, time's a ticking! Next time I try to show some more than just pastel lines on black canvas! (or you know, stuff I've already posted on twitter (warning: trippy colors))
Hi, it's me, Northburns! I'm joined by my brother ippekun and cousin kueskol. Since "on computer you have to call [it] something" (Ringo Starr, 2005) we're calling ourselves collectively as 2BC. And this is our LibGDX 2015 Jam DevLog!
Due to all sorts of preoccupations, like day jobs and Christmas preparations, we couldn't start before 22nd. As such, let's keep this first post short; we're already running late. Future ones will likely have more substance. But that's ok, let's do this :)
Let's Go Bowling!
Our game most likely won't include bowling. But it's our project's working title. What our game does have though, is a shipwreck on a foreign planet. Think of Robinson Crusoe, but in spaaaace! (maybe the hero was on his way to go bowling..)
What we're trying to do here is a super-simple roguelike survival game. We had a meeting discussing our expecations, ideas and what not, and I'm now hard at work doing initial prototypes of some of them. Oh right, this is a jam! What I'm writing now will be in the fina l product. There's no time to lose!
So that's how I'm spending the little me-time I have this Christmas. Ippekun and kueskol are doing art mockups and stuff over the festives. We'll be meeting soon after Boxing day, expect some more coherent thoughts to appear in this log then :)
You can follow our progress on this dev log, and on our Bitbucket repo here: 2BC at Bitbucket
Hi! Nice to see such a huge crowd!
I'm Northburns and I'm joined by my brother ippekun and cousin kueskol. We're aiming to just have some fun with this jam, not stress it, and simply try to push something small and fun out. The holidays will sure tax our time, but we are very excited!
Happy jamming, everybody! We're already running late, so I'll just keep this brief and get hacking ;)