After getting inspired by Marcus's TinyCham I started creating my own 40x30 pixel adventure. I didn't get particularly far because I got quite sidetracked on a separate project which I will go over below. Anyway here is what I have thus far:

I got sidetracked when I started looking at music for the project which I haven't yet added to a game but am convinced of it's importance. I have tried creating a software synthesizer/sequencer to replace the horrible java.midi api several times but never been particularly successful. This time for some reason the design just worked and I ended up with something I am very happy with. I created a demo applet which you can try out by clicking on the screenshot:I will release a library soon that should enable you to have full (albeit electronic sounding) music tracks in a game for less than 80k. I think I might chop down a version of it for this years 4k comp (always been meaning to enter it) and try making rhythm game (also something I have been wanting to have a go at).

That game is cool, and the music really gives it a spooky feel. You must be a musician because it's really quite awesome.

I liked the piano applet too. The random button is good. By the way, a good fellow named Bleb made a similarly cool program that did synthesised sound effects, I'll try and find a link... it's somewhere on JGO, in shared code.

The game needs more baddies though, I couldn't find anyone. Oh and the map should be a little bigger if possible, and what about scaling up the world so it's still got a pixelly-feel but it takes up more screen space... just an idea.

irrevessible_kev: You explored too much... Also the sound crackling is probably because the audio buffer size is really low (for low latency key response). The library version of this will have a customizable buffer size when you create the Synthesizer so you can tailor it toward real time (small buffer) vs background playback (large buffer).

CommanderKeith: As noted, there is a single enemy (that you can't kill and just walks around randomly) in the cave/castle. I would have created more but as mentioned, got sidetracked. The world is scaled at x4 at the moment but if I continue developing (frankly unlikely) I will add 1x - 8x zoom.

Very cool synth (can I request virtual-piano mapping from keyboard? ). I've always wondered why audio-processing in game seem to be living in the stone-age while 3d-graphics have moved beyond imagination.

I know you might not keep working on it, but for what it's worth, you cancel the players movement when I exit a house (making me click the down arrow twice). It's unneccessary.

Really cool stuff!

It just felt like a bit of a harsh/discontinuous jump if you just kept walking after you were teleported outside. I should probably have you keep walking but have a brief black screen or a pause so it's not quite so jarring.

Hey. I Tried the game. I really like this style. Your sword attacks are great, aswell as walk-animation. :-)

I gotta ask this though: What are the controls?Also i got the problems described below when i played the game:

****************** Spoiler alert!(Mark to read)******************

The spider in the cave tried to escape through the cave entrance. I tried to follow but got stuck in the cave entrance on top of the spider, which was also stuck. I rebooted again, got to the room that told me to stop exploring, went to the next room, and got stuck again! I think a spider was involved again... Also I'm starting to get arachnophobic...Third time i thought i had explored it all and quit. I really wanted to open the chests, but failed at finding a way... :-(

Hmm, yeah there is nothing stopping the spider from traveling through doors at the moment. And the second he gets far enough away from you he stops moving so you will teleport inside him and get stuck. I'll have to fix that one. As for chests, they are purely cosmetic at the moment. Can't be opened and don't contain anything. My original idea for this game was to see if I could have a compelling story and atmosphere in only 40x30 pixels. It is very hard to write any text for the game due to the size constraints but I hoped that when pared down it could still be an engaging experience that would take around 30 mins to complete. If it became popular I was thinking I could try doing an episodic format (always such grand plans when I start).I planned to have Episode 1 start with an earthquake that cause the rock-slide that is blocking the path out of the village. In the course of getting the rock-slide cleared you would discover it had a sinister origin and end up having to embark on a quest to save the world (or something along those lines). Episode 1 would finish when you left the village.

Cheers,Yeah will probably allow 8-dir movement (once again, inspiration permitting) in next release. Generally I at least GPL all my source code if anyone asks so I'll probably start a GoogleCode or SourceForge project for SimpleSynth when I get some free time.

Sorry to hijack my own thread but I was trying to implement a keyboard control for my synthesizer and ran into an interesting problem. Is there any way in Linux to reliably detect the state of any key without getting the Security Manager throwing a hissy fit? I really don't want to have to pop up a permissions dialog just so keyboard control works properly.

Peculiar dilemma. I'm pretty sure that would be impossible, or else you'd be able to monitor keystrokes outside the webpage. You'd could probably use threads to build up a buffer for choords, but it seems like much work for the request.

I don't need to keep keyboard focus, the problem I have is that on Linux key repeat works by sending multiple pressed/released events while a key is held. The only way I know around this is to take a look at the AWT event queue (needs security permission) and ignore any release events that have a subsequent press with the same timestamp.

One thing that could be improved in the movement of the player is that when you press two keys at once, the player should do what the last key pressed did, rather than continuing to honour the old key press.

Here's a class I used to take that into account, maybe it will be useful (This may help with your other problem too?):

import java.io.*;import java.util.*;import java.awt.event.*;

public class PlayersCurrentDirection{

// If empty, the player will not be trying to move // The last pressed keys are first. ArrayListSS<Integer> directionsPressed; int direction;

// this should really be called isTryingToMove, since it doesn't return whether or not the player is actually moving. public boolean isMoving(){ return (directionsPressed.size() > 0 ? true : false); } public int getDirection(){ return direction; }

Ok, got the key thing sorted, new version up. This is probably the ugliest hack I have ever done but basically after any keyPressed/keyReleased events I keep track of the key state according to AWT and start a Timer with a 5ms delay. The timer actionEvent then compares the AWT key states with it's own set of key states and issues it's own events based on the differences. This seams to fix the Linux press/release key repeat issue as the press/release events appear to go into the event queue in pairs and when the timer goes off I have never had a key that was held down in the up state. Oddly I tried an SwingUtilities.invokeLater() to do a similar thing but I was getting keys up occasionally so I am not sure what's up with that.

One thing that could be improved in the movement of the player is that when you press two keys at once, the player should do what the last key pressed did, rather than continuing to honour the old key press.

Here's a class I used to take that into account, maybe it will be useful (This may help with your other problem too?):

I don't think that class is quite necessary, all you need to do is set the direction to the most current key pressed and only stop if the released key matches the current player direction.

My little bro gave me the thumbs up when I implemented this method, since it meant that he could press down while pressing up, and the player would change direction by going down. Then when he released down, the player would head back up since he never released the up key.

It does feel nice when the game remembers what keys you've got down, but obviously the added complexity might not be worth it. each to his own

Also, often key presses are streamed continuously even when multiple keys are down, so doing whatever the latest key press was isn't necessarily the best option.