Vote here

My game is a minimalistic puzzle game where we tell a history of a little boy called Ted, trying to make a better world around him with the imagination.

We receive in our page great reviews, and the most good thing is the surprise of the game be so polished. It’s because we fix in the idea that the game have to be something minimalistic at all, not only in the graphics, but also in the gameplay, and even in the story.

(more…)

During the compo, I ran into a bug that made two pushable box (which should collide and stop) run over each other.  I’ve been trying to fix that, but now nothing makes sense anymore… The gif bellow can better show it (and also show a new stage! ).

As you can see, the first time it collides perfectly… but the second time (which should be the exact same situation), they overlap each other… One thing that I was able to notice (after dumping some frame-by-frame information to a .txt file… >_<)  is that there may be a relation with their order in the object list (FlxGroup, if you’ve ever used Flixel).

Ok, this gave me a (stupid) idea. I’ll check which is the left most one and pass that as the second object to the collision method (FlxObject.separate). I’ll post soon with results. Obviously, it didn’t work. ¬¬

 

Now that the weekend is over it is Post-mortem time.

 

TL;DR: I managed to create a fun game by taking a well known game mechanic and adding a twist to it. Unfortunately, the lack of proper feedback put a steep entry barrier into it.

Conception phase

On Saturday noon, when I learned about the theme, I wasn’t sure that I would participate at all. I had been brainstorming some ideas for the themes in the final voting list, but didn’t pay too much attention to Minimalism because I wasn’t particularly interested. It occurred to me that it could be an excuse to be lazy, and there was the risk of having most games resemble each other (…well, I’m happy to say that in general the compo entries I’ve checked so far have proven me wrong; it’s amazing how many different ideas can stem from a simple theme). Of course, Murphy’s law stroke back and that happened to be the final choice.

The first ideas that came to my mind consisted on just picking one of the concepts from the day before and reduce graphics to its bare minimum (yup, I’m lazy). However, after thinking that most people might follow that approach, I started thinking about what minimalism really means: to remove everything non-essential until you end up with the core of a particular piece of work. In games this can  be achieved in different areas, either by themselves or as a combination: graphics, sound, narrative and, of course, gameplay.

In many current games the main concept hides behind layers and layers of superfluous functionality: stunning visuals and excessive feedback, over the top GUIs, tutorials, meta-game features,… Sometimes they do enhance the experience, but in some cases they can also obscure a set of mechanics that already work perfectly well by themselves. So I decided that for my entry I would pick some well known gameplay mechanics, bloat it with unnecessary stuff, and then strip them from the game as the player progresses until you got to the “essence” of the game. At first I thought about the classics: Tetris, Pacman, Puyo Puyo, Match-3 games,… possibilities were infinite. However, I figured that I could at least try to add a twist to them, or imagine a new game concept that fit the theme by itself and at the same time was fun to play. This way, even though I wasn’t able to implement the “non-minimal” feature set I would have a decent entry.

I ran some searches to find some inspiration and then I ran into this image:

When I saw it, I felt that familiar “click” of inspiration, and the match-3 with ring rotation  as one of the possible movements just came naturally. Gameplay was certainly minimalistic, and so was the art style.

For the sound I thought of Simon, so there we go…now we have minimalistic audio, too…


And you can check the final result here.

What went right

It’s fun!

I know I’m not the one to judge, but people seem to really enjoy the game from what I get from the entry’s comments (Thank you all!) and from friends who have tried it, and I think this is the most important thing, besides being really encouraging. When I was coding, sometimes I’d run the game to test some new feature or reproduce some bug and then would find myself playing it longer than necessary, which was a promising symptom. Still, I wasn’t sure if people would like it or if they’d find it too casual, or boring. It seems they do enjoy it =)

Start small and modular

This makes planning and prioritization easier. Given the Ludum Dare’s tight time constraints, this is fundamental, and it’s much easier said than done. For this edition I managed to “split” the concept into two: the basic game, and then the “start excessive, then simplify” idea, which didn’t make it. At times I resent it a bit that I had to drop the latter: I liked it as a means of criticism of certain tendencies on games today (I may sound a bit snobbish here, sorry :S), but if I had decided to go with both at the same time I probably would have failed at both.

