Posts Tagged ‘ld23’
So now that Ludum Dare #23 has finished and the dust has settled, I guess its time to write a post about the post mortem and give some insight into my experiences with making a game in 48 hours…
Here is a diary of the major milestones of my 48 hours highlighting interesting points of my development:
I rushed head first into creating my voxel engine, I was pleased with the announcement of the ‘Tiny World’ theme, it seemed as if this theme was perfect for what I was creating… My mood was great!
Still driving ahead with the voxel engine, encountered a few problems with how the triangles and meshes are rendered, so had to go back and improve my rendering engine. Spent a good portion of these hours optimizing how triangles are pushed to the renderer and adding support and features for mesh rendering with display lists and vertex buffers.
Started playing around with different configurations for meshes/chunks/regions… came up with some interesting implementations of how a voxel world could look (sphere worlds, cube worlds, trees). I made sure to leave all configuration/ideas in the code so that I could easily come back to anything which worked.
Added support for cubes/voxels with different textures. Using a texture atlas to store the different textures. i.e. (grass, stone, wood, magma, etc) This would be important since I wanted to make a world that could be modified by using different cube types.
Towards the end of day 1
Hit a wall with regards to what my final outcome was going to be… I did have some original ideas relating to a flat, cubed world with tress and houses that you walk around and do stuff as a player, but nothing really inspired me in that respect without completely ripping off minecraft functionality (which I did NOT want to do).
So I went to sleep and hoped to come up with some neat ideas in the morning.
I woke up with renewed vigor and some thoughts about a different direction that my game could take. I decided to make it more abstract and not have a player in the world or have any direct user control, instead focus on world destruction and voxel effects.
Day 2 general
The bulk of day 2 was taken up coding effects and voxel related gameplay. I created asteroids and a layering system for my planet, exploding blocks and effects of asteroids crashing into the planet. The vaporize and terraform effect was actually something which came about accidentally, but I liked how it looked so decided to keep it in and make a gameplay mechanic for it.
This period was pretty crucial for me, I was rushing and coding gameplay elements really fast, I had a feature idea and once I got it working I moved onto the next thing on my mind. Asteroids, world vaporize (terraform), exploding chunks of the world, world rebuilding. I needed to make a full game cycle so I decided to add a timer that would ultimately drive the gameplay (destroy the world within the time limit).
I had finished the gameplay that I wanted. Next came the hard part of making it usable and playable. Having a lot of functions that are bound to keyboard keys is no good when you want other people to play your game and enjoy it.
I started to code the game flow:
Start menu –> enter game –> game timer –> score screen –> restart.
Added basic HUD and menu. i.e “Press SPACE to start/restart” and a scoring system.
My plan for the scoring system was going to be more complex with multipliers and additions for which super moves you used, but I didn’t have the time to make this work, so stuck with a simple score and time multiple.
The HUD and user interface needed work, I added these features faily easily but they were basic and static. So I started working on timings and polishing the interface. Flashing “Press SPACE to start/restart”, score screen with accumulating score. Timings and delays on the game flow to add additional polish. For example when you destroy the world, the score screen doesnt instantly popup, it has a time delay, or when you press to restart the game, the game waits until the world is rebuilt before allowing player control and starting the time. etc. This polish and attention to the small details is what makes your game stand out and feel like a proper experience, rather than a load of features cobbled together.
This last hour was mostly taken up with preparing a release package, zipping up the projects and source and testing to make sure a download of the source and executable would build and run, etc… Faily boring stuff but it does take time. I noticed a problem with absolute paths in my Visual Studio project, so had to rebuild a whole new project solution to fix this… luckily my project solution didnt contain too many header and cpp files.
I tested my package, uploaded it and then created an entry on the Ludum Dare website… then sat back and had a rest.
My entry can be seen here:
WHAT WENT RIGHT:
- Had great momentum from the start – I was able to put off the design and gameplay decisions till much later, since I had a lot to code from the start, having decided on a specific rendering engine.
- Used my own personal engine – Since I was using my own 3D/OpenGL engine, I knew exactly what I could do and how to do it.
- Voxels and cube art is great for programmers (and anyone who isn’t an artist) - Art was always going to be a problem for me, but creating stuff in 3D mitigates that problem slightly and creating stuff purely with voxels actually looks great with NO art whatsoever (See minecraft :P)
- Got lucky with the theme – Seriously, I couldn’t have chosen a better theme for a voxel based game if I tried. if the theme had been something like ‘Evolution’ or ‘Discovery’ or some other abstract concept then I don’t think my game would have turned out half as good as it did!
- Got involved with the LD community – I really enjoyed looking at the other users entries on the LD website and also posting my own progress and hearing feedback and comments from the community. Nothing is more rewarding that seeing other people’s efforts and encouragements from the community.
- Self documentation – I think I did a pretty good job on documenting my progress, taking screenshots and uploading videos to youtube. I even enjoy looking back myself now and seeing the progress that I made during the 48 hours.
WHAT WENT WRONG:
- Gameplay – I left most gameplay decisions until the 2nd day. After I was happy with my rendering and voxel engine I actually spent a good hour or so scratching my head as to what to do next.
- Focusing too much on the rendering/engine – I was torn between wanting to make a really optimized re-usable voxel engine, and adding in gameplay features. At one point I had to physically stop myself adding voxel engine features and rendering optimizations to force myself to think about gameplay and mechanics. I could have quite easily spent the whole 48 hours making a voxel engine…
- Trying to do too much – I had far too many ideas that I wanted to try out and not really having a clear design goal or making any gameplay decisions at the start meant that I was fragmented when I wanted to start making something that would be playable.
- Memory leak! - I found a major bug (memory leak) in my voxel particle renderer about 8 hours before the compo was due to end. I was leaking memory quite badly when creating and destroying particle effects that I HAD to fix. This took up about 2-3 hours of valuable time towards the end of the 48 hours.
- Basic user interaction - It is really hard polishing a user experience, so I ended up just putting a couple of buttons in for the special moves, not the most elegant way of coding gameplay features
- Sleep! - Don’t even bothering thinking that you can work solid for 48 hours, it is just not possible. It’s counter productive to lose ANY sleep and even just trying to do one all nighter is going to be detrimental to your progress. Yes you are going to probably stay up later than usual and once you are in the zone its hard to leave things to go to sleep, but if you are staying up into the early hours of the morning and going to sleep before it gets light outside, I would say you are doing something wrong.
- Prototype FAST - 48 hours goes really fast, if you are spending a lot of time on a feature or idea that just doesn’t seem to be working, move onto something else. Don’t waste time flogging a dead horse.
- Know your tools/code/engine – Since you are going to be creating something SUPER fast and with no time to spare, you really need to know what you are using. It helps if you know exactly what your engine is doing, right down to the individual function calls and rendering details. You will spend far less time fixing bugs, debugging code and trying to figure out what is going wrong if you know your engine/code inside out.
- Make decisions before the competition starts - I think I can attribute a lot of my success to this point. Since I was prepared before the theme announcement and was ready to start programming the instant the 48 hours started, this helped me a *lot*. I could have took this EVEN further by making some gameplay decisions first as well as deciding on the style of my game.
- Make the theme work for you. – (This is related to the previous point) Already have an idea of the sort of game you are going to make and then just adapt it to suit the theme… It is no good having no idea about what you are going to make and just trying to come up with a game that perfectly suits the theme. You will waste valuable time thinking and designing when you could be coding!
- Polish what you have – Personally I think that a well polished, smaller scope game that does a few features really well, is much better than some attempt at a game that has lots of features but doesn’t implement any of them particularly well. LD is a time to create something small that shows off something cool in a neat little package, not create the next big blockbuster.
Overall I had a blast making a game in 48 hours and taking part in my first Ludum Dare. I am pleased with my final outcome and even surprised myself with what I made. I now have a 3d voxel engine that I didnt have before I started the LD48 and don’t doubt that I will be using and improving it from now to create even better voxel games.
Thanks for all the support guys and see you next time.
After about a week dealing with Avidemux unsuccessfully I’ve decided just to release the rough timelapse as is. If anybody could help me with either a better video editor or explain why camstudio can’t import into Avidemux, I would greatly appreciate it.
Anyway, play the game here:
Post Mortem to come shortly.
Ok, I’ve rated 50 games so far (and left comments on each one of them because they all deserve it) so it’s time for me to share the awesomeness of the entries I’ve reviewed. I must say all of them were amazing games so it’s hard for me to pick only 10. I would actually like to pick 50 but oh well, I don’t want this to be easy for me either, picking 10 is a sort of a personal challenge.
There are a few games whose level of polish blown me away. I’ve placed them at the top 5 places of this list. Besides that particular arrangement there’s no order in the list whatsoever.
Angle Isle is my second Ludum Dare game. Here’s how it happened.
The theme arrived at 6pm PST. After throwing out the first 60 minutes of work on a bad idea, I started sketching in Photoshop for inspiration. Soon after I developed a 45 degree angled art style. It seemed interesting enough, so I spent the rest of the evening creating tilemaps and characters.
During the morning shower I tried to figure out what the hell I was making. I liked the world, but most of the characters didn’t fit. I only liked this angled bird and before I dried my hair, the bird became the hero.
After a quick cup of coffee I started the code. Angle Isle was coded in Flash Builder on top of the excellent Flixel engine. I don’t have much experience with Flixel or Actionscript, so I was often reading Flash Game Dojo and the Flixel documentation.
In the early afternoon I coded and animated the player. The desktop playtesting was done with an Adaptoid and my original black N64 controller. Once the bird’s flapping felt pretty good I started thinking about levels.
A large chunk of time was then spent on level transitions. I could have made it simple, but I wanted the levels to change dynamically. The player would seamlessly fly between one level and the next. It took awhile, but I think it was worth it.
At this point it was late. I needed to start designing levels, but there was much to tie up including touch controls, the breeze, and the shark. (More on this later.) I was delirious by 4am and went to bed a half hour later.
I slept two hours and awoke a bit groggy, but anxious to start. First task: writing music. The gameplay theme was written in Textmate with MML. The tunes didn’t flow, but In four hours I had a passable melody.
I moved on to sound effects and finished them with six hours remaining.
The levels still weren’t designed. I set a twenty minute repeating timer and tried to make, playtest, and finish each new level before it went off. This was a tall order. I spent extra time in the early levels trying to figure out what the player should experience and learn. I also found the tileset incomplete and had to spend more time adding tiles.
Halfway through level design I stopped to create the title and ending screen. This took another hour. When it was time to submit I had squeezed in 8 levels.
What Didn’t Happen
I had started to add an antagonist to hunt the player in later levels. The shark would jump out when the player was trying for the lower hanging berries. But time grew short and the shark was cut.
I also hoped to add a continuous day-night cycle with parallax stars. Ran out of time.
When the player collects more than half of the fruit on a level, a wind appears to the right and the player can ride it to the next level. A bird chirp sound effect signifies the “exit wind” is available. Although I like the chirp sound, it doesn’t communicate a connection between the berries and the wind. I should have used a wind visual and sound effect instead.
I submitted an iOS port to Apple the morning after Ludum Dare. But as I’ve been playing it more, I’m less satisfied with the performance on older iOS devices. Instead I’m looking into porting to Axel or perhaps Objective-C for the post-compo version.
Ludum Dare is awesome. I’m amazed by the results of some good ol’ pressure. Angle Isle blew away my previous entry and I’m pretty happy with the results.
If you entered the competition, please take a chance to rate my entry. I’d love to hear your feedback.
I added some bits and bobs to my entry version of the game. I’m done with it for now, but maybe in the distant future I’ll come back to it and make a much better version.
- added sound and music
- added pause, sound and music toggle
- changed level layouts to be more interesting
- changed speed of the game to generally to play faster
You can download it for Windows from here:
I made a game in 48 hours! And I even like it!
I started preparing for this LD with the release of @mcfunkypant’s book “The Game Jam Survival Guide.” I had been wanting to enter the LD48 contest ever since I first heard about it 2 years ago, but the survival guide is what finally gave me the confidence to try.
Code preparations began a week before with the warmup contest. The 1 week deadline helped keep me motivated as I put together the library of important basic functions that I knew I would need. I had decided by this point to do a pixelated platformer because I felt like that was comfortably within my skill level to accomplish in the time. I used the warmup time to hash out rect-vs-rect collisions, some really basic spring/damper physics, and a set of map loading and rendering utilities. This brings us to the first major thing that went right…
What went right
Using Bitmaps as Levels
In previous projects I’ve lost many hours of game coding because I attempted to create “the perfect level editor.” Inevitably the process takes longer than I had expected, and my final product does far less than I had hoped. This time, I was inspired by a friend of mine (who was inspired by Notch) to just use the pixel data in an image as the map. Brilliant! This means that I can take full advantage of my graphics software to make rectangles and circles and rotations and flood fills… all those things that I’d never have time to implement in a homebrew map editor. Then my game loads this image and translates each pixel of the image into a tile in the world. It recognizes certain colors as being tiles with certain properties (non-destructable, collidable, non-collidable) and, if it reads a pixel it doesn’t recognize as a particular kind of block, it generates a slightly noised-up tile of the same color and gives it some default properties. This technique slayed the level-editing-dragon that has conquered me many times before.
Choosing an Art and Game Style in Advance
Two weeks in advance of the theme being announced I knew that I would be creating a pixelated platformer. Having those additional constraints in place really helped focus my thinking once the theme “Tiny World” was announced. Making the decision to make a platformer style game early also let me write the necessary collision, spriting, and map loading/drawing code before the contest began.
Being Ready with my Tools
I devoted some pre-compo time to setting up a reasonably efficient Clojurescript development workflow. I used cljs-build to monitor and continuously re-compile my source as I changed it so I could very quickly hop back and forth between emacs and the browser to see the effects of my changes. I hacked my resource fetching code so that it would keep the browser from caching anything while I was coding. I even decided in advance that my nominal sprite/tile size would be 16×16 pixels, and I figured out an appropriate scale to apply so that the game would have the retro-pixelated look I was going for.
Throwing Away My Early Ideas
To quote Chevy Ray Johnston in “The Game Jam Survival Guide”: “A great way to come up with an idea to fit the theme is to write down the first five things that come to mind, then toss ‘em. Those are the ideas everybody else is already thinking of and/or making.”
When the theme was announced I immediately starting doodling gameplay ideas on my handy pile of scratch-paper. My first idea was a game centered around some kind of proto-plasmic hero that collects nutrients and waste and transports them around a human body. I’ve now seen a few game entries that are similar to this idea, and I would have been pretty disappointed to write a duplicate game.
My next idea was some kind of RTS / resource management game where you lay out the major components and the transport systems within a cell. I wasn’t able to find the spark in that idea that would make me confident that the game would be fun. After this idea, I also rejected another idea due to its potential art scope.
After looking up “tiny” in a thesaurus, I came across the word “elfin” and its synonyms: “sprightly, playful, rascally.” Thus was born the idea for a game about the little people who are always stealing my keys. As I was telling my wife about the idea, she suggested the collecting-and-stacking mechanic that ended up being central to the game.
What went wrong
Insisting on “realistic” physics
The number one complaint I’ve received from players is the sluggishness of the controls. You see, I fell for the classic blunder of having the keyboard apply forces instead of velocities to the character. It’s my own fault. I even got that feedback from friends that I asked to play the game after the first day of the contest. I responded to their feedback by increasing gravity, increasing drag, and applying stronger forces due to keypresses. This improved the feel, but it seems that any perceptible acceleration time translates to the player’s mind as “sloshy, unresponsive controls.” Never-mind that that is the way it works in real life… sometimes reality just isn’t real enough for video games.
Not fully rewarding the player
In my game, you race a timer and collect keys (while doing general damage to some poor sap’s house). I scored the player both on keys collected and damage done but emphasized the importance of keys by giving the player an implicit goal (e.g., “You found 8 of 12!”) However, I failed to reward the player for achieving my implicit goal! Sadly, it never crossed my mind that players would want some gratification for getting all 12 keys. It’s obvious now. It should be one of the commandments of game-creation–look for ways to reward the player. You can never reward them too much.
I had to watch new testers play my game in person before I realized how unintuitive my animated instruction screen was. The problems are clear to me now: I have arrows representing arrow keys, but they don’t really look like keys; I have “SPACE” written on a horizontal blob with the player’s character sitting next to a tool, but that doesn’t really communicate “hit space to use your active tool” like I had hoped. The instruction screen came late in my development process and after I had already used up my available fresh-to-the-game testers. I should have opted for simple text to explain the controls instead.
My final tool stack was:
- Clojurescript: [https://github.com/clojure/clojurescript]
- cljs-build: [https://github.com/emezeske/lein-cljsbuild]
- zynga/jukebox: [https://github.com/zynga/jukebox]
- Garage Band (iPad)
- Paper and a blue ball point pen
- Trello (to organize my thoughts): [http://www.trello.com]
- A very reasonable amount of sleep
Things I produced:
- My Game: http://50ply.com/ld23/
- My Timelapse
- This postmortem
- A new personal confidence that I can actually create fun games!
Ludum Dare 23 was a fantastic experience. I’m proud to say that I succeeded in my ultimate goal of making a game that I actually enjoy playing. Now I’m continuing to learn as the very talented LD community members evaluate my game and offer suggestions.
I wasn’t really expecting to do a postmortem, but due to all the feedback i ‘ve been getting i just said “Meh, why not?”.
- What went right:
-The concept: Like i always do with most things, once i heard what the theme was i started thinking ‘outside the box‘, something that no one would think about doing with the current theme….
Luckly for me, i got a great concept 30 minutes in, a heavilly-text story oriented game, something i never even attempted to make before, but i managed to stick with it till the end and the final result was pretty good.
-Coding: Due to my experience with the (not always so great) Game Maker, i was able to program the engine from scratch in only a few hours. Sure its not the greatest engine ever, but it gets all the work done which gave me plenty of time to concentrate on my cons. Speaking of cons…
-Graphics: Usually, i would put this on what went wrong, i’m just terrible at drawing but, for some reason, i really like how some of the art came out. Sure, its nothing spectacular compared with most of the games around here, it might even be on the ‘1|2 star type‘, but I was really proud of what i did.
- What went wrong:
-Sounds/Music: I always have trouble with this part, i tried to make the sound effects myself (using the mic, etc), but i just couldn’t make them properly so, after wasting about 30 minutes, i went for the overused sfxr which can get the job done but the sounds get too similar to most of the games around the comp, but what really upset me the most was the lack of music. Music would be great for a heavilly-text oriented game but, after using OpenMPT for about 1 hour and getting near the deadline, i decided to scrap the music idea which really hurt the game in my opinion.
-’Lack‘ of content: For a 48h game, its quite a lenghty game, with several diferent paths and decisions to choose from, 7 diferent people and 4 ‘zones’. Unfortunately, i planned to have +10 people and 6 zones and 2 more paths but, around the end of the first day, i saw that i wouldn’t be able to do that, which made me rewrite most of the dialogs for the NPC’s, sometimes making them say and give the same quests on diferent paths. And, while its possible to have 2 ‘diferent endings’, they were rushed out on the last minute, something i REALLY didn’t want to for this kind of game…
Aside from all that:
-I was able to finish the game in 48 hours =D.
-About 40% of the time was spent writing dialog for the NPC’s.
-I learned alot on how to handle ‘dialogs’ and ‘scripted events’.
-Music making is not for me…
That’s about it i think. I might plan to complete the game later on since i’m getting a lot of great feedback, something i wasn’t expecting from this kind of game :).
or “What not to do during a compo” xD
Once again I’ve taken part of the Ludum Dare. Last time I ended up really slacking off… So, this time, I forbade me to do anything not related to making a game =D . Turns out this didn’t worked as planned… But I must say that I really had fun.
Though I made a game about a tiny little creature that eats others tiny things (what, in my opinion, doesn’t really have anything in common with the theme… since it’s missing the “World” =x) this wasn’t my original idea. After seeing the theme, I thought about what to do and came up with two ideas:
- backup idea: a game about a tiny creature that is hungry and keeps eating until it grows so much that it can eat the planet, then it would go to another one; (this is a little diferent from what I ended making)
- main idea: explore a tiny world, interact with it’s tiny inhabitant, then [the player would] play in their tiny reality…
I really don’t know why, but I thought the latter would be better. Even though the idea was interesting, when I completed the “macro world” parts I couldn’t think about anything to do in the tiny world… And what’s worse: the game wasn’t fun at all! >_< (at least, I learned how to implement a “random dungeon generator”… or, how I really did it, “random paths between objects in a random landscape” =D )
So, within 8 hours from the compo end, I had something I wasn’t happy with (by “wasn’t happy” read “couldn’t work anymore @_@”). Then I did what any (in)sane person would do: I scraped that idea and start a new project… Since time wasn’t exactly on my side, I quickly remembered the basic feature: you eat things and grow bigger. I also had a new idea: you can jump on things to shrink them. Since I was using Flixel, i didn’t have to remake the core… but I couldn’t reuse anything usefull from the original idea (well, I copied the “control” class… but since I didn’t allow user modifications to the controls… it was kinda useless… xD).
Then, in a hurry, I began doing everything needed: coded, drew the sprites, coded some more… Had trouble comming up with the song xD. Then, with the base working kinda properly, time to design the stages! I ended up doing only tutorial stages and two that should have enemies… but I ran out of time to implement them. =x
Since I rushed so much, I didn’t realize that I forgot to allow the creature (which had already been named Hummy =3) to grow bigger than the world in order to eat it… Anyway, in the end, I was able to work something out that (even though wasn’t exactly what I had planned) I really liked. =D
Next time I must be sure to think throughly about what I’ll be doing… Though I must say (now, after the compo…) that it was fun… it would be really better if I didn’t repeat this. I regret not doing a better game (especially since I know that, had I choosen this idea from the start, I would be able to do something better). =X
Thanks for reading. =]
Crosspost with my wordpress – seagaia.wordpress.com
This past weekend I made a game, “Naos”, for Ludum Dare 23, around the theme “Tiny World”. If you haven’t played Naos yet, you should do so now, the blog post will make more sense.
Aesthetics were very important for me in this jam game. So I tried to pick carefully what kind of music I wanted to write. The game wasn’t supposed to represent a wholly realistic thing, so the music sort of reflects that in a haunting/minimal way (the organ-like house loop, the chime-like thing in the forest). The more action-like piece at the cliff helps to show that there is some action going on there (i ended up redoing this one the most…). As for the intro/ending thing…I couldn’t really think of a fitting melody, so I added some fancy-ass white noise that I thought fit.
I like the chimes piece the most, and would like to expand upon that. I feel like part of it was definitely influenced by listening to the Fez OST ( http://disasterpeace.com/ )way too much over the weekend – especially with the bitcrushing it uses, which I felt I may have overused in a place or two. Two pieces in particular I found salient were Spirit and Nature.
Graphics style…WHY? MY EYES!
Admittedly the game’s blur was a bit much. I did think it suited the quiet/haunting/ethereal-esque nature of the game, though. I wanted to try the scribbly style. Spending more time would have of course improved…well, everything. In a normal setting they wouldn’t be that rushed, I’d use a tablet, etc. Right now, it looks just good enough to not seem completely sloppy. (But is, still, of course, sloppy )
I was playing a lot with BitmapData objects in AS3 (surprisingly for the first time…why? I don’t know…but now I’ve got a level of comfort). They more or less represent what will be drawn to screen. And you can do interesting things like pull out certain color channels, transform them, and superimpose them on the original graphic. Or, you can blur things at different levels. The way I did blurring wasn’t ideal, I surely could come up with a more plug-and-play way of doing it, rather than the somewhat terrible way I have now (at least it’s organized terribly), which was to copy the sprite’s data, and keep some external data that determines how much to blur it – essentially, I have a copy of the data – I copy it to the displayed sprite, blur it, draw that to the screen, etc. The same idea goes for the color offsets. I played around until it looked okay.
I also played with a new logo for Seagaia today. It shows up on the intro screen. I like it. It’s a bit of a rip-off from. It was fun to make, at least the top part. There’s this nice thing in GIMP where you can copy and paste every other row, and then you make it a bit transparent, modify it a bit and superimpose it to get this neat shadow-y effect.
oh so how was the coding
Straightforward for the most part. Every room was a different state, with its own events and so forth.
Became an ugly mess near the end with the event coding since I haven’t figured out a nice way to do events with flixel yet…want to definitely figure that out. I’ve been asking around a bit, but not much in the way of detailed cutscenes. x_x
Since I already talked about the graphics coding, the only really interesting aspect was the events. How do they work? Well, for one, it helps to draw a tree of your dependencies with state variables. For example, “E_CLIFF_2″ represents the 2nd cliff cutscene, “DRAWING_1_DONE” represents finishing the second drawing. And so every iteration of the game loop, depending on what screen we’re in, we check to see if we need to start an event. Essentially, events just freeze character controls, and wait for some condition (my player’s x being at some point, pressing x to advance text) to occur. Each event has an “event_pos” variable that is incremented when that condition is true, bringing the event to the next part (text, movement, whatever).
While this method works for a game jam, it doesn’t really scale well (see the other game I’m making) when it comes to moving many sprites that you don’t want to have to hard code into the game…and it’s a bit hard on the coder with the repetitive switch statements (see.https://github.com/SeanHogan/seagaiald23/blob/master/src/CliffState.as JEEZUS.)
An interesting bug resulting from this was that I didn’t nest one of the “if you press x increment the event counter” things deep enough, so if a player pressed X before they should have on the forest screen, you would be frozen when you actually pressed X over the right thing. Thanks to my friend Runnan for showing me that issue…gah!
One way this could have been done better is to have only checked for events once upon entering a screen, or have had some single “an event happened” variable to be checked, rather than all of these conditions on every iteration of the game loop. While this is okay because performance didn’t really become an issue here, it would be something to think about in some sort of later implementation.
so what the hell was this about?
it’s a secret! well, a few people have messaged me on NG about it, surprisingly. My interpretation of it is more or less solidified, but it’s interesting to see other people’s takes on it as well. In lieu of not looking all pretentious, i won’t write about it here. but if you’d like to know, shoot me a message.
that’s all for now.
if you found this interesting, you should follow me on twitter . http://www.twitter.com/seagaia2
Well, my Ludum Dare submission contains the whole message I wanted to send, so I’m happy with it. But it lacks a lot of gameplay and you play only for one minute before reaching the end, that’s obviously to short ! So here’s a release with many levels (in fact, infinite levels) and more challenges. I also added some features as a red flash when you’re hurt, some graphics changes so you can see best your player in the middle of the “cells crowd” and some tiny stuffs around.
Have a look and try it ! (it’s also accessible from the same link as the official jam release, just click on the “post compo release” on the bottom)
For LD23, I decided to go full-retro, and make a z80-based game that runs on Pac-Man arcade hardware. I’m not going to lie to you, I didn’t even come close to completing it, and I’m totally fine with that. You can see the “finished” product here. From there you can get the romset (mspacmab – bootleg spaceman, for reasons I won’t get into), the source, and the link to the google code repository that has my Z80 kernel which I used for it. Fact of the matter is, I wanted to do a Z80/Arcade rom game for LD, I did it, and I’m happy that I did. I think I may do this for future LDs as well, learning from each (failure) along the way.
I knew I wouldn’t be able to finish something in time for either the regular compo or the jam, but I wanted to see how much I could get done in time, without going out of my way to devote all 48 hours on it.
I was coming home from a work trip, so if you watch the time-lapse off of the link above, you will see that I’m actually working on it in an airport (in Atlanta, Georgia) as well as on an airplane, along with on the couch at home and at an office desk. I squeezed in as much time as possible.
The main thing that prevented me from getting (a little) further is that I was planning to spend evenings on the work trip i was on, in re-aquainting myself with the tools (assembler, z80 kernel, etc) that I haven’t really looked at in about 5 years. I also wanted to add support in my “Llemonide” z80 IDE/emulator, for building and better debugging. Instead, for various reasons, I was unable to have any downtime at all on the work trip to devote to this project. I was essentially going in to LD completely green on the subject. I spent a lot of time creating the project, remembering how my z80 kernel works, basics like that which should have been old-hat.
So what did I learn? Spend A LOT of time getting familiar with your tools. Do practice jams. Try to minimize the amount of boilerplate stuff you’ll be recreating to save time. You need to spend your time making your game, not fumbling with your tools.
Better luck and progress next time!
As a sidenote, all of the source for mine is available at the page for Tiny World ’82, along with links to the tools/kernel, and the romset. I have included instructions to running it within the Google Chrome browser, in case you don’t have MAME handy. Check it out and review it if you like. I’m just hoping for an non-zero score on this one.