You know you all want pirates as the theme
Archive for the ‘MiniLD #48’ Category
You are stuck in a universe full of war, terror and hazard. You have been sent on a mission of Recon, to see if you can find any survivors. You jump into hyperspace but something goes wrong. The dials and buttons are flashing red…
Read more & play the game here.
EDIT 19-2: I made a pre-alpha version (with loads of bugs, placeholder music etc.) available online. You can view it with the Java applet or download the .prg to run with an Commodore 64 emulator.
A long time ago I made a commmodore 64 game for the Mini Ludum Dare 45.
I liked the result and thought it would be a nice idea to expand on the game and maybe release it commercially (yes for the C64!).
A sort of personal October challenge.
It will have to be sent by post, with a sturdy package containing a 5 1/4” disk, so to break even I will have to charge at least 7,50 euro.
Of course a C64 game would not be able to compete for other games with the same price, so I think I’ll try to make it a nice package with some cartoons. A sort of collectors edition.
I did some work on it the past few months, but there was not much progress. This week and the coming week I’m trying to make some progress by working in an Agile kind of way.
I think I’m making progress but sometimes it’s hard to tell. The sticky notes with ‘user stories’(just small units of work really) are not moving as fast as I hoped (and sometimes they get pulled down by my cat, I think he’s an Agile perfectionist: ‘that’s not a user story!’). There also new notes appearing, but that’s to be expected.
There are other reasons for the lack of obvious progress. Before this week my game was still largely based on what I made for the Ludum Dare. It had a pretty good structure if you only have one level. If you want more levels and texts between levels you need something that is more flexible, some sort of game states. I think I have a much better structure now to accommodate an easy flow of the program. I have lots more constants, variables and there are now also more macro’s so the code becomes more readable.
For instance: the transition from the Help-screen to an introscreen that will exit to level 1 is now two lines:
1. “showscreen LVL1IntroScreen,continueWithLevel1″
2. “SetState StateInfo”
I hope to see this progress reflected in a higher speed with the realisation of other stories.
Another way to measure progress is how big the program is:
It’s now about 80 blocks on loading (approx. 20k). It’s uncompressed but after loading all kinds of stuff is moved around, so after playing a game the program will have left its impression on about half of all the 64k of memory. This can be optimised a lot, so no need to worry yet.
I think I have done an overhaul of between 30 and 50% of the code (not including data). So there’s a lot of progress.
And lastly progress can be measured best in a more enjoyable game experience.
Sadly that is not the case. I break the game several times a day. It can sometimes take several hours to get it working again (and I use the word ‘working’ in a very broad sense).
I think my main goal for this and coming week will be to have a game with three levels that can be played till their (happy or tragic) conclusion. Polishing of text and graphics and creation of music will have to come after that. But it means that hopefully within two weeks playtesting can begin.
I know it’s not best practice to have something playable so late in the process, but I think I had to do the refactoring to be able to make changes without drowning in bugs.
I’ll end this lengthy post (TL;DNR) with a screenshot of the second level I’m working on. The end product will have 3 or 4 levels.
Oh: the bar you see on the side is an indication of how much screentime my program uses: it changes to grey, when my interrupt starts (where now everything happens) and changes back to red after that. The maximum now lies at 20-25%. That sounds like a lot but there are not many forseeable processor-intensive tasks to add.
If I have to, I can probably get it down to 15% by using double buffering for the scroll.
Today, lonebot.net is officially turning one year old!
I wanted to post this here because without Ludum Dare, there wouldn’t be Lonebot. So thanks a lot everybody! I think we’ve come a very long way since we launched our website
Here’s a cool video Mati made about our games:
So what does the future hold? Hopefully, not potatoes.
Thanks so much for everything, Ludum Dare!
So myself I don’t really make 8-bit games, but I know a lot of you guys do. There’s one thing I would love to see more in your 8-bit retro games: CUTSCENES!
And I found the perfect tool to help you achieve that ;-). It’s an online tool (no download) found here: http://c64.superdefault.com/
I encountered this site when I was looking for a PNG to 8-bit retro converter. The naive approach was to scale a picture down, save it, then scale it up to make it look pixelated. That actually failed big time, simply because the result was too rich in color. It clearly looked like a scaled up photo rather than a retro graphic. There are a few tutorials that showed how to do it right using photoshop, but for the lazy type like me, I found that the online tool works best! Just look at this awesome 8-bit photo of Nicolas Cage below!
I just released my very first game The LootCastle, which is based on my LD25 entry from a year ago (Path to Death). The game is about creating your own skill trees with randomized skills. So if you like strategy games where you experiment a lot with finding synergies of skills, you are happily invited. And there is a ton of (epic) loot to discover. I also write this to encourage you: polish your LD game and put it on itch.io – feels so good!
If you are interested, just have a look at my website.
I’m in the process of slowly moving out of my comfort zone, and try to learn to make games without Flash. Flash has had its moments, but the port to mobile is getting really clunky and impractical.
So, the obvious choice would be Unity, as it seems to grow in popularity and has the advantage of being cross platform. But I was also considering another option: Cocos2D JS
#1. Well… it’s not clear but… is this developed by Zynga? ;-P
#2. The IDE of choice seems to be cocosbuilder.com, and at the top of the page it says Cocos Builder is no longer maintained. (then it redirects me to SpriteBuider.com). Does it look like a red flag?
The reason I’m not completely sold on Unity, is because I’m mostly a 2D game developer, and I would prefer something a little more lightweight. Unity seems to be for the kind of devs who like to incorporate APIs, engines. I’m the kind of dev who’d rather implement basic collision detection than use a physics engine in my game.
Anyway, just looking for other dev’s thoughts about it. Thanks
Hey People , Two Player Chess is a two player chess game made over last weekend, check it out!!
Gyro Clone , This is the clone of the android game Gyro that am working on.Check it out.
Same as above