Not too many bugs

This can be a secondary effect of the game being simple enough, but the match and possible movements calculation logic relies on lots of array checks, leaving the door open to “off by one” errors that can show up in the game with unpredictable results. I’m aware that there is at least one of such (or it may be due to the logic in charge of the blocks state transitions after a match), but it is quite infrequent. In general, people have not complained about bugs, so I’m quite happy with that (of course, those bugs have an arrest warrant on them, so I’ll try to fix them)

Language choice

This would have applied to the “What went right” of my entry for LD25, Conquer All The Castles!, if I had written the post-mortem for it (procrastination, the root of all evil), but as that was not the case, I’ll state that here. The game was coded in AS3, which despite not being my cup of tea had two advantages compared to C++, which I had previously used for It’s evolution, Baby!, my  first LD game: the first advantage was that it was easier to get things done and display them on a screen. On C++ I generally use SDL and OpenGL, but I don’t use any higher level graphics library (and I haven’t coded any of my own yet), which means I have to spend lots of time in graphics programming rather than gameplay.
The second advantage is that you may distribute it easily via web. No zip downloads, no installers, no platform issues (generally), no dependencies and no annoying external redistributable packages required (We could argue about using GCC, or maybe even developing on Windows vs Linux, I know).   This grants you a lot more visibility, as the game is more accessible and people can play it immediately.

Easy to evolve:

The idea is really simple, and there are lots of opportunities to expand on it (although this means that we’re straying from minimalism )You can always improve the  visuals, of course, and add some eye candy, but music and  sounds, and evolve the gameplay in lots of ways (for example, allowing horizontal swaps, adding a special ability to “sacrifice” a ring, further victory conditions, etc, etc)

What went wrong

 

People have a hard time figuring out what to do

Essentially, this:

The fact that I needed to add an external tutorial for a game with only two movement types speaks ill about the feedback the game visuals provide, or maybe even the controls. I’m against in-game tutorials as a general rule (and in this case in particular, I felt that it went against the theme), so I decided not to add one. This is OK, but if you choose to do this then you must count on the game itself teaching the player to play it, either with sound, animations, intuitive controls or any other type of means. I made the fatal mistake of assuming that it was easy enough as it was, and anyone would get  it instantly, or after a short period of trial and error. That assumption is indirectly taking for granted lots of things: that everyone is equally familiar with the “match-3″ mechanics and that all those games are played the same way (for example, clicking on blocks vs dragging), that the way people perceive the game is always the same, which is not true, etcetera.

Lack of play test.

The above mentioned problem could have been solved easily if I just had some more people play the game while I was developing it. It’s actually interesting seeing people play by themselves, as you can see where and why they get lost, and you can spot pitfalls that have slipped unnoticed. After seeing some people play I discovered how much the spatial  perception of the scene differed from one person to the other. Some people would see the square as a 3D box, while others saw it as concentric plates.

This actually affects the way they think the game is played, and raises an interesting question: could people be less confused if for the starting levels I had used circles or polygons with a larger number of vertices instead of squares?

Prioritization issues.

Despite I’ve already talked about this in the “What went right” section, I must also drop a few lines about it here. Following with the theme’s motto, “less is more”, so it’s better to have the main, most important features well implemented and possibly leave out some minor details, no matter how simple they are. For example, the time spent for the random tips at the top of the screen or the addition of the “timeless” mode could have been used polishing the controls, testing if the level progression made sense,…Yes, they’re simple and they may not take more than a few minutes, but if you keep adding things up you end up deviating from the main goals.

“Feature showcasing”.

This is related to the previous point. Of course you don’t want to throw down work you’ve done. At times, though, you must stop and rethink if it’s really sensible to add that here or there, or if it just detracts from the experience. Again, I must use the “Timeless mode”.

Lack of polish.

Besides the visuals, sound, etc, balancing comes into play here. I haven’t been able to move past the fifth level (a square with a larger number of rings) so far, and I’m not sure if someone’s managed to do that, or whether it’s actually possible at all. In the end it all adds up, so as I mentioned in the “Playtest” section, perhaps having a proper progression where you decide that a level with (X vertices, Y rings, Z matches to complete and T seconds) makes more sense if played before another one with, say, (X + 3 , Y, Z + 2, T – 10) could help people have less trouble to understand the mechanics.

