Better late than never. Here goes:
Graphics – This always seems to be hit or miss for me but I managed to find something simple and cute early on and mostly stuck with it. The style did evolve a bit over time so it’s not perfectly consistent but close enough to not be glaring.
Character – Somehow the combination of cute spherical animals, chaos and tiny planets came together well. I can’t say this was planned but I’m happy with the outcome.
Delayed decision making – I decided on the controls and genre for the game early on but didn’t really come to a decision about gameplay or goals until later. This meant I spent most of the available time on Saturday building the basic physics and movement of the game. This was a bit of a risk but it meant that the eventual goals and gameplay were tailored to what was achievable. I’m quite glad I didn’t commit to some of the earlier ideas I had that would have taken the underlying systems in a different direction as I don’t think they’d have turned out as well.
Using an existing engine – Choosing FlashPunk early on turned out well for me despite it being my first time using it (I’m generally a C++ developer, I’ve worked in as3 before but using my own entity system and supporting code). It was good not to have to maintain and fix things as I went and FlashPunk was kind enough to step out of the way when I needed to which made implementing the physics efficiently possible.
Ogmo Editor – Ogmo is great, very simple but a huge time saver when it came to building my levels and the XML output was dead easy to parse. The only downside (and this was not the fault of Ogmo itself) was FlashDevelop’s code completion feature throwing an exception and popping up a dialog every character I typed while editing the XML parsing code. For all I know this is fixed in a later build of Flash Develop.
Physics – By far the biggest problem pointed out in the feedback on my game was the glitches in the physics. I think it’s something I could have fixed easily but I weighed it up against the risk of destroying the chaotic nature of the game which added a lot of character. Maybe it was the wrong decision but it’s the one I went with. Unfortunately right after LD I didn’t have a lot of time to play with tweaking it for a post jam version and now it seems a little late. If I find the motivation I’ll have a shot at tweaking this but it will be a fine balance. When it comes to people I’ve physically witnessed playing the game it mostly caused laughter rather than outright frustration but this doesn’t mean there’s nothing to fix.
Time – I decided to join in late so I ended up doing LD on a weekend where I had existing plans. This probably chewed up about half of Saturday and 4 hours of Sunday.
Sound – This was a casualty of time, as mentioned above. I think it would have added a lot so it’s a shame.
In game control tutorials – In my first LD (#18) a common criticism was that the controls were given pre game and there was no way to return to them after the fact. I took this onboard and added the controls to an overlay that pops up around the player’s ship if they are idle for a while. Unfortunately as I found out watching people play the game post submission the common reaction to confusion over the controls is random button pressing so the overlay often won’t pop up. Regardless there was a lot less confusion over the controls this time so it’s definitely an improvement but can be refined further for next time.
In game signposting – I took this quite literally and added big billboards to the backdrops of the tutorial level to explain the goals. Unfortunately some inconsistency here lead to more confusion. As some parts of the early billboards looked like in game items but were non-interactive people thought that later billboards must also be non-interactive. This lead to people thinking that a merchant who creatures should’ve been delivered to that had a billboard pointed at it was for illustration only, and went off to find the ‘real one’. This was definitely a step in the right direction however and with some improvements to its consistency should work well.
Overall I’m much happier with this entry than any of my previous entries. It got more positive comments than I expected and I’m more pleased with it than I expected to be at the start of the weekend. I really enjoyed working on it and had fun playing with it myself. Hopefully I’ll be able to take on board the lessons learned from this to make a better game next time.
The game’s entry is here: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=2573
Hurrah, Creature Collect is submitted!
I’ve had to cut it down from what I originally intended but on reflection the original plan would have made it even more difficult. The people I’ve shown it to have had fun so I’m happy. \o/
The main disappointment is the lack of sound and troubles people have had with the tutorial, which seems to be easy to miss.
Most important thing first, my game has a name: Creature Collect
I had a nagging feeling I’ve stolen it from somewhere but some Googling for the name came up dry so hopefully I’m good.
As for the rest of it, it’s getting there. I have the code and art in a complete state. Unfortunately I’ve had to make some comprimises to avoid completely rewriting the physics, which I don’t have time for tonight. The game is rather difficult at the moment but definitely playable.
Gameplay wise the goal is to collect creatures and deliver them to merchants (who are they? who knows? they could be zoos, could be conservationists, could be evil poachers). The space flight, gravity and tractor beam mechanics makes this difficult, as does the occasional flying creature.
- Spinning creatures
- Tractor beam
- Merchants to deliver creatures to
- Level progression
- A tutorial level
- More creatures
- More levels
- As much tweaking as I can manage
- Better physics
As usual the in progress build is here: http://moop.org.uk/~moop/tinyworld/bin/
I’ve made a bit of progress, despite getting up late today:
- Drawn some creatures and other items
- Implemented (simple) collision
- Turned gravity back on
- Tractor beams
- Poachers, maybe
- Scoring system
- Front end and polis
The game is currently a chaos of creatures whizzing around in space, it’s time to settle on some gameplay. Right now I’m torn between rounding up creatures, defending them from poachers, defending them from asteroids, or some combination of the above.
Current playable version is here: http://moop.org.uk/~moop/tinyworld/bin/
I’ve been sitting on the fence about whether to join in since I have a semi-busy weekend already, it’s a bit late but I’m definitely in.
Progress so far:
- Drawn some small planets and a rotund spaceship
- Pondered gameplay, remained indecisive
- Learnt Flashpunk
- Implemented player movement using Verlet integration (will come in handy later)
- Implemented gravity on the planets, disabled it until collision is in
- Decided to give Ogmo a try and switched to it from hardcoded levels
- Got tired
Work for tomorrow:
- Implement collision on the planets
- Make some decisions about gameplay and goals, commit to something
- Implement the aforementioned something
- Make some sounds if there is time
I’ve setup a script to push my latest commit to a webserver at any given point, so current playable version of the game can be found here: http://moop.org/~moop/tinyworld/bin/
Controls are W to thrust, A and D to rotate.
- IDE: FlashDevelop
- Engine: FlashPunk
- Graphics: Photoshop
- Editor: Ogmo
- Sound: Undecided but most likely SFXR
- Distractions: Many
After giving up on the 2 colour limitation and the 3 hour coding rule I’ve managed to make Bunny, Chicken, Dinosaur into something playable and upload it. Unfortunately it’s Intel Mac only for now but I will get a Windows version up as soon as I can wrestle it into submission and make it compile.
It could do with a lot more tweaking and polishing but for now I’m fairly happy with it given the amount of time spent on it. There are plenty of glitches I could iron out but I’m running out of energy for today.
Edit: Windows version is up now.
It’s almost time to start coding. I’ve got a few pages of notes which hopefully will help things go smoothly during the 3 hour coding spree.
Bunny, Chicken, Dinosaur! stars a bunny, a chicken and a dinosaur escaping to a place where their unorthodox love will be accepted.
So far I’ve gotten around to drawing sprites for the main characters. I’m thinking of relaxing the two colour restriction a little to allow two colours per layer, depending on how things look.
The next step is to get some backgrounds drawn and plan how they will be represented in game. I’m hoping to get as much planning as possible done before I start coding, due to the 3 hour rule. The code will pick up various settings from external data to allow tweaking of visuals and gameplay after the the 3 hours for coding is up. I will post some notes from the planning stage once I’m ready to start coding.
Hey, I’m back for more after vanishing for a while due to crunch time at my day job.
My current plan for MiniLD #24 is a jump ‘em up similar to Cannabalt but with the player simultaneously controlling two or three with slightly differing abilities. It might turn out horribly tricky but at least then it will satisfy the “Game must end in 60 seconds” naturally.
I will be using the sprite engine I made for LD #18, with a few bits bolted on (support for sound). It can be found on github.
There will be 2 or 3 playable characters because I haven’t decided if the third character will be playable yet. It will either be running to escape like the others or the game will be set in its gut. More on that later.
Theme: Will be one of true love, tainted love and Tetris is now a game.
Limitations: 2 colours, 1 button only (per character, will be 2 or 3 total).
Rules: Game must be code complete in the first 3 hours, if not, must start over. NO CODING AFTER THAT.
I’ve been tinkering with my LD 18 game over the past week and a half. The main things I’ve added are online leaderboards, background graphics and better in game help.
It seemed like the main problems with my game were confusion over how to play, very bare gameplay unrelated to the ‘story’ mentioned in the readme and misunderstandings over the goals. There are now several pages of in game help explaining the mechanics, with pictures, that will hopefully clear up how the vacuum mechanic works. I’ve added some nice tile mapped backgrounds and an intro ‘cutscene’ which should indicate that you have to defend the area beyond the left of the screen. Finally, it’s basically a score based endurance game so the leaderboard should emphasise that part of it.
Astrovax also turned out quite addictive, hopefully the leaderboard will make it more so. >:D
The new version can be found at astrovax.moop.org.uk.
Somehow I’ve gone from feeling like I’d barely started to being ‘finished’ in a couple of hours.
My entry is posted here. I like the core concept so I’m planning on doing more work on it after the competition to polish and add the missing features I’d like to have added.
I have a timelapse recorded but it’s taking a long time to convert and there is work in the morning. Will upload tomorrow.
I’ve finally got my sprite engine into a workable state. Time to begin work on the game proper.
Right now I’m thinking of making a shoot’em up with a vacuum cleaner like primary weapon that sucks weakened enemies in. Various combinations of enemies when sucked in can be transmuted into more powerful but more specialised weapons, possibly saving up multiple of these will allow them to be permanently merged with the ship to give some sense of progression. I suspect balancing the attention required to work the transmutation system with the attention required to play the game will be tricky.
Will post some lovely screenshots when I have something.
My basecode/engine is slowly being hacked together and hurled onto github:
This will be my first LD, looking forward to it. I want to get coding already.
I’m planning to build a very cut down sprite engine using C++ and OpenGL/GLUT. The engine I have already is a bit heavyweight for that sort of stuff, so I’ll start from scratch but aim for the same style and structure.
Now time to stop being a big lurker and head into IRC.
Tools I’ll be using:
vim for editing
git for version control
XCode (C++) as a build system and compiler
Visual C++ 2008 for the Windows port
OpenGL, GLUT and OpenAL as libraries
Photoshop CS for generating content
make + ImageMagick for batch conversion to a more useful format
Audio: (if there is time)
Reason 3 for music
sfxr for sound effects
I’m planning to record a timelapse video over the weekend using this technique.
Fingers crossed I’ll end up with a nice and reusable sprite engine at the end of it. The plan is to continue developing it for my own projects, future LDs and keep the latest source available.