I have no explanation for why my graphics make copious use of rainbows:
Likes food, water, oxygen, etc..
Qeelom - xCode user
Awarded by Peter
on April 24, 2012
As is my custom, I started out by writing a physics engine. Right now, my game looks like this:
Now, all that’s left is to add some gameplay, which is the easy part. Oh, and art and stuff. My idea is to make a game where the player is constantly in motion and leaves a trail behind them, which they can later use as a platform. Thus, I’ve made a physics engine capable of handling circle-parabola collisions since the player (who will be represented by a circle internally) can leave behind parabolic paths*. I’m also planning to use two-button controls – one to jump, and one to slide along/under things. I’m hoping that I can make some interesting puzzles using the mechanic, though I’m not entirely sure yet – I don’t want the game to end up just being “player gets confused and suffocates in their own paths”.
*Strictly speaking, a player walking on a parabola does not follow a parabolic path, but we’re gonna pretend like they do by fitting it to a parabola. Hopefully that looks okay.
It’s been a bit too long since I last did a Ludum Dare. I’ve decided to fix this. Moreover, to make the most of the beautiful New England December, I have selected a fitting place to work:
Hopefully it doesn’t rain on my parade (or snow). As always, I will be using Processing assuming my programming skills haven’t atrophied from overuse of Mathematica. I expect everyone else to mentally prepare themselves for
the highest caliber of art they’ve ever seen particularly bad programmer art.
Well, progress is still being made; I have “decent”* graphics, and the levels are starting to be somewhat interesting. I think I’ll have something which is fine enough for the Jam though. Right now, the ninjas are throwing weapons at buttons to cause platforms to move, hitting multiple things with one throw, and kicking up dust when they run. Also, there are 6 (mostly tutorial-ish) levels – all to be completed by the ninjas in 10 seconds or less.
(*many other people would call them “programmer” graphics)
Well, my game wasn’t exactly “finished” by the deadline (nor was it particularly unfinished), but I didn’t have all the levels I want or any graphics whatsoever (well, black circles for ninjas, red squares for enemies, and black rectangles for floors and walls and stuff). If I hated my game, I’d probably have submitted it, but I think it’d be better to do some polishing, make some more interesting levels, etc.. – then I might have a good game.
Well, this feels a little late to be getting the back-end done, but hey, there’s still more time in the compo. At the moment, I have just finished adding the final touch to the engine, making there be enemies to kill – and of course, adding the means to kill them. The same system should work to create levers and such as well, which should make interesting gameplay. Maybe.
So, all I have left to do before I have a game is make the levels. (Of course, that’s not exactly “easy” given that my levels will probably involve a lot of motion) Of course, I’d like to have a pretty looking game, but… uh… ninjas don’t care about that sort of thing.
Well, my game still consists mostly of a blue screen – but now there are black objects on it! And it *should* have all the back end it needs except for adding some enemies to kill (which should be relatively easy).
Unfortunately, the ninjas are now visible and can’t walk. So they’re not so good at being ninjas. (Though they can, oddly, fly)
Well, my game consists mostly of a blue screen at the moment (to be sure, it is a blue screen with a useless back-end). I’m beginning to wonder if my goal of “make this game look better than the last game I made in only one of the days”.
But then again, my game is about ninjas. They want you to think the screen is empty. So, all in all, I’m gonna call this a great success.
An Informative Concept Drawing
My plan is to make a game where the player controls a flock* of ninjas with various abilities presented with the following task: Kill everything on screen and get off-screen within 10 seconds. The ninjas will be controlled via a timeline, so everything’s planned ahead of time and can be controlled very precisely (because these are ninjas – no mortal can hope to control a flock of them at the same time!). I’m hoping that this will lead to interesting (and difficult to program!) possibilities for level design (though I wish “level design” weren’t a thing I had to say) – like having two enemies be in planes and having a single rock thrown at them strike both if they’re in a line above the ninja, which they will be for only a brief instant (i.e. enough for a ninja).
Besides, I’ve already done the hardest part for this idea of a game: I’ve named it in a “clever” way!
*I believe this is the technical term
I seem to have a fairly nice concept. I’m worried that it’s not original (because there’s a whole lot of puzzle games out there, only a small proportion of which I have played), but basically, my game is a puzzle as follows:
The game is a grid with various cells. Each cell can either be empty, positive, or negative. A non-empty cell also has an orientation and various links to other cells. A cell may only travel in its orientation with all of the cells linked to it. Collisions between two like cells is illegal and collision between positive and negative yields an empty cell. The goal is to put all the cells into a rectangle from some starting position.
I have the engine done and the graphics (which are laughable – er, I mean minimal). I’ll probably add random level generation (which shouldn’t be too hard) and audio, but other than that, I think this will be a nice small, but tidy game.
It’s a good thing that the theme is “Minimalism” because I’ve never had this little time to work on my game (since I’ve already scheduled away tomorrow too).
Well, no, there’s no doubt in me being “in” – I’m going to try if nothing else. However, I seem to have accidentally scheduled most of my weekend away already (I blame my friends. They don’t program enough to consider this weekend sacred). So… I might have to rush this game – rush it more than I usually do. But that’s okay because there’s really no (reasonable) minimum amount of time in which one can make a game. I’ll probably go back to using Processing, because I haven’t quite gotten the hang of packaging things with SFML.
Apparently, it takes some effort to make a physics engine that mimics some of the nuances of the real world. Namely, the whole thing with making surfaces act like they’re slippery is somewhat challenging to do seamlessly. I think I’ve got the physics down now, but my game is basically a diagonal line (above which is the color #FFFFFF and below which is #00FFFF) which has very little friction and a little player (who I call “black box” on account of him being a black rectangle) who falls down it. My game, now, could be aptly titled “ULTIMATE SLIDING SIMULATOR”, but I think I’ll be a little more ambitious than that.
(I’ve also made a neat data structure so I can generate the world in whatever chunks I wanna and can make the world arbitrarily large. That’s not nearly as exciting though. It’s got a few bugs, but they’re of the nature “If the player attains a sufficiently high velocity, the world around them will generate 1 frame too late and they’ll either crash the game or pass through a solid surface”
Well, I forgot to actually do my homework before today (and still haven’t done it. Solution: I will stay up until I’m too tired to program, then I will do my other work!). So, from this, I have two sources of inspiration from the real world: Snow and homework. Now, one of those things is fun, so I’m going to make a game about it. I noticed yesterday when I was outside that snow is pretty interesting. Namely, if you’re trying to move from point A to point B, the fact that the snow I was on was icy and tended either not to support my weight (which made me slow and annoyed) or be slippery (which made me lose my balance). Yesterday, the snow was kind of annoying, but it’s not always that way – it’s fun to slide down slopes and to build stuff in the snow, so I’m going to make sure I get stuff like that in. I’m thinking that I should make a survival-ish game (except I want to encourage movement because that’s where snow becomes important).
(And if I’m really on top of things, I think it’d be awesome to make it so that if there’s a high ledge or chasm your want to reach, you could build a slide with a jump and get to the other side)
In this, my 6th Ludum Dare, I had yet another fairly unique experience, encountering both new and old challenges and successes:
(Repeatable) Stuff That Went Well
- My code was organized. In the past, I’ve written all the code for the game into the main function. This made it difficult to have more than one level and made it painful to add, for instance, a starting screen. In general, it let me make more content than usual.
- I got feedback from people (well, one person), then implemented it. I did this early, leaving me time to do a good job implementing it and still leaving me a whole day for assets. The comment really helped me though, giving me an idea of what would make my game fun.
- I left a lot of time to make assets after finishing the game. I spent the second day solely on assets.
- Based on my own playing of the game, I refined the balancing of the game to draw more attention to the special mechanic I’d added to the game.
- I chose an easily attainable goal and then built on it. I had somewhat of an engine done within the first hour or two. From there, I was able to add more stuff and polish.
- Certain bits of polish were really helpful to the game. For instance, the sword in my game was pretty sweet.
- I stayed motivated. In the middle of this competition, I kind of hated my game, or at least, I didn’t put much faith into it and didn’t really know what to do to fix it. However, I pushed on, doing what I did know how to do (assets) and then revisiting the gameplay later and finding that it was not really as bad as I’d thought and that I did have solutions for it.
(Avoidable) Stuff That Went Poorly
- My code was spread out. There was no single place I could do all the balancing from, so it was a huge pain to do so. Also, I made too many tabs on Processing, so I could only see the names of 3 or 4 at a time, which made it hard to find any specific class’ definition.
- I didn’t put much thought into what sort of mood I wanted. Resultantly, I didn’t exactly create any cohesive mood.
- My art still wasn’t terribly good. I think I could have used more animation to make the top-down thing more convincing, but I don’t know. I wish I were better with this sort of thing.
- The controls may not have been the best choice.
- I don’t often play games based on action or on being quick and not so much on decisions. I therefore found it difficult to capture that sort of gameplay well.
- The game concept isn’t wholly original. It feel more like a variation on some sort of shooter game – the majority of the game (the shooter part) has been done before. Only a small aspect (the part about summoning enemies by taking stuff) is really new. Then again, people keep saying they like the idea, so… maybe it’s a good concept.
- I did not proofread the title page. It has a lot of typos. Like the good player of a game that I am, I never read anything in my game and just clicked on stuff.
Also, if you are one of the >1000 people who haven’t tried my game, you can click here. (P.S. I love comments on my game – it’s one of the best parts of the dare for me)