External side effects

As a result of spending two days in front of a laptop screen, my neck has resented to the point that I still feel as if I had needles piercing through it due to muscular strain. This is a combination of my terrible postural habits and the long work hours without any kind of rest. To top it all, I lost several hours of sleep. At that moment it’s not important, but then you go to work like a zombie and have problems focusing.

Conclusion

Despite the obvious mistakes (Or perhaps even thanks to them, to some extent), I’m quite happy with the end result, to the point that I’m considering to keep working on it, and even maybe a mobile/tablet port.

These would be the next steps:

• Rotation animation. This is a MUST, as it would probably make the game A LOT more intuitive.
• Bug fixing.
• Better match animation/visuals, specially for chains.
• Improve overall feedback.
• Experiment with controls. Maybe dragging might do miracles for rotations, and probably for swaps as well. In the best case, give the player the ability to choose the input scheme that works best for her.
• Add game states, maybe game modes (for example: challenges with fixed levels, convert the “timeless toggle” into a game mode,…)
• Better sounds, better graphics, perhaps even music.

And this is it, I think that I’ve bored you enough already. Thanks to everyone who’s bothered to read all this wall of text, and specially, thanks to everyone who has played the game and given me suggestions on how to improve it. I hope you enjoyed it and I hope that I can keep the motivation to work on it and make it much better.

 

So I didn’t even know I was going to be able to participate in this Ludum Dare because of other things going on, but I knew I’d be travelling all day on Sunday and I happened to get an idea for a very small game on Saturday night.

My entry was created over the course of 8 hours and involved traveling through four states, on three different types of trains and one bus!

I am so glad the theme was one which supported a heavily constrained timeline.

 

Use the left and right arrow keys to avoid the blocks!

You can play Squeezed Out in your web browser and it has online leaderboards if you’re into competition with other players.

Here is the link to the compo entry page for feedback or voting.

I just finished and submitted my game. I’m pretty happy with how it turned out.
Play the game here.

 

Combining both the familiar appearance of the common potato with the radical contrast of sheer empty space my work explores the rift that exists in our post agrarian society.

The gestalt appearance of this tuberous crop, familiar to many as a common food can serve as a metaphor for the existential struggle of existing in a post industrial society.

The apparent contradiction of audio poetry references the numinous ‘eyes’ that cover the surface of the food, transposing eyes and ears to provoke introspection.

Please play and rate.

Finally finished the five first levels. Still not much of a puzzle, but it’s something.

Move with the arrows, jump with ‘x’ (if you have the powerup) and restart with ‘r’ .

Play it here!

Any feedback would be greatly appreciated!

Thanks! =D

I’ve already loaded the level editor with every (I hope) object, and some of them are functional! Just gotta polish the graphics, make sounds… and create every goddamn level. >_< Since it’s going to a puzzle, that only make things harder… >_<

Oh well, I hopefully can do this. xD

It’s been over twelve hours and I’ve only now finally managed to get a working A* pathfinding thing in Flixel.

…I do not have high hopes.

I’m entering Ludum Dare 26.

Tools and stuff I’ll be using:
> FlashDevelop
> Flashpunk
> Tiled
> GraphicsGale, GIMP
> bxfr
> goldwave
> Musagi or cgMusic

This is some base code I’ll be starting with. It’s mostly just for loading maps from Tiled.
Download

Hi all! This is my first Ludum dare and I really hope that I can finish the game in 2 days. It will be a pixel game in oldschool style

I will be using FlashDevelop as my code editor, Flash CS 6 with Pixel Tools v2.0 plagin  (or maybe Photoshop CS6) as my drawing tool and Bfxr as sound editor. Aslo i think i will be using WolframTones for creating ambient sounds.

I really like Afterlife theme and expect we will see this one D:

Good luck to everyone! I hope we will get a great weekend!

