You are currently browsing the category archive for the ‘Our Games’ category.
Hi. Got a little bit sidetracked, back now, how are you how are you, nice to see you again. Oh, that view counter looks pretty much how it did back in September, so no harm done?
Right, that’s that sorted, so now to business. Haven’t played much, haven’t made much, so didn’t see any point in posting for all those months.
Oh, actually. Made one thing, for a new game called Akmerika (We wanted a stupid name, I think I delivered. Apologies if it means something somewhere). It’s music, and talking (mostly talking) recorded while we began to make the game, which involves rotating bouncing rabbits and lasers. Here it is. Sorry about the levels, I realise it’s a bit quiet. But it’s ambient, innit?
So yeah, Akmerika. Look out for it, I’m sure it won’t at all get lost in a sea of studying and apathy, no sir.
What do you know this blog actually has two authors? I did actually post a few times on the old blog, but I have yet to find anything much to talk about here. At least while also feeling virtuous enough to write a whole blog post. Drivas’s lengthy pretensions and reviews have clearly set the bar quite high on such things, which didn’t help. Nevertheless, as a developer in colour game (most boring codename ever) I do actually have some things to talk about here.
We were intending to work in C#, as Drivas had already started piecing some stuff together, however we eventually decided to go back to my better known Python. Ultimately when it came down to it, the focus was actually getting a game made, and learning a new language didn’t seem the best way to do that. I know Python/pygame quite well, so it meant we could focus on all the parts of the actual game, the design, the structure, the content, instead of getting bogged down in learning new constructs and libraries.
In terms of progress, as you’ve seen we had all the core mechanics down a while ago, and currently I’m working on the level editor. In theory this shouldn’t have been too difficult, but the rather intertwined structure of the original code meant a lot of reorganising and modularising of the code was needed. The code at the moment still feels like it could be more modular, but it is sufficient for now. I have in fact, made a functional level editor, of sorts. There are many many features that need adding, but as it stands it does allow us to make levels. However the massive code restructuring means the mechanics coded for v0.1 are now useless, or at least need so much work that I might as well write them from scratch, and hopefully avoid any structural mistakes this time.
These kinds of problems are precisely the reason we want to make a simple puzzle game like this before we move into anything we really want to make. That way hopefully we won’t get distracted by lame basic things, and focus on the problems of actually designing the game we want. I’m also trying to make the engine modular enough that we can extend it quickly to other game types. pygame helps a lot here of course, handling a lot of basics like sprites and collision detection, but it is by no means a complete game engine. Having a structure already in place, even if we have to further modularise it, or even specialise it, to make a new game, saves a lot of time.
Anyway, once the mechanics are back in we’ve hit our milestone and can release v0.2. After that we’re going to start actually making it into a game. This will be much more about content than code. This means levels, sprites and a menu. Depending on how quickly we work, we might even decide to add stuff like sound and animation before we release v0.3.
Beyond this I’m not really sure yet. The goal for v1.0 is a completely polished, substantially lengthy puzzle game. No doubt there will be lots of stuff we haven’t thought about cropping up yet, but I don’t think we’ll get through 6 version numbers before we get there. Thinking even further ahead (to a dangerously optimistic potential future) we should be able to stop working on it at that point, at least if we did it properly, and decide which of our crazy ideas we want to try next. Although it’s entirely likely we’ll come back to improve it later.
You can follow the issue tracker on google code if you want. Hell you can even checkout the svn if you’re feeling creepily enthusiastic about our game. You’ll notice if you do, that I haven’t been updating very much recently. This is partially due to the AS exams, but as they’re (nearly) over now, the only excuse for the past few days is laziness. There is a certain inertia here, and hopefully I’ll overcome that and get back in the coding groove soon.
Goodness I thought I’d be done quickly and go to bed, and now it is half past midnight, I can see how Drivas ends up with such long posts now.
Oh well, bedtime for me.
I took a break from blowing my own horn and revision, and did some coding. After being thoroughly sick of python, I limped back to good old XNA, and made a fairly neat particle system, with a little help from the webernets. The results were surprisingly good, so I coded up some effects and threw ’em in a zip file for your enjoyment. Thoughts?
Back to game design for a moment: All games should have cheesy digitised explosions. Who doesn’t love a cheesy digitised explosion in their face?
Anyway, get it here.
I should preface this by saying that these posts on game design are really just my thoughts on the matter. Colour Game is the first game I’ve worked on, so I don’t pretend to be any great authority on the matter. They do, however, help me sort my ideas properly, and hopefully gives whoever is interested a sort of insight as to how I think.
Anyways, to the matter at hand. The Infinite Loop should be a concept familiar to anyone who has played a Japanese RPG before. Generally, before starting a grand heroic quest, the player is presented with a conversation that goes something like this:
Do you want to go on a grand heroic quest? YES / NO
Do you want to go on a grand heroic quest? YES/NO
Do you want to go on a grand heroic quest? YES/NO
Good! Let’s go!
This is pretty much infuriating, and to me, a little baffling. Your game is extremely linear. Generally, as a player, I’m okay with this, seeing as I bought your game in the first place. The on-rails nature of the grand heroic quest is something I’m willing to ignore. So, it’s probably not a good idea that you remind me of the limitations of your world, with a conversation that can only go one way.
On the other hand, if you’re intending to instil a definite feeling of lack of choice, an infinite speech loop with only one way to exit is pretty much the best way I can think of to do this, if only because of the familiarity to the player it has. For example, in the JRPG Mother 3, you play for a brief period as a monkey, captured by one of the main antagonists and wearing a shock-collar. Your job is to dance for the residents of the village, in order to trick them into thinking your master is an okay sort of guy. Mr Baddy (I do not recall his name) points in a direction, you press the appropriate direction on the d-pad, do the dance, trick the villagers. However, the game does such a good job of explaining just how much of a baddy Evilhead is that generally the player will not feel like following his orders. No, instead it is pretty much guaranteed that the player will try something subversive, like pressing a different direction. Baddy presses a button, you get shocked, points again. Sound familiar? Right. For the story to progress, monkey needs to give in, do the right dance, and he needs to feel pretty sore about that. So, a loop is perfect. It’s a great way of forcing direct authorial control when it is needed, without resorting to a cutscene.
I was going to say here that Colour Game won’t be featuring any such loops, well done or otherwise, but I realise now that isn’t true. It revolves around one, as do all linear games. There is only one way to exit a level within the bounds of the game, which is to win. You can also quit out of course, but that doesn’t progress or regress the game, so can ultimately be discounted. So, it’s pretty much the same deal as before:
Hi there! Go to that exit looking door to progress!
No, I’ll think I’ll just mess about with colours. Okay, I’m bored now! I’d like another neat-o puzzle.
Hi there! Go to that exit looking door to progress!
Oh, okay then!
I’d like to think players of *my* game are happier than when they play others. But you get the idea, it’s pretty much the same thing. I don’t think it’s too big of a problem, though. As I said before, linearity isn’t evil. I just feel you need a little subtelty. It’s a little obvious, but if you don’t want the player to feel constrained by the limitations set, don’t go around yelling at the top of your voice how constrained they are. That, or make a big deal about how constrained you are, and tie it into the story. That, of course, was Bioshock’s big trick. But, the bizarre situation of authorial semi-control that videogames put us into is full of metaphorical potential.
The excellent Mother 3 english fan translation can be found here. Also! Please, tell me what you think of these pieces! Too pretentious? Not pretentious enough?
I had an interesting conversation (which you can read here) with Michael Charge of hntdaab.co.uk over IM, in which we discussed his upcoming XNA game, and I said “yeah” a lot. It’s a multiplayer game of tig, set in a primary school, so I look forward to that. One of things we talked about was his idea of allowing the players to scrawl on the screen while a game loads. This doesn’t really have much purpose, it’s just a quick diversion. This, I think, is also a really clever piece of game design. Games are about interaction, so any period in which you are forced to sit and wait without being able to anything is pretty much inherently boring to the player. That probably isn’t what you as a game designer is going for, so allow the player to do something while they wait. Drawing with friends is fun, not for very long, but long enough to load a level.
Now, colour-game is an extremely lightweight 2D game, so hopefully we can get away without having loadtimes at all. But I feel “useless” interaction has a place in actual play as well. If your super serious game with rigid goals and mechanics can also function as a mildly diverting toy, well, you’ve effectively doubled the scope of it, and probably made it much more engaging with a very minimal time investment. If you play the little demo of colour-game’s main mechanics we posted (Please do! Please!), I feel pretty confident in saying it’s got a certain charm. It’s fun. Not very, but enjoyable and interesting for a couple of minutes at least. It’s satisfying, just to affect the world around you and see how the rules change. This surprised me, but looking back it really shouldn’t have.
A game I feel does this much better than ours is Tag: The Power Of Paint, the IGF 2009 winning student project out of DigiPen. The basic premise is that the three colours in the world, Red, Green and Blue, affect the player in different ways. Red makes you run fast, Green makes you jump, and you stick to Blue, allowing you to run up walls and the like. These colours appear in the greyscale world occasionally, but for the most part you lay them down with your paintgun. The useful purpose of this mechanic is to get you to the end door, but it also enables you to do silly things like this:
Which is really half the fun. It would have been easy for the developers to streamline this right out of the game, because it doesn’t aid you in the basic “get to the end” aim. And it would have been a poorer game for it. I think that’s important to note.
EDIT: You can get Tag here.
We haven’t started the first one. Not really. We’ve got a lot of periphery stuff done, but we can’t do the real meat of it, the levels, until we build a level editor. Well, we can, but I for one do not want to build that stuff by hand. Typing out filenames of block images over and over to build walls gets a bit tedious. Before we’ve even started, then, we’re thinking about the next thing. Here’s a proposal I put on our google code wiki of an idea I had for a companion to colour-game, which I’m tentatively calling You Shine On Us:
So, ehm, I had an idea for a game that I thought I’d put up here. It’d use pretty similar concepts to colour-game (we really need to come up with a better name for that thing), although the gameplay mechanics would be considerably different, as would the tone. So I guess a companion piece? I don’t know, you guys see what you think.
I came up with the central idea pretty late last night, while listening to Vaka, by Sigur Rós. It’s a pretty bleak and morose song, and I recommend it. Anyway, it was dark, so I got to thinking, what about a game in which you eat shadows? A bit of a leap, but whatever. So you eat shadows. What does that do? Well, I suppose it would make the world around you lighter, which is a good thing. But it also makes you darker. So if you do it too much, clearly you turn you and the background into this grey, neither-here-nor-there shade, and disappear into obscurity (similar to the disappearing blocks of colour-game, but playing with dark and lightness of colours, rather than individual shades.).
So, I think that’s kind of interesting. Doing too much of this ostensibly good thing will eventually kill you. You can’t help everybody. In gameplay terms, it means you are effectively balancing two meters, your “health” and the state of the world around you. You can increase either one (what would a game about eating be if you couldn’t also vomit that stuff back up?), and that will make for some decent puzzles I hope. It also provides you with choice and balance to strike. Do you save your “health” that will make this puzzle really easy, or do you use it to lighten the home of this NPC that will presumably reward you?If you chose the latter, you’ll have to find a cleverer way to solve the puzzle with less health, or spewing the shadow you just picked up to show a completely different way.
In terms of basic gameplay, I was thinking a metroidvania, something along the lines of a gloomier Cave Story in terms of tone. That 2D openworld style, with little towns and settlements that you pass through seems to me the best way to get across the idea of a world, that isn’t in a good way, and is something that you affect, rather than a world that revolves around you. It’s a good way of showing off the progression from a black and white world to different colours, and seeing as each area is monotone, it would be very difficult not to know where you are. It’s also one of the best 2D playstyles I can think of for including an involved narrative, which this game would fit far more than colour-game. That mechanic, and the idea that you cannot save everyone, and trying will only hurt you is pretty chock full of metaphors fer exploitin’. And is what you are doing even right? Who says shadows are all that bad? You are pre-disposed to thinking that, because that’s what the game tells you at the start, but there can be characters who don’t like the light. So that’s another balance to strike. Once again, you can’t help everyone. Someone has to lose out. Perhaps you start the game thinking that only removing shadows is good, but soon find that that is a completely bigoted view of the world (Again, hella metaphors).
Aside from giving you folks considerable insight into how I think (hint: lots of brackets! I am the king of digression. Also exclamation marks.), hopefully this is a pretty cool idea! WHAT DO YOU THINK, LOYAL READERS?
Well, more like revised Colour Game Music. I changed up the timing and melody slightly, and also recorded the midi to an mp3 for for your enjoyment. Get it here
I’ve been working on this theme for a couple of days now. It’s not perfect, but I have it mostly worked out. It’s either my pretty lacking notation skills, or the quality of the notation to midi program I’m using, but the midi sounds a bit off. It doesn’t really matter, as I’ll record it from my piano for the final version. Anyway, download it here
Colour Theme is licensed under a cc-by-sharealike license.
Release time, woo! Seeing as in this build we have pretty much all the main gameplay mechanics implemented, I’d better splurge on the details regarding what the hell this thing is actually about. First of all, it looks like this:
So, the game is centered around colours, and the mixing thereof. Using the three different colour “seeds”, the player is able to change his/her own colour, and also that of the background. For example, touching a red seed will change the player’s state to red (I haven’t actually made different sprites for this yet, so you’ll have to imagine it). This allows you to move straight over red blocks. While red, the player can touch another seed, let us say blue. This will mix the two colours, and change the background to this rather lovely shade of purple, and return you to your neutral state. Now, there is also a purple block in the debug level in this build. However, when the background is also purple, you can’t see it, and if you can’t see it, as far as I’m concerned (and the game, of course), it no longer exists. You can pass right over it! This allows for all kind of tricky puzzles that I personally can’t be bothered building until we make a level editor, but if crazy people want to build one straight into the .py file, they’re welcome to. By the way, that little door in the bottom right is the exit/goal. At the moment it quits the game when you touch it. Don’t worry, it isn’t broken.
A note: These art assets are absolutely not final. Everything’s a little plain at the moment, but I will work hard to make it look better, and failing that, get someone else to make it look better.
Anyway, play around with it, you can download it here.
EDIT: Except you can’t at the moment because filefront failed, so get it from our google code host here.
I would say I had no issues with Daniel’s original decision to work in C# other than my own unfamiliarity with the language, but of course that would be a lie. Obviously, deep down, I secretly feel the unexplainable disgust of syntax prejudice, these strange curly brackets and unrestrained indentation caused various bodily fluids to simmer gently in their appropriate organs. However, being aware of this prejudice, I pushed it aside in my decision of what language to use… or so I believed. [END MELODRAMATIC MONOLOGUE] Instead, the decision was based on the inevitable slowdown that working in an unfamiliar language would have caused. While learning C# is probably a worthwhile objective, it seemed premature to do so when our practical knowledge of python never extended beyond the bare outline of a space shooter. The prospect of actually making a game seemed more important than learning a new language. Furthermore the code relied on Microsoft’s .NET XNA libraries, and while a mono port of these exists, we remain uncertain of its quality or completeness. It’s entirely possible it would have worked fine, but this uncertainty was important to considered.
Edit: This wasn’t actually finished when Rivas posted it! I was still drafting it. You can instead consider it a snapshot of my working psyche.
Further Edit: I’ll post whatever I want, whenever I want, and there’s nothing you can do about it. Know this. –D