I'm perfectly happy for you to use this/my work however. Technically it'd be a "Attribution CC BY" - Copying, changing, distributing are all freely allowed as long I'm credited somewhere. (Andy Jenkinson/Uglifruit).
Looking at the CC website - their wording is "This license lets others distribute, remix, adapt, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered. Recommended for maximum dissemination and use of licensed materials."
Hope that helps, and if you need anything else / source code / notes then please let me know.
Thanks for comments. This definitely still has a bug that can occasionally print a (magenta food) that doesn't count, and you can't progress. And it IS too hard - I've been playing it again today (on 200% speed on emulator it feels quite responsive), but I can't get close to my personal best. I think when making it I tweaked it to be as challenging as I could just-about not cope with, which is where I think arcade games should be. But at that point I'd been practicing, now - after not playing for a few days with dulled reflexes it's frustratingly difficult.
And thank you - the 'hunger' (and graphical representation of it) was the thing I was most proud of here. I don't *think* I've seen that in a snake game before.
A couple of things - yes, the map generation is painful (ears and mental state). I think a pre-gen .z80 snapshot might at least get people playing.
The key choices seem odd: [qaop] to move the cursor says the screen ... okay(!)... but it appears to be QAOP that is moving cursor, leading to ever downward movement when the Swordsman is selected being interpreted as 'A' (attack) and then down.
Then there's the mildly annoying d (from 'end' in the UI) that doesn't get deleted when you select a character.
I really wanted to love this, as I think it's a super brave attempt (you've got unit A.I. and a nice map in place), but the player is left a bit in the dark, thanks to it lacking the 'gloss' (or just comprehensive instructions) that'd make it a gem.
This is good (insofar as the number of items moving, and the rather colouful presentation). The sixth level exit bug does seems repeatable, which is a pity. Good work I though, over all.
A masterpiece of efficient coding. Elegant, and clear (the notes on the game page about what each line does are nice too). The game is relatively pacy and fair. Very well done indeed.
A weirdly compelling piece. It's repetitive to the point of being like a poem, with tiny changes after huge periods of playing. It's an adventure from the Minimalist school of game making.
I liked this one. The timer only descending when you are not popping pills means the game becomes about path planning to avoid doubling back. Good work, and quite 'just one more go' y. Good work.
I'll second the people who noted odd key choice (it's hardly a FPS, so WASD seems odd... as a right hander that's a quite strange choice to make - play with left hand, or play with Right Hand over on the left of keyboard.
This is hard, and it does as one would expect. I like the titling "Flickering Lunar Lander" addressing the elephant in the room - the lander IS flickery. Despite it's simplicity this game has a charm that is very likable, and does make you want to try/crash again.
The screen draw time is the only major down-side to this very nice looking version of the classic puzzler. Good UDGs and colour use, I thought. I don't really feel the need to play through the Sokoban levels again - but this is a nice version - well done. Good effort on having a Loading Screen$ too!
This is excellent. Given the number of moving parts this is very very playable, and the use of IN ports to read the keys (enabling the reading of more than one key press at once) is a nice treat. Good attention to detail in (such as the 'scrolling' Game Over) adds to the overall gloss. Really well done.
The 'after jam' version of this is much nicer. There's something quite hypnotic about playing (and it's not difficult to complete, so it does become about getting a 'lo score'). The previous version was painfully slow - but in it's new incarnation it's very playable. Well done.
An interesting/clever take on the maze game. It's hard to comprehend, and probably benefits from a pen and pencil to map what's going on. I'll be honest and admit I was crap at this, and had to check the listing to see I wasn't just seeing random room descriptions!
It really is quite difficult to see the effects that actions take, and the input questions running over lines it a shade annoying. Instructions (just things like whether answering "Y" or "YES" is correct, and some notion of how the decisions affect things) would be helpful.
This has a nice degree of polish, although the limitation of BASIC's speed do hamper it. The random placement of the apples can feel quite brutal when there are mazes in the way - sometimes it's just not possible to get to it before it decays away.
There is a lot of greatness about this - presentation is excellent, and obviously recalls Elite excellently. The lack of responsiveness of keys is workable (the beep works), and it's great to visit those planets again (it's been a long time since I've flown from Lave to Diso in search of a cheap profit). Some planets do seem to *really* want to off-load slaves, and will pay you for taking them. This is either a thematic suggestion of progressive thinking, or a bug. With the suggestion of Fuel usage (the omission of which somewhat makes travel rather easy), and the suggested 'economy type' of neighbouring systems, this would be an *amazing* feat in basic. As is, it is just incredibly impressive. Well done.
There seems some inconsistencies in collision detection, (and which colours do what). And the fact it doesn't loop back when you die is a bit irritating. The lack of responsiveness does suggest underwater though, so that works! The amount of baddies, bullets and size of player sprite is an impressively brave amount to handle in a real time BASIC game though.
Thank you. Without wanting to blow my own trumpet, I'm really enjoying playing it too.
I've actually been thinking how I might make the game work if I re-made it in assembly. I *think* I could - my z80 skills are okay (though the maths might prove challenging in such a low level environment).
Thanks. I've actually spend some time on presentation, and the like. I actually think the game is very hard (hence the not-at-all-hidden cheat mode to start on any level). The later levels are - in my opinion - the more entertaining ones, the first half a dozen are about teaching concepts, which is a bit of a chore, if starting afresh.
Last minute update to this - bugfixed a scenario where the random placement of food meant that if it landed on the 'head' of the snake, it'd be not eaten. I think I've bugfixed it anyway!
I raced off another entry, having been inspired by all the 'Snake' games on there - I wanted to have a go at a minimal snake - and see how fast I could get it going. (not super fast, is the answer). Thought I'd try an against the clock type thing to make you snake about less efficiently.
Drawn a line under it, and submitted. Decided that I'd designed enough levels - 20 was good enough for Miner Willy, 20 is enough for me! (Some of them are HAAARRRDD to beat).
I've added a crude level designer to my effort, which allows me to place elements on the screen then gives me the figures I need to pop into my DATA statements. I wish I'd done this earlier - so much easier than trying to just write the DATA statements 'by hand'.
Using the designer means I'm having to copy out meaningless strings of numbers into my program - it's like the olden days of copying pages of them out of Sinclair Programs Magazine.
It's my PLOT eo,fo in line 68 which is at the same co-ordinates as the PLOT e,f was a couple of lines earlier. Because of OVER 1 it's removing that pixel (OVER 1 meaning plotting is toggling the state of the pixel when it PLOTs).
Thank you. It's an OVER 1, PLOT statement to draw and erase it.
The (horrible, uncommented) code that is doing that bit is -
66 OVER 1:LET e=48: LET f=138:LET ea=1:LET fa=2:FOR x=1 to 156:PLOT e,f:LET eo=e:LET fo=f:LET e=e+ea:LET f=f+fa:LET fa=fa-0.1 67 IF f<16 THEN LET fa=-fa*0.8:LET f=16 68 LET i$=INKEY$: if i$="" THEN PLOT eo,fo: NEXT x:GOTO 66
e,f are the co-ordinates it's PLOTted at, and in each step of the loop ea and fa are the acceleration added to e and f respectively. Each step fa is reduced (due to 'gravity).
if the height is less than 16, fa (vertical acceleration) is reversed, and reduced to 80% of it's previous value.
if nothing is pressed then the the old position of ball is erased (eo, fa) and the we loop around.
This is (essentially) the same 'physics' done in game, but with some fixed parameters.
I *think* mine is going pretty good actually. I've even been working on some 'bells and whistles' (front end, and the like). It's now a case of level designing I think. It doesn't help than I am massively enjoying playing through it - which is slowing me down. Having had a few people play test - I've added instructions (as it's not self evident how to play). The level designing (which is me fiddling with Data statements) is now taking the time (and nothing like as good fun).
Happy to take feedback if anyone cares to have a go: (dropbox) Physiced
RUN (obviously) and on the menu press '1' to cheat and start at a different level. (1-11; though 11 is far too hard).
Andy here. Had an '81, then a Speccy. Did a lot of recreational programming back then, dabbled with assembly. Done a lot of hobby programming since (currently enjoying Arduino things), but I still return to the Spectrum. It's so comfortable!
Today I've messed around and decided on what I'm trying to do - faffing and seeing how fast I can make things move as I'm trying
for something arcade-game-y. I'm using the attributes to check for
collision, and having a lot of fun. I might even be up to the stage where I am 'designing levels' - ooh ya. I'm going to knock together something crude to do that on the speccy too - if I have time maybe it'll be a level editor too!
It's not all that sophisticated, but I'm using a text editor to write my BASIC program (TextWrangler on a Mac but could use anything really), then using the very handy "zmakebas" by Russell Marks which creates a .tap file containing a BASIC file, which I can then test into my emulator. I find it a lot quicker than using the in built editor on the speccy (although you obviously miss out on the syntax checking as you go along, which is probably helpful if you're less fluent in Sinclair Basic).