We are a team of two and this will be our first Ludum Dare. Our previous projects have been small in scope but we hope Ludum Dare will challenge us to create something exciting with very little. Our work will be recorded and put up in our post mortem in the form of a timelapse video. Starting in the middle of Saturday due to our timezone is also going to present a massive challenge.

Country: Australia

Language: AS3

Libraries: Flashpunk

IDE: FlashDevelop

Graphics: Photoshop and Opengameart.org

Level Design: Tiled

Sound Effects: BFXR

Repo: Bitbucket/Mercurial

 

Our last project can be downloaded and played here:

 

Also I made a short warmup vid showing off my workspace. Also proof that the timelapse is going to work!

http://youtu.be/YxDpiX1lAlA

If your answer is POTATO, then you can check out my tools for making your development easier.

What are you selling?

First is Jorjon Resource Maker, which will enable you to quickly embed all your images / fonts/ mp3 you need for your game.

Don’t write a single [Embed] ever again.

You don’t even have to worry about it, just use my *.bat file and double click whenever you change a resource, and it will generate everything for you. Very useful, I use it in all my Actionscript projects.

Anything else?

Well yeah, actually. I want you to use Consolator for your next project. This is a functional Console that will enable you to debug your classes, objects, functions. It supports multiple channels and features an über-simple implementation. Works in Starling, too!


All my tools are available for free. There’s a support forum you can use if you need any help, or just Tweet me at @jorjongames.

It’s already my fifth Ludum Dare and I’m still excited like in the first time

I feel that this Ludum Dare is going to be super awesome with a lot (1000++++) of great new games!

And as always, my weapons:

• Platform – Flash AS3
• Library – FlashPunk
• IDE – FlashDevelop
• Graphics – GraphicsGale and Pixlr
• Sounds – BFXR
• Music – Maybe some random generated music
• Food – Chocolate, A LOT of CHOCOLATE
• Live stream – Open Broadcaster on Twitch
• Encouragement – Friends, my cat and the Beatles

I’m In!

Follow me on twitter for live updates! ( @galman33 )

Play Despair

Remember my little MiniLD#40 game? No? It was that strange game about fighting the news. I read your feedback and comments, and figured I could remake the game into something else. I’ve never made this before, I just tend to archive my projects and move on to the next one, so this was a good opportunity to try something else. In the process, I trained my willingness and discipline, because working on something you thought it was finished, it’s pretty hard. I hope you enjoy the new game and continue to give me feedback!

[You can read a full post-mortem at my blog]

Don’t you sometimes get enough of that?

 

PLAY :: RATE

No? Well I do. That’s why I decided to show how much I detest watching news and hearing about the world sometimes. Ok, most of the time.

The game was developed for the MiniLD#40 competition, themed: The Real World.

What the hell is this about?

Avoid the world is about defending yourself against media information (or misinformation). You fight with your only weapon while watching TV: your remote control.

Your goal is to push away all the words that the TV screen vomits upon you. If they reach you, your brain damage will increment, and when 100%, you lose. Note that you can’t win against the TV, you will always lose at the end.

Can I get Brain Damage playing this?

Good question. Yes you do, so please play carefully.

Where are the words coming from anyway?

The words are automatically read online using advanced alien technology, found in a cave by honorable scientist Giorgio A. Tsoukalos. In the modern world, this is know as RSS, a format which most newspapers have.

Did you find any trouble while doing this?

I’m glad you asked. Well probably you can’t imagine, but this was rather hard to make. Read the full post-mortem in my blog, I dare you! I DOUBLE DARE YOU!!

Hey everyone! It’s Rich, the programmer/composer half of Green Pixel. This past weekend Joe and I entered our first Ludum Dare and ended up making this game over the course of 55-60 working hours (which is almost a week and a half at a regular job when you think about it!).

 

Before the Jam:

As much as I love playing and making games, I also love developing really boring but useful tools. Early on Joe and I realised we only have interest in creating games from the NES/SNES era and that means sprite sheets and tile maps, baby! So over the past year, knowing our self-imposed limitations, we’ve been working together to create a set of tools to make our lives as 2D developers easier (every day we inch closer to the “generate game!” button!). Two of these tools, our animation system and tile map editor, became extremely valuable over the weekend.

