So first of all, thanks LudumDare, because of you I had awesome weekend. It was my first gamedev experience and it was amazing.
My game is Glow. You can download/rate it here.

I’ve tried to do my best on theme/mood. And I think I succeeded in it.
What went right: code, sound, idea, storyline
What went neither right nor wrong: art, level design
What went wrong: packaging. I though it would be easier :/
See you next LD.

Play the game HERE.

Timelapse video:

I’ll make it short and to the point:

RIGHT

- I finished on time

- Interface

- Idea

- Art

WRONG

- I had to leave many stuff out

- No time to make music

- No time to polish

- Some problems with the software (The Games Factory NGE) (Game was supposed to be displayed scaled 2x, not in a small window. Didn’t know it wasn’t possible until I was done).

MISC.

I don’t think the game reflects what I intended, as the content is very limited but it may give imaginative people an idea of what I had in mind. I’ll surely keep working on this to make a proper game that’s more enjoyable.

Well we didn’t make the deadline for the Jam, but we’re committed to finishing the project regardless. We just rushed into this thing too quickly and got in over our heads. The physics for our original idea were too complicated and everything just fell in. Here’s our latest mockup, programming starts tomorrow. If you’re interested in following our progress, check out @undergroundpixl on Twitter. We mainly focus on iOS development, but plan on participating in Ludum Dare Jams into the foreseeable future!

I had a lot of fun this ludum dare, thanks everyone!

The game I ended up making was Step Off, which is a simple play forever style game with 40 items to unlock. The description from the game page- “you play the purple guy who is so deathly afraid of other people’s company that it physically pains him. To stay alive he must make them leave. But he doesn’t want to talk to them or touch them so he just throws stuff. ”

This wasn’t the game I initially set out to make, however. Infact, it was quite the opposite at first (a brooding, dark, abstract platformer/narrative), but I felt that it was boring and not fun so I started over with something I thought would be fun.

My process in making Step-Off was very “loose”. I didn’t really know what I was making at first, I just added things one by one, thinking to myself each time, “that would be fun.” And eventually things fell together with a little elbow grease.

The controls: There has been a lot of mixed criticism and praise on the aiming while throwing objects, so I’ll go a little into my thought process behind the choice. I didn’t want to use a precise aiming method like the mouse, because that would have been to easy and tedious. I wanted something that felt like how I feel when I’m throwing something myself in real life- challenging but it’s satisfying when you hit something.

What went right: I learned a lot from my previous entries, and because of that I had about 5-6 hours to polish the game and add more unlockable items.

What went wrong: wasted a little too much time on my first idea when I knew deep down it was never going anywhere. Also I bought nothing but lasagne to eat which got really boring…

I’ll end with a gif since you guys seem to enjoy those a lot

Thanks again guys!

And you can play the game here.

So time for post-mortem is here…

This time I’ve managed to create fullscale and mostly playable game (probably best I’ve done in 4 competions I’ve attended in last two years) which is even quite fun to play, so I’m pretty happy with myself, even if I had to move to the jam and use another 12 or so hours to finish it.

It’s an oldschool style FPV dungeon crawler with a goal to find your zombie kittens and be finally alone with them (and a big bag of brains), but rotten undead pirates ninja looted your kittens and you have to take them back. I even had time to do some leveling with three skills (ninja, pirate and undead) and tune up the game (not completely happy with it, it tends to be too easy later on, but since playthrough takes about half of hour I just had no time to do more testing.)

What went well:

Using Unity (well mostly) instead of coding everything from scratch… after several months of using Unity fulltime I’m quite skilled with it and this time most of the things I hate about Unity wasn’t issue, since I was doing PC / Web build. And web build is one of the things I like on unity (even if there’s no linux player). (BTW web version of TDMR is just about 700 kbytes, while pc has 20  megs :/)

Drawing 2D “art” : I’ve spent just maybe two hours drawing all textures and sprites and skins for characters using tablet, Paint.Net and not giving a damn about how hurtful it will be for eyes of some more sensitive people I could have done something much better if I wanted… but it would took me at least day. And this way I can boast about having “style”

Decision to use pirate/ninja/undead – not exactly sure how I came to this connection (I think it’s from some picture I’ve once seen, who’s the bigger boss, pirate, ninja or zombie?), but i’ve mixed it together and in the end I have a lot of enemy types… easily made by combining three (well, four if you count ghost) base types- and I used it as a base for RPG system too.

