Posts Tagged ‘tiny world’
It is a First Person Shooter where you have to save the miniature Trivials from the mega-spheres!
I feel like I did better on this game, but it sort of lost the originality Isolated Assault had.
How I rated Other People’s Games
The games where a lot better overall this time around and I mostly gave 4 stars for most categories.
Results (Drum Roll)
Audio my highest rank, at #211, which made sense I guess. I put a lot of work into the music and sound effects, so thanks voters!
Innovation, however, was the lowest. I didn’t think an FPS was very original, but the idea of saving the smaller towns was new, so I don’t know what happened here…
Looking at my score compared to last LD, I did a lot better last time, my highest rank being #40. Then again there was a lot less people less time.
STAY TUNED FOR A SPECIAL GAME SURPRISE! (A sequel to a very popular game by Rob Productions :3 )
Nice job, everyone, great LD! <3
Hey there jammers! It took a while but we finally found some time to sit down a bit and reflect on all that went down during the LD jam. It was our very first attempt. We had no idea what to expect from ourselves or the community and we couldn’t be happier with the experience. That being said let’s get down to the matter!
Check him out here!
Since we basically had no experience making games, we tried to aim for a platformer which seemed, at the time, the simplest way to make something viable in 72 hours. Looking back, not so sure it was the brightest idea. Although we defined this early on, ideas went crazy and at some point we had to stop and settle for the one that fit our skills best. Luckily enough it was one of the favorites almost from the start of the brainstorm.
Regarding the theme we thought of the most obvious topics and discarded them right away to try and make something different. By thinking about various interpretations of world, we came to the inner world of a being or how he perceives it. And so, Phobius deMelt was born! An overly phobic boy who sees his world close on him as he gradually panics from claustrophobia. It seemed to fit the theme just right and also provide room for a cool mechanic. It would also be very dependent on the audio to set the mood for the character which was a plus.
Pretty fast a story formed around phobius. He’d be going on some kind of a tour to a building with his family but fearing closed spaces he gets scared at the entrance and is left behind. The rest of the time he’ll spend trying to catch up to his family growing ever more phobic with the fact he’s now also alone.
So, this is our first Ludum Dare. Or was? Just 3 days left!
Anyway, we didn’t know what to expect. I mean, we are from Argentina. A place not precisely known for it’s videogame industry (which is actually growing fast!) And we are just two regular dudes!
Thanks to the comments and feedback that our 72 hs. game has been receiving, we have an extreme motivation to keep developing on it (AND keeping it FREE for browsers!). So we decided to give you guys a tiny present: An HD widescreen wallpaper!
Again, thank you very much. We still have about 1240 games to play and rate! See yah!
[My name is Carlos Leituga and I’m a Game Designer / Implementer in a Portuguese company, where I’m working on a _NEW_ Hidden Object Adventure. That one is going to take a bit to finish, so I'm back again helping the Make A Game team to create a game in 72 hours for Ludum Dare #23.]
«That’s a wrap!», we said when “alone I art” was submitted, «We’re not going to do another Ludum Dare before making full games out of this and Eggscape, okay?»
We all agreed, until seconds later someone reminded us that the next Ludum Dare was going to mark the 10th Anniversary of the competition.
«#&$*@!», I said, before blacking out and waking up four months later and right when the theme was announced.
«The theme is Tiny World?»
«#&$*@!», there, I did it again.
(Edit: this is the game I made, if you’re curious. I will be posting my own late post-mortem and list of favorites next.)
The past couple of weeks have been insane, and I got way too carried away with meeting so many people through Ludum Dare that Twitter’s system suspended my account under suspicion of my being a bot. I took this as an opportunity to step back and take a look at all that has happened.
Ludum Dare is not the only game jam, but it’s the most significant. Because of its size and reach, long history, and incredibly strong community, each Ludum Dare creates actual ripples in the game developing world.
The best examples of how awesome people are to each other in LD are the game reviews and the posts on favorites. There is a lot of effort put into encouraging people to see the qualities of their games and how to improve. No matter how unfinished the state of the game, sometimes even unplayable, the comments are always incredibly encouraging. There is always something awesome about it.
It has moved me deeply to see what a wonderful gateway into game making this is. For me, being so readily embraced even though I had never made a game and knew absolutely nobody before the competition caused something long dormant in me to awaken. I’ve learned many lessons that, if it’s not too corny, I’d say might have saved my life.
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.
This is a play-through video of our Ludum Dare 23 Jam entry, Stranded.
If you’re interested in playing the game, please note that this video goes from start to finish, so contains spoilers.
The timelapse is now available:
I captured 1 screenshot every 5 seconds the video shows 25 of these screenshots per second.
I find it a little bit annoying that wordpress does not embed https youtube links.
I’d been meaning to write this a lot earlier, but I’ve been way too busy to do it until today. Anyways, I made an online persistent world game in 48 hours. I wonder if it’s been done before during LD? We really need a tag system for games or something, it’d be interesting to be able to look up games with
specific elements. This post will be a bit of a combination of a making-of and a post-mortem; I’ll explain how this game came to be and comment on it.
Before Ludum Dare
This was my second Ludum Dare, so I had a decent idea of what to expect. Last time I used Unity, which had both its advantages and disadvantages. But since I’m the kind of person who wants to be able to customize everything and doesn’t want unnecessary things forced into his game, I prefer not to work with Unity. Fortunately, since February I’ve been doing an internship where I’m working on an XNA game, so I got pretty familiar with it. In making that game, I wrote a simple sprite engine which turned out to be very useful, so a week or so before LD23, I took the engine, removed some game-specific functions, added a tiny bit of documentation and released it as VBXSE. A short while ago I’d also been working on a simple netplay engine named GNI in my free time, so I decided to release that as well.
The original idea
After waking up at around 9-10 AM (competition started at 3 AM for me, but sleep is very important if you’re doing a 48-hour solo project), I checked the site to find out the theme was unexpectedly ‘Tiny World’, a theme I hadn’t even considered a possible winner in the poll. After thinking about it, I decided to make a roguelike-ish survival game similar to UnReal World where you and a couple of NPCs were stuck on a tiny island and had to get food and shelter to survive. That’s right, the original concept was nothing like what the game eventually became. I wrote down the basic game design in a text file, if you want details. So, I started working on the survival roguelike…
World and Graphics
Since roguelikes tend to be played in console windows, I decided to keep the area size small enough to fit in one. After some thinking, I decided square areas would make the most sense considering you also need room for other game information, and I ended up at a 22×22 world with each tile having 22×22 subtiles.
After a rough interface sketch, some calculations and some guesswork I decided the tiles would graphically fit best at a 32×32 size. However, I’m terrible at drawing stuff, so I decided to turn ‘lack of skill’ into ‘style’ and went for a pixel art look; I drew every tile and item in 8×8 and then resized it to 32×32 to make it look ‘retro’.
I made all of the art in GIMP because the Paint that comes with Windows 7 tries to be too hard to be a real drawing program and in doing so actually becomes worse for making pixel art…and it still doesn’t have any transparency. Brushes were surprisingly actually very useful when making tiles like grass, sand and sea. Just keep using random brushes and you have good-looking grass. Definitely something I should use more often.
Sound and music
The music for the game was made in FL Studio 9 using only soundfonts from DSK Music‘s HQ Instruments set. Although the effect is very subtle, the game actually contains dynamic music; although throughout the entire game the same track keeps playing, there’s three slightly different versions of them. They play simultaneously, and the volume adjusts depending on where you are.
The music used the ‘Celtic Harp’, ‘Ney Flute’, ‘Percussion 1′, ‘Oboe’ (forest only) and ‘Harp’ (beach only) soundfonts. It was inspired by Paavo “Tarantula” Harkonen’s soundtrack for obscure MMORPG Dransik (now a shadow of its former self and named ‘Ashen Empires’) and a random street performer playing on a harp the day before LD23.
The sound was created by rubbing or hitting various objects around my desk against eachother in different ways, recorded with my laptop microphone and edited in Audacity (amplitude change, pitch change and echo). Like the music, it was mainly inspired by obscure MMORPG Dransik, where you would hear a simple but satisfying sound whenever you did things like cutting trees and mining.
But how did it become a persistent world game?
Development started out well. I started by making simple ‘world generation’ (filling the entire world with grass tiles). Then I made movement work, then proceeded to add sea and forests to world generation. I added the axe and item usage, so you could chop wood. Then I also needed support for dropping and picking up items, which also required a menu to let you choose between items. I also made sure you could save and load your world, so I made functions to serialize the entire world to a long string and load it again.
At that point, day 1 was already over (LD goes from Saturday 3 AM to Monday 3 AM here, so it’s 2 days instead of 3 as it is in some time zones), and there was no sign of crafting, construction, the hunger system, NPCs, wildlife, fishing and similar methods of food gathering, liquids, an age system, building recognition or pretty much anything beyond the very basics of the game. Whoops. So, what is the logical thing to do when your plans seem way to ambitious?
I went with the logical solution: I changed my game into a complete persistent world building game. Of course it’s a ridiculous decision to take halfway through development, and even more so when your project is in that state due to being way too ambitious, but all things considered, it ended up being not as unreasonable as it sounds. I had recently created a netplay library, and though network communication is always tricky and it was not tested much, it did seem to work perfectly from the small amount of testing it did get. As a game design decision it was more logical than anything; I was just a tiny bit of code away from making a game where you can build stuff, and games like Minecraft, Terraria, Active Worlds, a whole slew of BYOND building games and many more games have pointed out that just building things for other players to see can actually be fun in itself. Add to all that that I could already serialize any part of the world to a string, and the decision was made overnight to go all-or-nothing for an online persistent world game.
The first thing I did on the second day was finish the crafting and building system (otherwise even having a persistent world would be futile). Then I used my GNI library to write a server program and a client class. The client would ask the server for the serialized string representing the world map, and then for the serialized strings of each of the areas in the tiles (each tile on the 22×22 world map contains an inner area consisting of 22×22 ‘subtiles’, if you haven’t played the game). I found out the serialization had some errors, but after some bugfixing, it actually worked perfectly. Then, to make client changes affect the server and have the server keep the client up to date, instead of at the start the server would send the client the inner areas only whenever he zoomed in or walked to a different inner area, and the client would serialize the entire inner area and send it to the server whenever a tree was cut, an item was dropped or picked up and whenever something was built. It’s an inefficient approach (the reason it lags whenever you switch between areas or do something area-affecting), but it worked great for a 48-hour game. I then proceeded to add functionality for chat, player names, seeing each other, et cetera.
After the netplay features worked, I decided to add what little extra content I could still safely push in (mountains, stone, and anything that requires stone – yes, originally there was only wood) and release it.
What I like about the game
-It’s a persistent world game. That by itself is awesome.
-It’s my first succesful attempt at a non-BYOND online game. There was one other finished game were I attempted netplay, but its netplay was a horribly buggy mess that desynced for any players that were more than 2 meters apart.
-The world generation is nice. I’ve barely done any random world generation before, so the fact that I managed to get a properly shaped island with properly shaped beach and mountain areas out of it is pretty nice.
What I dislike about the game
-Lack of content. And I mean utter lack of content. There’s two kinds of walls to build, two kinds of floor plus four natural floor tiles, one tool to make and one decorative item. Ludum Dare games aren’t known for their extreme length, but it’s very minimal here; it’s a building game, but there’s hardly any variation in what you can build, so you get bored very easily. This is especially disappointing after my previous LD game, which could be played for significant lengths of time and still be interesting.
-It’s buggy and laggy. Whenever you zoom in, lag. Whenever you build something, lag. Whenever you cut a tree, lag. Whenever you move from one area to another, lag. And those 4 natural tiles I mentioned at the previous point? Good luck getting three of those without relogging a minute later, as they mess up something in the graphics (still not sure what causes it).
Things I should do again next LD
-Use VBXSE and GNI again. Especially the latter came as a surprise in how powerful it can be in just a small amount of development time. I was afraid of netplay functionality before considering the debugging hell it can cause, but now I think I’ll just plan for netplay from the start of the theme allows it.
-Use pixel art. I can’t draw, but ‘style’ turns out to work as a pretty good excuse to hide my lack of skill.
-Record random objects using my laptop microphone and edit them in Audacity for quick sound effects. I’m pretty satisfied with how they turned out; they subtly add a lot.
-Be overly amibitious. Partly because I’m just an idiot, but also because going beyond what you know you can do allows you to learn new things. It would be better for the game if I didn’t, but in the long run this is very useful.
Things to keep in mind for next LD
-I should make sure there’s enough content. LD is for games, not for tech demos.
-I should try to get the day after LD off work. Starting a week with a serious lack of sleep hurts your productivity for the entire week.
-I should update and improve VBXSE and especially GNI. They’re awesome, and therefore they must become even more awesome.
-I should make sure I’m used to the the tools and libraries I’m working with. I thought I knew XNA, but it wasn’t until halfway through the project that I realized I didn’t know even how to play multiple music tracks at the same time and change their volume. I also wasted a lot of time debugging an issue that happened because I didn’t take into account that using auto-poll GNI’s client class handles received data in a different thread.
I was initially considering updating the game a bit, adding some extra content and fixing some things I didn’t like, but there are so many things I’d like to change and so many things that need to be changed to make the game actually fun that it’d just take too much time. I think it would be interesting to one day make a complete game based on this, but that’s the kind of plan that will either never see the light of day at all or won’t be used until years later.
By the way, I forgot to do it initially, but I’ve slapped a Creative Commons license on the game so you have the right to mess with it in any way you want. Well then, see you all next LD!
Appendix A: Tools/libraries/etc used
C#: The language the game is written in.
XNA: Engine used for the game.
Microsoft Visual Studio 2010: The IDE I’ve used to make the game in.
VBXSE: XNA Sprite engine, used for all graphics stuff.
GNI: Netplay library, used for client-server communication
FL Studio 9: Used to make the music. I’m a fervent supporter of pattern blocks, even as Image-Line gets rid of its unique features.
DSK Music’s HQ Instruments: Set of amazing soundfonts I use for music. The music for this game was made solely using DSK HQ Instruments, using default FL Studio VSTs as effects.
Audacity: Pretty much the best audio editor around. Used for sound effects.
Appendix B: Network signals
If you’re interested in how exactly the server and client communicate, these signals are sent back and forth. Each signal has a ‘key’ denoting what the signal is about, and a ‘value’ containing other info.
Server to client
(None) – A signal with no information to check if the client is still connected.
identify – Asks the player for his appearance and location, in case some other players requests it later.
goplay – After version check and sending the necessary maps. Tells the client the player can start playing.
gspfinish – Indicates the server is finished sending inner tiles and the client can enter the subterrain the player was about to enter.
message – A chat or system message. Output the value to the displayed messages.
people – A list with the unique player numbers of all players that are currently online. If a known ID is missing, that means a player has disconnected. If there’s an unknown ID, the client sends a ‘who’ signal to ask for information on the new player.
person – Information on a player (ID, appearance, location) as a response to the ‘who’ signal. The client will then add the player to the list of known IDs.
pos|X – Where X is the unique player number of a different player. Tells the client where the specified player is right now.
subter|X|Y – Where X and Y are integers representing coordinates. Replace the inner tile at X,Y with the serialized inner tile in the value string.
subteru|X|Y – Same as above, but the change is vital, so if the player is in the area, it MUST update the inner area before letting the player continue doing whatever he’s doing.
versioncheck – Asks the client to send his version number, to make sure he isn’t using an outdated client.
versionmismatch – Tells the client he can’t play on the server because the versions don’t match. Which version the server is running is in the value.
where – Requests the client to send a ‘here’ signal, telling the server where the player is.
worldmap – Sends a serialized world map as the value. Allows the client to build the same world map client-side as the one that exists server-side.
Client to server
The server automatically sends these signals without the client saying anything to it:
Every 2 seconds – where – Ask for the player’s current location.
Every 2 seconds – pos – Tells the player where other players are.
Whenever a client connects – versioncheck – Asks the player for his client version.
The server can receive the following messages:
cmsg – Client wants to send a chat message.
getsubplus – Value contains X and Y coordinate. Client asks server for the inner area at (X,Y) as well as the 8 areas around it. Server sends them followed by a ‘gspfinish’.
here – Client tells the server where the player is.
ident – Client tells server information about the player (appearance and location). Server stores the information and sends ‘worldmap’ and ‘goplay’ signals to let the player start.
nick – Sets the player’s nickname.
usub|X|Y – Client tells server they updated the inner tile at (X, Y). Server updates world and sends a ‘subteru’ signal to all players.
version – Client tells server what version they’re using. If it matches, the server will return an ‘identify’ signal, otherwise it will return a ‘versionmismatch’ signal.
who – Client asks server for information on a player. Server sends a ‘person’ signal in response.
I made Flea Circus! There’s not a lot to it, but I’m really proud of it, and this was my first LD. I just wanted to write a little bit about my what went right and wrong to clear my head and process the experience. Before you read this Post-Mortem, please check out the game by clicking here. If you don’t want to read it, please at least go rate my game: click here.
What went right
I did a really good job of taking each idea that came out of brainstorming and running it through a Feasability Filter® before risking taking the idea further in my head and becoming attached to it. I stripped out the idea of levels, and character creation and character selection that’s typical of extreme sports games and just focused on the fun of jumping around and doing tricks.
This first images in my head when the theme was announced were of Super Mario Galaxy type planets with big oversized objects on them. So – I knew I didn’t want to go with something like that because I wanted something fresh and different from the rest of the competition.
Truthfully, though, there is one other flea circus meets extreme sport game in the competition. Weird.
Getting all the timing and the combos working was a really satisfying experience from a coding point of view – but I’m also proud that it works, and works as expected. Granted, you can say the game’s a little easy, but that’s aside from the fact that it’s very satisfying to make the little flea do his tricks!
Think of fighting games : Yeah, you can beat me by button mashing – but can you beat me and know what you’re doing?
What went wrong
Believe it or not I have a background in Graphic Design! But small pixel art … man, I don’t know what I’m doing. Those curtains look pretty good, right? And so does the wood of the stage. But those judges and the flea … could be better to say the least. I need to get good and I need to get fast. I wanted to have poofs of smoke and blood splatters and animate the fire in the hoop.
I may have gotten a little too obsessed with wanting to use the same dimensions as the gameboy advance. I should have just made a game with the style that it needed and not with a style I wanted to try.
Also, yeah, that flea needed more contrast, I don’t know what I was thinking.
It’s easy. It’s an easy game. In playtesting half said it was too hard and half said too easy – no one said ‘just right’ but me. So I went towards making it easier for those who said it was too hard and I think I made it too easy.
This is was my first LD and it was an eye opening experience:
- I need to work on my graphics abilities and I need to figure out my graphical style.
- I discovered the kind of game I like making though. My last game ‘Run Along, Now’ had some similar elements with ‘Flea Circus’. Perhaps I excel at creating fast-paced action games?
- I’m really pumped about game design again. I was really down in the dumps about my abilities and whether or not I had any talent. You may disagree, but I think this ‘hobby’ of mine is worth pursuing more than ever now.
Thanks for reading, I had a lot of fun at my first LD!
While voting, I came across a lot of games that didn’t really fit the theme. However, among the games I’ve played so far I noticed four games which perfectly fitted the theme:
1. Cage by epicSpeedTurtle
This is may personal favourite so far as it resonated pretty well with me. At a glance you’ll see that the game has really few and HUGE pixels, but despite that it manages to convey a very strong mood and a sense of tinyness: You’re an awfully sad hamster living in a cage (yeah, you probably have one in your home) – and that’s its world – A CAGE! A f***ing 48×24 pixel cage! To make things worse, a fly comes by and makes fun of the hamster – a fly of all things, yeah that annoying flying creature that is free as a fly can be. If I continue writing I’ll spoil too much… I liked the game!!!
2. Casal Navity by Nanofus
This one is pretty original – it’s actually the most original and weird game I’ve encountered so far (and I thought my game was weird). You’re a small (really small) funny looking creature thingie living in someones nose :D. Yeah, it’s pretty yucky from our perspective, but the story-line is presented from its perspective: the nose is its world, its home, its comfy moist cave full of “life-giving substance”. It becomes kind of dangerous after a while and fun :D. PLAY IT!
3. Atom Planet by NMcCoy
This one suits the theme AND it has complex gameplay elements: it’s 2d Minecraft like game – so, it’s rather complex for a 48 hour game. It’s very fun to play as you always try to find all the possible recipes. Moreover the world is also affected by weather (it’s not there just for visuals) and you even get to pick clouds (and even make them).
4. Gum Crisis In Pipe City by jason.bakker
This was the first I’ve played from this LD. It’s really nice and original: you control multiple worm like creatures of all sizes (I mean, from tiny to supertiny) and you… aah I don’t know how to describe the game best – just play it!
I’ll continue playing and judging. I’m planning on making a list of not so great games but with huge potential because one shouldn’t stop developing after the first 48 hours.
(oh, I hate WordPress)