For the week leading up to Ludum Dare, I started writing a 2D flash engine. We went with flash because:

1. You can play the game directly in your browser.
2. ActionScript is a rrreally forgiving language which is perfect for trying to get a game finished in 3 days and not being arsed to fix memory leaks and whatever else.
3. I haven’t gotten around to making a cutscene tool yet, so movieclips to the rescue!

I had never tried making my own engine before and now I can’t imagine how I got by before. With the tool chain and the new engine in place, Joe could section up a sprite sheet, create animations and I could have it in the game in about 5 minutes.

 

The Jam – Some notes on the creative process:

Friday – First of all, the theme really took me by surprise and I think I actually voted it down a few times haha. Anyway, we heeded the advice of the keynote and spent about an hour or so brainstorming ideas. We decide on a top-down Link To The Past style game where a Mad Scientist would have to gather resources to build a death ray to protect a world he hated from a meteor by smashing up people’s property whynot. I began by breaking the game down into the various objects that needed to be coded. We had the idea to randomly generate the town and the house interiors, so I first broke up the map into equal sized squares. Each square could have a 0 or more houses, each house could have 1 or more floors, each floor would have 1 or more rooms and each room would contain various objects and NPCs. Too ambitious! At the end of the first night and having a bunch of weird-looking half-assed procedurally generated house interiors, it was clear we would have to design some house templates and assign these templates randomly to build the town. We also constrained each house to only have a single floor. The game looked like Colecovision at this point with my amazing programmer art of solid coloured rectangles, but morale remained high!

Saturday – When I woke up, Joe was finished most of the character animations at this point, so I added them to the player and the NPCs. The NPCs just stood in the top corner of each house and didn’t scroll with the map, but they looked good! The big task for the day was grabbing sections of the templates to build the town map and house interiors. We also discovered the size limit on a ByteArray in ActionScript! Fortunately, Joe was able to prune the templates down so we could load the maps. That night we discussed things we wanted to put in the game, but would have to cut if we were going to reach the Monday deadline. We had originally planned on a few different locations (military base, good scientist’s lab) and giving Dr Vile an inventory of collected resources, similar to Minecraft, that you’d periodically have to empty at his lair in order to build parts of the death ray. We scrapped these ideas and just focused on the town game play. By the end of the first full day, we had a clear vision and most of the visuals in place… just no game play.

Sunday/Monday – The long haul! We vowed not to sleep until it was complete! (We actually did end up sleeping, but we also completed it so I guess that’s ok). Jobs for the day: NPC AI (yeah, I foolishly left this until 23:00 on Sunday night), breakable objects, loot spawning, music and sound effects, cutscenes, HUD graphics, game flow (menu – game game over – final cutscene – menu). So… basically half the game. We worked until 9 am Monday and took a brief 4 hour nap and then rushed like crazy to get the rest of the things into the game but it all came together in the end.

 

Scary Times:

• We had a bug in one of the tools that almost erased all the art for the game on the second day haha. Luckilly, it was fixable while the art was still in the RAM.
• Generating a ByteArray so large that it crashed the flash game and not really having the time to design an alternative.
• A bug in the AStar implementation meant that if an NPC was more than 10 or so tiles away, it would take about 20 seconds to calculate a path. AStar is not a lot of fun to debug at the best of times, but it was about 4:00 am Monday. Luckily, the problem was simple and it ran fairly smoothly after that.
• NPC AI in general. I had never done enemy AI before and there are a lot of things I would do differently now (like not calling the path finding function every frame when they’re chasing you d’oh!)
• Combat. I had also never really done any sort of melee combat before. It works ok, but it’s definitely clunky and can lead to some garbage deaths.

Good Times:

• We finished!
• Pretty much had time to implement everything after stripping down the feature list.
• Learned a lot in a short amount of time about AI and procedural generation.
• Doing both code and music has a nice duality where if I get pissed off with one, the other uses the other side of my brain. Mmm, brain massage.

 

Conclusion:

All in all, it was one of the most fun weekends I’ve had! I already can’t wait for the next Ludum Dare in April. <3