Adding sounds: with about hour to spare for submission I took my mike and audacity and made some sounds and “voiceovers”, quickly patched it to the code and I’m quite happy with the result. Just too bad I hadn’t time to sing some songs as background music (brains brains brains brains braaaaains, brains brains brains!)

Keeping number of game elements in check I made most of the things I wanted to have in the game with the exception of brain-o-matics for buying brains.

What went mostly ok:

Most of the coding in unity, although I’ve spent some time trying to debug few stupid bugs I made (and debugging is sadly one of the beefs I have with Unity – it works much better on WIN editor, but I’m so used to total instability on MAC and “printf” debugging that instead of firing up monodev debugger and hoping for best I’ve spent a lot of time by putting numerous Debug.Logs everywhere. Resulting code isn’t even that ugly as usually is in my speed hacks… although I still hardcoded a lot of things without using some better design – if I ever try to use TDMR as a base for some more serious dungeon, I’ll have to refactor at least half of it.

Level design Originally I wanted to have few more levels (but smaller), but in the end it’s just one and I’m quite happy with it, it reminds me good old times with Beholder and Dungeon master, so it’s definitely ok from my point of view I’ve originally considered doing rogue like randomly generated levels, but it’s probably good I hadn’t even attempted it.

Playtesting and tuning up RPG system – At one point I realized that I’m playing for fun, not for testing, which really gave my morale big push. Also my GF used as playtester liked it (she’s as crazy about old RPG’s as I am), so although it could use some more tuning with difficulty and some parameters, it’s ok.

Sleeping enough I’m getting too old for non stop crushes and since I’ve ended one of the worst periods in my 10 year carrier as gamedev just before the start of the LD, I decided to take it easy. But in the end I had to move to Jam and use another 12 or so hours to finish it. I think I’ve spent about 30-40 hours total working on the TDMR.

What went bad:

Theme I was really unhappy with the theme (once again)… I’ve spent some time racking my brains for ideas about using alone for something original AND fun to play, or something interesting to flex my code skills on… then I gave up. Since I’ve always wanted to make some oldschool FPS RPG (and never found enough time), I’ve decided to make it and force it somehow on the Alone theme… (from what I’ve seen from other submbissions, I wasn’t the only one using this approach – some entries don’t even try to use alone in any way).

Idea about using animated chars instead static sprites – near the end of the day one I had a stupid idea – why use simple static sprites if I’m using Unity? So I ventured to recreate my first characted (pirate ninja skeleton), put it on simple 2d mesh… then skin it and rig it to the bones. I’ve wasted a LOT of time on this, result is ugly (kinda hard with the texture I’ve started to do good mesh and skin it so it can move without serious distortion taking place), but I should have expected that – I have all the theoretical knowledge about this stuff, I wrote it from programmers point of view, but… using 3ds max for anything else then checking on some artists work, creating super simple meshes and importing/exporting here and there, is something I just don’t have much experiences… Well, I now have some, but it took me too much time, especially considering results. But at least I’ve learned / practiced something new.

(First sprite I’ve made before switching to animated chars… it’s static, but it looks better :/)

So… I’m mostly happy with my entry (and hope someone will play it , about the only thing I’m sad is that I hadn’t time to implement save and load… never wanted to do it, other then maybe checkpoints on the level start, but since I had just one… Problem is that doing serialization in Unity for proper save / load is not that easy and it takes some time to do properly… time I knew I won’t have.

Anyway, I’m glad I had time to participate in LD and looking forward for another one (and Global Game Jam next month). Although it can be brutal… it’s fun (especially when compared to “normal” crunches on commercial stuff).

PS: going to rate some games before I start working on another game (I have three months to finish one commercial design), so if you’ve made something else then platformer (I seriously hate those), drop me a link

My entry page

Playable version (unity web player)

Link to my blog

Here’s the first in my (maybe) three part series of postmortems for my game ZERO2. Of course, I’d recommend checking the game out first before reading so here’s the link:

http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5821#LD48

GOALS

This is my second time participating in Ludum Dare, so coming into it I was hoping not only to simply make a game, but to outdo my previous effort. My LD21 game (NO ESCAPE [pictured below]) was fairly well received for its graphics and audio but (as many commentors noted) suffered from three main flaws:

1. ‘Not A Game’

Well, that’s a little harsh, but in some ways maybe true. I hadn’t even attempted to program anything for years going into LD21, so I decided on a concept that would require the bare minimum of coding. The result ended up feeling more like an interactive movie than a proper game, with little variation between playthroughs, and no real challenge or obstacles.

2. ’40 MB WTF?!?!’

While I was working on it the last thing on my mind was how big the .swf was going to be. Turns out it was really big – 40 MB big, which in the world of Flash games is humongous. This led to a painfully slow preloading screen. This wouldn’t be so bad if it wasn’t for this next point…

3. ‘Press Space Bar for a Minute Then it’s Over?!?’

Yup, despite all that loading time you were getting only about a minute of gameplay. And while I generally go for quality over quantity, I think it’s safe to say my game simply didn’t have enough content.

'NO ESCAPE' - My entry for LD21

SUCCESS

So, with these goals in mind, how do I think I did with my LD22 entry?

1. ‘It’s A Game This Time I Swear!’

This time I based my gameplay on the point-and-click adventure style popularized by games like Myst in the early 90′s. Although this type of game still has moments that feel a bit like ‘interactive movies’, it still definitely feels like a game. You solve (admittedly simple) puzzles, collect equipment, and have to find your way to the end. The great thing for me, is that this type of game is relatively easy to code – and I was sort of thrilled that everything worked as expected almost right off the bat.

2. ’3 MB OHH YEAAAAHHHH’

I was SO concerned about the file size of the final .swf that I took every imaginable step to keep it down. All of the image files are as compressed as I could get them without showing too many artifacts. I also really restrained myself in terms of adding animated sequences to the game, and when I did add them I tried to be very conservative with the frame count.

3. ‘It Takes Slightly Longer Than a Minute to Beat!’

Ok, it’s still a short game, but I really busted my ass to create as many environments as I could so that the experience would have some ‘girth’ to it. I think these types of games are successful when you can really drag the player into the game world so they can feel that sense of exploration and being lost in an unknown environment. While I think this game could certainly be much longer, I think it’s long enough to get the player ‘involved’ with the world and the story.

FAILURE

While overall I think I would describe the game as a success, there are certainly ways it could be better:

1. Too Easy

Right now the game is quite simple – almost all the puzzles are solved in the same way: you need some object to proceed, find said object, proceed. I wish I could have programmed some more complicated stuff in (for example I had an idea for a ‘circuit breaker’ style minigame to get one of the elevators running) but every additional layer of complexity would have severely increased the time spent coding.

2. The Sound of Silence

While I’d like to think the environments convey a potent atmosphere with the visuals alone, the truth is that sound probably would have made the experience twice as good. In fact, I was thinking about sounds all the way through the development process – unfortunately, I just ran out of time!

3. Too Short / Not Enough Replay Value

Ok, after patting myself on the back for making it longer than my LD21 game, I still think I could do better. Part of that could be achieved through replay value. And while replay value for puzzle/adventure games is always hard to achieve, I had a pretty good idea to implement an ‘Investigation Rating’ at the end of the game so that players would potentially want to go through it again and try to examine everything in the game for a 100% rating. You know, basically achievement hunting! Of course, I’d need to add a lot more stuff to investigate…

CONCLUSION

Despite these ‘failures’ I still feel pretty good about my game, as I think overall I was able to achieve my goal of outdoing my LD21 in almost every way. The other good news is that I feel I’m in a pretty good position to expand upon and improve the game without needing to completely redo it. Whether I choose to do that or not…well, we’ll see.

I haven’t said too much about the graphics since I’ve decided to save that for another post. If you’re curious about my process though stay tuned for my next postmortem, in which I’ll do a step-by-step breakdown of the creation of a single scene.

Ok, I guess everyone here packaged and submitted the game already, but as I was trying some of them out, I thought that it’s a good thing to post some advice on how to make your game work out of the box, thus getting more views and plays. Consider repackaging the game if some of the below points apply to yours!

How to have your game working out the box:

• First of all
  • Listen to suggestions, people will surely feedback if the game is not working for some reason! Check comments, come to IRC and ask if the game runs fine.
  • Make a gameplay video and include it in your game links! Even if someone is unable to play, he can give you some ratings (e.g. Graphics and Audio)!
• Downloadable games
  • Subdirectory - Include a directory with your game files in the downloadable archive, it makes unpackaging way easier!
  • Decrease size – make sure you remove all redundant files form the archive!
  • File name – avoid using file names such as ld.zip, ld22.zip, alone.zip etc.
• Java
  • Make a web applet! Link to Daze’s web applet snippet
  • Or, use Java Web Start
• AS3/Flash/HAXE/Stencyl
  • Include classid parameter when embedding!
  • Add a preloader if your game is over 1MB!
• Love2D
  • Create Love executable!
  • Keep the original .love for Linux and Mac users!
• Python
  • Use Py2exe!
  • Keep the source inside too!
• C#/XNA/Mono
  • Provide links to framework you used in the game description!
  • Framework links: XNA 2.0, XNA 3.1, XNA 4.0, .NET 2.0, .NET 3.5, .NET 4.0
• JavaScript/HTML5/WebGL
  • Make sure your game works in different browsers! At least Firefox and Chrome!
• C/C++/Native
  • Make sure you included all the dlls and that these are right version!
  • Add links to redistributables: VS 2005, VS 2008, VS 2010
  • Use static linking if possible!
• Ruby
  • Use OCRA to package your game into executable!
• Game maker
  • Submit the game to Yoyogames sandbox! It will allow people to play it online.
• Linux
  • Use ldd to pick and package correct libraries with your game!
• Mac users
  • Use WineBottler to play most of the windows entries!
• Read DO’s and DON’Ts list by Mathias Zarzecki!
• “[...] Damn. I spent ages searching for such a place. Ah well. I’ll do it next time.” SUPERBAD!
  • Do it now! That’s what this guide is for!

If you run across anything annoying regarding packaging, or have a piece of valuable advice, write it in the comments, and I will snip it to the list!

Volcanox was a lot of fun for me. Although a programmer, game development is not something I normally do. Additionally, it was also a test of the programming language MoonScript. I wanted to see if I could write a game in my own programming language.

The results, I thought, were pretty good. By the end of the competition I had something playable. I even had time to write music and insert sound effects.

If you haven’t played the game yet, you can do so here!

The Process

For this project I started with plain LÖVE. I figured I could get a foundation together. Even before the theme was announced I was pretty certain of making a platformer. It’s something I’ve never done before but I implementation ideas in my head. The first night was all writing collision detection code and movement. This was the one thing I was certain about writing, so I plowed through it. I even had time to write a map loader

I implemented an algorithm called Uniform Hash Grid, which let me subdivide my collidable objects to reduce the number of checks per frame. This worked very well, I was able to create a huge map with no impact to runtime performance. (It had a little load time though, which I think I could improve if I had more time.)

My map loader just loaded a bitmap where pixels represented collidable tiles. I did this to avoid having to use any real map editor tool. In my code I assigned colors from the map image to be actual tile sprites. This was my first map:

From there I just added gravity, and assigned a jump button and I had a working platformer.

I spent some time fooling around with ideas. I wrote a basic particle system which I later used for all the shooting effects.

The next day, after waking up I decided to tackle something I thought would be very hard, drawing sprites. I put together a simple (and awful) animated player sprite:

After that though I kind of lost sight of what I wanted to create. I had a working system, but I didn’t know what kind of game to create. I  got lazy and went out to a coffee shop with friends. I think this was unavoidable because I needed time to think. After that I decided I would have shooting and enemies so I started coding bullets. I added minor things and created a tile set. Things were looking okay but I still didn’t have a game mechanic.

On the last day the name Volcanox finally came to me. I coded up until 1 hour before the deadline adding simple game features like title screen, and winning and losing conditions. I added one enemy and wrote the AI. I had no experience writing something like that so it came out very unnatural. I decided that because the game was so simple, I would make the enemy spawning very aggressive. This actually made the game (annoyingly) hard. I expanded the map to make it huge and have lots of enemy spawners.

Here’s the final map: (yes that’s a volcano)

The last hour I rebooted into OSX and recorded some music on my keyboard, and quickly got some sound effects out of bfxr. I submitted my game at exactly 6pm.

The final submission’s sourcode is on GitHub.

Review of MoonScript

Part of this project for me was testing how well MoonScript would work for game development. MoonScript is a language that compiles into Lua. It’s a slimmed down syntax that adds a lot of sugar. Things like classes, list comprehensions, and a lot of other useful stuff. It works great with LOVE.

I wrote 1534 lines of MoonScript, and it compiled into 2880 lines of Lua. Pretty cool!

I heavily used the class system, and the inheritance it provides. It allowed me to quickly scaffold objects in my game. I think if I were writing Lua, a lot of time would be spent designing my object interaction. In that regard, MoonScript was an excellent tool to use.

I strongly recommend it for game development.

What went right

• Using MoonScript
• Using a bitmap and gimp as my map editor
• My tools all worked well together

What went wrong

• Didn’t test on windows, got report of people having issues after submission
• Didn’t know what I wanted to make in the middle of the comp
• Didn’t have any foundation code, had to focus more on getting code to do basic stuff instead of adding game features and polish.

Once again, If you haven’t played the game yet  you can do so here!

I had a lot of issues since the end of the 48h challenge and the game wouldn’t work correctly for obscure reasons. But now it does.

You can play it here: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=6638 (I strongly recommend Firefox to play it best online)

Gameplay video!

Here goes a postmortem for my first LD game, Lighthouse Keeper. I started working on the game on Saturday afternoon and finished almost on the deadline.

This was a great experience even if my game didn’t turn out great

What went right:

• Managed to submit a game, even if it’s horrible, buggy and way too hard.
• The art is ok in general terms (for programmer art!), atleast better than stuff I’ve done before.
• Using stuff I’ve worked with previously: C++, SDL, OpenGL.
• Simplifying my original idea so I could finish in time.

What went wrong:

• The game ended up being too hard. Should probably tune the wolves and player attack damage and/or add more lives to the player. Actually you started with 5 hearts but decided to drop to 3 just before submitting the game.
• You can walk on water! Didn’t have enough time and decided to work on other stuff instead of adding collision detection for staying on the island.
• I spent too much time trying to figure out isometric tiles when I could have just render a rotated quad for the island (pretty much did this to save time).
• The code is horrible, there’s repeated stuff and it’s messy. This is because I just started coding right away with no planning or thinking before.

Greeble is an HTML5 game where you are the captain of a crashed spaceship. You are ALONE but need some help to survive. Collect the cryo-keys to activate the stasis pods in order to free your friends.

What went right?
Was very familiar with my tools, both engine, language and art creation pipeline. The amazing JAWSJS game engine was a breeze to work with. Had a very easy time making the art, since my level editor was just photoshop. Enjoyed screenshotsaturday, twitter and google+ as a means to stay motivated. I did well in the time-management arena, and planned ahead of time. I used placeholder art during programming and coded everything first in an ugly room with rectangles for characters. Only after the first day (when all coding was done) did I dive into the art, so I had tons of time to make it real puuurdy. I spent 75% of the time on the art and was feature-complete the coding by noon on Saturday. Total time spent on the game: 14 hours.

What went wrong?
Ran out of time before I could add sound effects. No user instructions or intro. No GUI. Had to cut features and simplify to finish on time. Got a bit stressed about it on the last day, racing to finish. Drawing the level took more time than I predicted. Overall, had TONS of fun regardless.

About the game:
Features pixel-perfect, non-grid platforming, bounce-pads, transparent glass tubes, a fun retro “scan line” effect, silly AI followers and A KITTEN. Your objective is to navigate to the exit where you will be rewarded with a trampoline party!

→→→→ CLICK HERE TO PLAY! ←←←←

Use the ARROW KEYS to move around. Try to find a way to revive all your friends (including the hidden secret kitten, which signifies my enthusiastic participation in the “kitten challenge”) so you can all bounce on the trampoline at the end.

I had so much fun making this game. I even had time to hang out with friends, go for a hike, and decorate my house for the holidays! There is a lot of room for improvement but overall I’m really happy with the final product. Created using ippa lix’s wonderful jawsjs game engine.

The word “greeble” comes from the original Star Wars ILM special effects artists who used the term to describe generic “tech” bits and pieces that adorn sci-fi hulls. There are thousands of greebles in this game’s level art.

How it was made: I drew two “techno” textures as the base texture for all the world platforms (one brown and one silver). These patterns were covered in “greebles” (panels, buttons, wires, lines, etc.) In photoshop, I made opacity maps for each and turned everything transparent. Then, I drew the game map itself by drawing black and white pixels on the alpha (opacity) channel so that certain parts of these materials would become opaque. An effect filter that added a little emboss to the edges completed the look.

In the game engine, the entire world map is one gigantic .PNG image, which is layered on top of two parallax-scrolling background tiles (set to move slower than the foreground). The retro “scanlines” effect is merely another overlay image that sits on top of everything.

This is the entire map image I drew, as used in the game (click to zoom in):

… and this is the scanlines overlay I created:

Making “Greeble” was very inspiring. I now have an HTML5 platformer game engine that allows me to create freeform worlds in photoshop. No tiles or level data files required!

→→→→ CLICK HERE TO PLAY! ←←←←

Ludum Dare is so much FUN. It is amazing what you can accomplish in a speed-coding weekend.

Yay, Dread Maze is fun. Happy days. Mostly writing this so I have at least one journal entry.

Isn’t it sad that the amazing winner of the BEST COMMUNITY award last time wouldn’t have any entries at all? :’-( At least I made a game. It was my dad’s birthday and I am home for the holidays, so that I found any time at all is pretty surprising.

http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=7984

My first time trying LD and it was a great learning experience as well as being fun and creative! It was kinda cool to just sporadically start programming random things with no base code (although the source code is a minefield of awfulness) and getting to draw whatever I really felt like – setting it as a dream gave me some artistic license with things, for example you don’t usually get whales in space (or oceans in space for that matter).

What went well

• The theme. It made me think about games slightly differently, I usually like platformer-type action or puzzle games, but I had the opertunity to think of something a little different.
• I got the art done as I went along, started off with the character and some stars, then as I got ideas I just scribbled out some more (with a basic idea of where I was headed)
• The code was not very nice but got the job done, was very fast to come up with on the spot. The paper concept for the player was a half-way snake type thing, instead of cells in a ‘rope’ rotating they stayed axis aligned, giving the paper vibe (along with the art).
• I like the way it feels, weird and dreamlike. I always think of dreams as a lonely place – people will be often be in dreams, but they aren’t really there.
• It looks a little sad from the outside, which matches the ‘alone’ theme, but my view of the end is more cheerful – but I’ll leave the whole thing open to interpretation.
• I didn’t give any instruction as to what the player is supposed to do, because they can do whatever they want. There is a purpose and end to the game, but I think games are about an individuals’ experience, and I thought it was cool to just let people float around in my little dream world and just check it out, move things around, do whatever they want.
• Working over a 48 hour period wasn’t as bad as I thought, next time however, I will be more prepared and bring something a little more solid to the party.

• SOUNDS! Total lack of them. My main regret. I didn’t really know how to load and use sounds, didn’t know of any libraries or how to use OpenAL and didn’t really have the time to learn so much as I went along. Probably gonna look at SDL for the future.
• Images, as I had zero base code to start with I forgot (after not programming for PC in a while) I didn’t have any image loading libraries, so I found a nice lightweight lib called SOIL, which was really simple and worked perfectly.
• It wasn’t exactly polished to a high standard. The code was inefficient (and sloppy), there was no reset and no title (although a title probably wasn’t necessary).
• The code should compile on Linux and Mac, but I don’t have a Linux install and didn’t have the time to get it running on my Mac.

Overall, a positive experience, definitely going to come back next time and give it another whirl.

Hello everyone!

A little post to explain how I create levels in Run Away.

All the system is based on pixels.

First I got my set, here is my Hell set.

Then I create on my paint editor a new image where 1 pixel is one tile in the game (classic).

To choose which tile to use, I work on the Red color, Grass will be 0, Water will be 100 …

Then I add foes, bonus, checkpoints  and tuto points with Green color

And to conclude, the Blue allows me to select a specific one. For exemple I can chose the foeI want to spawn.

Here are my maps

For the last one, that’s what we have in game:

In the game, the loading is really static, I could have added information on the Alpha of the first pixel to store data on the level for exemple the set (if it’s forest or lava) and the id (to know the order).

My local values for each colors.

int GrassRed = 0;
int WaterRed = 100;
int PanelRed = 130;
int EndRed = 150;
int SpikeRed = 160;
int BossWallRed = 170;
int DefaultRed = 255;

int SpawnGreen = 100;
int CheckPointGreen = 200;
int FoeGreen = 150;
int BonusGreen = 160;
int TextGreen = 170;
int ShadowGreen = 180;

int FishBlue = 100;
int BirdBlue = 101;
int SawBlue = 102;
int HalfSawBlue = 103;
int HalfSawLeftBlue = 104;
int BirdNoCollideLeftBlue = 105;
int BirdNoCollideRightBlue = 106;
int SawNoCollideTopBlue = 107;
int BossBlue = 120;
int BossDamageBlue = 121;

//int SpawnSideRightBlue = 255;
int SpawnSideLeftBlue = 254;
int SpikeRightBlue = 254;
int SpikeBottomBlue = 253;
int SpikeLeftBlue = 252;

Thanks for reading, if you want some other little post on how my game works, please comment

The Current People from IRC!

Okay, as many of you (IRC) know. I have been developing an RTS/Dungeon-like/TDS  for a bit of time, and a big point of the game isn’t the game in it self. It’s including people. That’s why all the in-game playable Characters are real people from the IRC.

As you see in the image (UP), i have included a few. And this is your chance to be a part of it

When you’re in the irc/Talking to me in the IRC. you’ll have an chance of being made into an Character/Trap/Boss/Enemy in the game.

-Cell

Thanks to the people who is already in the game

(Bigger version of the image over: http://dl.dropbox.com/u/34397004/TheCrewOfTheUnderDome.PNG )

While I’d love to see even more ratings on my own game, I feel like I should take this opportunity to callout some games written by all of you guys that really caught my attention :

Embers – by NMcCoy

Very exploration-based, but with a “listening” mechanic that is visually wonderful and a completely creepy and compelling vibe.  The ending is existentially terrifying.

The End – by kebabskal

This is one of those games that really pours on the atmosphere with great graphics, and possibly the single best music track I’ve heard yet in the competition.  It’s not perfect, and there are plenty of things that could be improved, but it’s more than worthy of a look!

Alone – by Jesse Freeman

More of an intro than a game, but the design aesthetic and the poem make for an impressive piece, and the start of something grand, even if the current LD entry is a bit thin on gameplay.

Head South – by MurrayL

A 3D exploration of vast, beautiful landscapes, meeting people who are just like you… all alone… Why don’t you help each other?  Interesting question…

Solus – by morganquirk

The sprite graphics on this game are jawdroppingly beautiful, which is impressive given how dark and gritty everything is.  Note the white noise overlay on top of everything, the creeping pace, the awesome sound effects, and the tense, claustrophobic action.

It’s been over a day, and I’m still pretty winded from LD. Look, I made some game about clones, http://dl.dropbox.com/u/43348544/LudumDare22.swf, and that was a really fun idea to play with. Messed up a whole bunch, learned a lot, and definitely enjoyed every bit of the experience.

Ahhh, I also like pictures:

What went right:

1. Learning how to program two years ago and making plenty of random gameplay prototypes for fun. One of those prototypes was a city populated with your former selves–which was one of the biggest inspirations for my concept here. It seemed to be an interesting angle to play on the theme, and I really wanted to flesh the notion of combat in that idea out. Knowing exactly what I wanted to do pretty much the minute the theme was announced let me hit the ground sprinting.

2. Programming faux-AI. If you’re going to have clones with guns, it’s no fun if they’re turrets–that was the problem I ran into halfway through my programming. I didn’t have the time to devote to clever AI, and I didn’t think that a fancy 2D shooting AI would have been worth it. I ended up doing a super simple idea–randomly move either left, right, or up–that just worked. Which, in retrospect, was by far the part of my game I am happiest about. ^__^

3. Postings updates of my progress during the compo. I didn’t do post anything during my first Dare because I’m a hermit, but I really wanted to for my second one. I’m glad I did too. Updating the interwebs with my progress was one of the biggest sources of motivation.

4. My computer didn’t explode. I’m not sure whether most people have this problem, but electronic things I touch tend to like to explode. Went through three different laptops in the last four months. This one is a repaired version of the first, and it popped open a blue screen of death the day before the competition. I took a gamble not using subversion and a backup laptop with everything installed just in case, but I figured that I had bigger concerns if bad things happened.  It didn’t though, and I’m pretty thankful.

5. Taking plenty of breaks and sitting next to my refrigerator. Mmm… so much delicious orange juice. I couldn’t have done it without you. Spending a lot of time away from staring at a computer screen to recharge my mind definitely helped getting back to a lively pace.

What went wrong:

1. Attempting last minute sound effects and music composition. If a person like me can’t do digital composition to begin with, he probably shouldn’t try to learn how to with new tools during the last three hours of the compo. I’m sure I also made the process of picking and implementing sound effects way more complicated than for smarter peeps. None of my audio work in the last three hours made it, and the game ultimately only had a sampled drum beat I used as a placeholder/last resort background tune and no sound effects to speak of. Looking back, I should have definitely walked through the audio development process beforehand.

2. Spending a tad too much time on creating content. It’s one of my pet peeves about myself. During my first Dare, I spent probably half the time designing, creating, and implementing a superfluous amount of upgrades that just ended up overwhelming players. I consciously toned it down significantly this go around (only a quarter of the time), but I could have added a lot more feedback/agency to the gameplay if I had a few more hours.

3. Not addressing the theme/mood in the game. I thought that the concept itself would be enough to speak the theme, but not too many others did when they played it, lol. I should have added narrative elements to really push my concept through and what’s happening behind the scene. As it is, it might as well be any other shooter with bouncing music.

4. Not playtesting it beyond the first couple of levels or with a fresh pair of eyes. After staring at a game for hours (especially only staring at the first few levels), I began to really notice the subtle differences between the player character and his cloned enemies. Unfortunately for new players, distinguishing them was a lot more difficult. Biggest regret this LD: not playtesting.

That’s it. Thanks for listening. I hope you had as much fun this LD as I did! Cheers.

Well I learned a lot from this.  First of all, the controls are much less self explanatory to the people playing it then the people programming it.  And also you should probably have it switch to the first weapon automatically, cause nobody’s gonna figure it out that they have to press the switch weapons key to get it.  Sorry to everyone who downloaded it and couldn’t play, that was my bad.

Lesson learned: don’t leave the core gameplay and puzzle initiation algorithm for last. Argh.

The game was supposed to play a little bit like Pipe Dreams. You’re the last engineer on an otherwise vacant starship, the ship’s AI is taking care of navigation and weapons, and you need to make sure the shields, weapons, and life support stay powered under enemy fire. The board starts with a reactor on one side, the ship’s systems on the other, and a bunch of power routing tiles in between. You reconfigure the grid by rotating tiles to provide power to the systems that need it.

What went well

For the first time ever, the graphics came together really well. They were a little time-consuming to make in Inkscape because in between sessions, I forget everything I know about it. I was happy to finally have a game with a consistent graphic style that wasn’t offensive or straight outta MS Paint.

I got the tiles clicking and rotating pretty easily. That was a great confidence booster early on. The background game simulator that powered the ship’s systems and dealt damage to its shields over time went together really well, too. Adding scripted events is as simple as adding a hash with an ‘enabled’ flag, an interval in milliseconds, and a fire() method that performs the game state update and requeues itself.

The Android WordPress app was lovely when the LD site wasn’t under load. Rather than fiddling with screen shots and files and the web UI, I could pull out my phone, snap a pic, and post. Awesome.

What didn’t go well

Eating, sleeping, staying focused, and holiday things that will now turn into last-minute nightmares. And then there’s the technical bits:

The Problem

Given how hard it is to programmatically find a smart route through the tiles between each of the three ship systems and the reactor, I’m now thinking that the Tetris-like pick-n-place behavior may make more sense than starting with a filled grid. I thought the filled grid would be more interesting, but crawling the tiles to find each system’s connected power grid is tricky. Two systems can’t use the same tile. So who gets to use it? The first grid that’s fully explored? That was my first strategy, and it lets one well-connected system take over the board. Maybe the systems have to explore the grid in parallel, each acquiring one tile at a time before the first can acquire another.

The Result

I was really looking forward to completing my first LD. I figured I could cram a bit into the submission hour, even. And then it was too late. I had a bunch of nice-looking tiles that rotated when you clicked them, and I couldn’t figure out why they couldn’t see their neighbors. Heartbreak and disappointment.

Since this is also a sort of prototype for a part of a larger game, the plan is to see it through to some kind of playable state. The holidays may torpedo that plan.

(more…)

Hi! I want to learn procedural level generation and some simple pathfinding( for making objects wander randomly for example). I would like to ask a favor for those people here to suggest me games(from this Ludum Dare or others) so that I could study the code for doing this things. I’d also like to learn how to make cut scenes so add these games too. Thanks a lot!