Someone expressed interest in the source code in the comments section for the game itself, so I’ll upload that. I don’t know about the engine code? It’s kind of in an unfinished state and I might release it as an open source library along with the tools some day. Hopefully the game source will still be interesting!

Congratulations to everyone who participated and submitted a game!

 

Click here to view my LD entry.

Or click here to go directly to the game.

 

This post contains a few spoilers (sorta), so I suggest playing before you read on.

 
Phew!

---

What a hectic, fun, stressful, and exhilarating weekend this was. I’ve never participated in a Jam before, nor have I ever actually completed a game, or made something beyond the game I’m still working on.

That first game has been (slowly) in development for almost a year now, so the idea of creating a game in a weekend was very appealing to me. Almost like a “right place at the right time” moment for me, as I’ve been struggling to have the motivation to continue development on my first game. Turns out that LD was exactly what I needed.

All the lessons and techniques I’ve learned from working on that first game really helped me create Shadow Possession in the short amount of time I had. I’ve also learned that if I can make 8 decent levels in 60 hours, there’s no excuse for my first game having only 5 levels in 9 months! It’s been a good wake-up call.

 
What’d I miss?

---

I have a good list of things that I didn’t have time to get into the game.

Off the top of the list: more sound effects, an increasing difficulty curve, and new rules/additions to the mechanics.
 
Sound

---

Sound is something I always had in mind as I developed Shadow Possession. I imagined “darkness-y poof” sounds when you would flip and land, a “searing, burning” sound when you were hit with light, and the appropriate sounds when the lights begin to flicker on and off. They really would have added to the atmosphere, yet I simply ran out of time. A few more hours probably would have been enough, as I had gotten footstep sounds into the game, so it was only a matter of having the time to find the other appropriate sounds I needed. Fixing nasty bugs that appeared in the last hour or two took priority, unfortunately.

 
Increasing Difficulty/Additional Mechanics

---

I had wanted the difficulty in Shadow Possession to eventually start escalating, after the player had time to learn the mechanics I continued to introduce. I set the flow of the levels in a calculated way – You learn to flip before you learn that light hurts, you get used to avoid light to continue before you learn that some lights have switches, and so on. The final level in SP should hint at what I wanted to do next with the mechanics – mobile lights via people/creatures/machines/whatever made sense. My plan was to have some AI that would wander in certain areas, and if the spot you with their flashlight, they’d chase you. They’d be either random strangers or perhaps friends of “The Gentleman” (the guy whose body you possess). I also wanted to make the light kill you quicker (and perhaps not push you out as much), but balancing the difficulty with that would have taken more time, so I went for more of a timing approach.

 
The Result

---

Despite not getting more sounds and menu in, I’m still very pleased with what I turned out. It was a lesson-full, motivating experience to take part in. I’d like to compete in the next LD again, and do something with procedurally generated levels/content. I’m not sure what takes longer – hand-crafting levels, or letting your systems do that for you (and working out the bugs), but I’d like to take a crack at it, as I’ve never done proc gen before.

 
The Future

---

If you liked Shadow Possession, look forward for a new version in the soon future. Now that I can take my time and really give it some finesse and challenge, I’d like to see where the game can go. I plan on setting deadlines to self-motivate like I did for the Jam, so development won’t take years. I won’t try and estimate a release time this soon, but I plan on seeing what I can do in a week or two, and take it further as needed.

 

All in all, I feel a good kind of different from before I participated. A pretty tired kind of different, but a good one nonetheless.

I finished my Ludum Dare entry, I didn’t make a post yesterday because I was too tired.
Come play it if you want some rpg goodness. Click here!

Also, here’s a timelapse.

This was a tough weekend!

And yep, I did it again ,I made a game in 48 hours ( And the whole LudumDare community too of course :P)

As always I had a really great time making this game and I’m really proud of it. I think that my “graphic skills” really improved from the last LudumDare and that’s some great news for me. If I had some more time I would spend it on the “fine-tuning” part of the game to make it more balanced, not too easy, not too hard.

I was streaming the whole game creation process on Twitch and it was fun to talk with some other devs from times to times.

Play and rate my game here!

 

Thanks for reading! If you want me to play and rate your game too, don’t be shy