About Ithildin

Entries

 
Ludum Dare 37
 
Ludum Dare 35
 
Ludum Dare 34
 
Ludum Dare 33
 
Ludum Dare 32
 
Ludum Dare 31
 
Ludum Dare 29
 
Ludum Dare 28
 
Ludum Dare 27
 
Ludum Dare 26
 
Ludum Dare 25
 
Ludum Dare 24

Ithildin's Trophies

Ithildin's Archive

I’m (probably) in!

Posted by
Friday, August 23rd, 2013 10:39 am

The theme reveal will find me on a train travelling back home throughout the whole night, so I guess that I’ll use that time for design or (gasp) sleeping.

Tools:

  • Language: AS3.
  • IDE: FlashDevelop
  • Additional libraries: Starling. Depending on the game needs and time, add to the mix the Particles extension  or Box2D.
  • Starting codebase: Some utility classes for scrollable maps, animations,…plus the basic application layout, mostly reused from my previous Flash-based entries. (Sources here)
  • Art: Photoshop, Flash.
  • Sound: bfxr, and I’ve been learning OpenMPT, so I might give it a try if I have the time.

“Sociales Santillana” – Post-mortem

Posted by
Wednesday, May 1st, 2013 8:17 am

 

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

Spoiler alert!

 

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:

“Gran Cairo”, Frank Stella. 1962

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?
For example, compare these

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.

 

Can you add instructions to an embedding HTML?

Posted by
Monday, April 29th, 2013 5:14 am

I’m using HTML to embed the SWF with my game, and I would like to edit it to drop a couple of lines to add  a simple paragraph with the controls. It’s not part of the game per se, but it may affect the perception of the players about it, so I’m not sure if that’s OK or if it would invalidate my submission. I’ve checked the rules and there’s nothing stated in one way or the other.

Does anyone have any idea?

On a related note, would the same apply to “readme” files?

Link to the entry

Basic gameplay done

Posted by
Sunday, April 28th, 2013 7:35 am

Well, at last I have the basic functionality done.

Yup, it's a match-3 :DD

Yup, it’s a match-3 :D

Short, watermarked video beyond the link

There still might exist some bugs in the match calculations, but I’m having trouble to catch them and they’re rare enough, so I’ll try to sort them out later.

I think that if I submitted it right now it would be 100% fitting with the theme both aesthetically and in terms of gameplay, which is what I was more interested in. Still, I would like to expand a bit more on it, so these are my next steps, after a late lunch:
– Additional visual cues, to make the available options clear.
– Sound.
– Gameplay enhancements (making it time-based, allowing to sacrifice some time to discard a plate of blocks, levels, …).
– Game screens.
– Some more stuff.

I’m still considering my original idea for the theme, which is to take a simple, possibly well known game concept, bloat it with superfluous elements (unnecessary visuals or sounds, metagame/non-social features that no one cares about and detract from the game experience,…) and as the player progresses through the game, strip it from everything non-essential until she gets to the most basic core of the game  (I would use “purest”, but that would make me look pedantic :D).

 

Finally, an idea :D

Posted by
Saturday, April 27th, 2013 2:30 am

Woke up to check the theme (which happened to be the one I’d thought less about…sigh), and after thinking about the possibilities (graphics, gameplay,…), I may have found an  idea for a puzzle game. This is a quick concept:

Game Concept

…which is more than heavily inspired by a Google Images search that led me to a work by a minimalist painter (incidentally, my primary school books had this as their logo).

Frank Stella, Gran Cairo

I think the idea can work fine by itself, but I have in mind some twists that can add depth to the game concept if I have enough time.

I might be in

Posted by
Friday, April 26th, 2013 3:04 pm

Still thinking about joining. The theme will be a decisive factor, so I’ll try to brainstorm a bit with the final voting list.

Tools:
– If I’m feeling particularly bold, I might use Unity/C#. As that’s unlikely, I’ll probably stick with AS3 + Starling using Flashdevelop, and reuse the core classes from my previous entry, Conquer all the castles!
– Photoshop and, depending on the game, perhaps Tiled and Texturepacker
– sfxr, probably, for sound effects. I’m still undecided about music, though.

The dungeon:

20130426_234915

It’s evolution, baby! A LD24 post-mortem

Posted by
Tuesday, August 28th, 2012 2:15 pm

This has been my first LD ever, and I have to say that it’s been quite a satisfying experience, from which I’ve learned some interesting lessons. To tell the truth, I wasn’t sure that I would end up submitting an entry at all, so I didn’t take it seriously enough and devoted less hours than I would’ve liked to, but still, I am proud that I applied in the end.

What went right

Having a clear objective.

I already had some ideas for games based on evolution, so once the theme was announced I only had to choose between two different approaches to develop it from a common core concept: an evolving ecosystem. Thus, that core concept was always in the horizon, which helped me not to ramble too much.

Focus on simple goals.

Rather than getting lost in architecture details, that frequently lead to a dead end (well, at least that tends to happen to me), I split the steps to reach that goal into small, simple tasks, so that I could iterate quickly and had new things to show (not necessarily in a visual sense) all the time. The feeling of accomplishment is really rewarding, and pushes you further towards the next goal.

What went wrong

Language choice.

I really like programming in C++, and I’m always eager to keep learning and improving at it, so I take advantage of every opportunity that allows me to do that. However, and despite what I previously said about the feeling of successfully reaching some minor milestones, the main objective of the Ludum Dare is to develop a game in a really short time. This means that we should be smart enough to choose wisely the language, tools,etc, that will allow us to optimize that time and, especially, reach a larger number of people.

To code a full game from scratch in 48 hours (well, in fact I would say the actual time devoted to it would be more or less one third of it) using C++ is probably much less time efficient than the other alternatives I’d considered (AS3, Pygame), even if I had the feeling that I was spitting out features at a relatively high speed. Yeah, it is more powerful but, being realistic, a game intended to be finished in less than two days will not probably require that much.

And then, of course, there is the issue of distributing your game.

I only did a Windows release, so that leaves Linux and Mac users out of the equation (even though a port to Linux could be more or less immediate, but I don’t have any distro installed on my laptop). What’s more, even for Windows the probability of errors or crashes due to missing DLLs, incorrect build executables, etc., to appear is relatively high, which puts an additional barrier to your public. To top it all, since I finished quite late, I couldn’t playtest it with friends or family, so I could only trust my computer.

This led to some chaos on Monday, where the initial build submitted was using a debug executable and crashed in several machines, or there were strange frame rate drop issues (about the frame rate, I realized that the main loop implementation I chose left to be desired, too…but the disparity spotted in one case was unreasonable). I submitted a fixed build, but there are still some crash reports.

So, the conclusions are: First, think carefully about what you want to achieve: is it learning? Ok, but then don’t complain if you spend twice or thrice the time and can’t have so many things done; Is it developing a fun game? Then use something that allows you to have a fun game FAST. Is it a mix of both? (Yeah, I’m stubborn) Well, in that case, FFS, USE SOME CODE BASE. A basic game core, functionality for rendering text (which isn’t trivial using SDL_ttf plus OpenGL as I did), sprite drawing, sound, UI components…all of these can really help reducing the time spent developing low-level stuff, leaving you more time to make the game fun and cool-looking, which is what matters.

Second, if your application artifacts are platform-specific, test it, test it and test it once again in as many different computers as possible. And, if you’re making a multiplatform game, test it, test it and test it in as many different platforms, browsers and devices as possible.

Lack of overall focus

This may sound as if it contradicts one of the epigraphs in the “What went right” section, but in reality they’re two different things… Here I mean that my commitment to start coding wasn’t 100%. I would wake up in the morning and debate between overall procrastinating, playing something or developing the game, and when I realised I’d wasted several hours. Yeah, once I launched Visual Studio and started typing I’d enter the “flow state” and I could spend hours coding non-stop, but all that time lost was invaluable. Of course, the final result has resented.

Gameplay? What gameplay?

Being a gameplay programmer myself, this is probably my main grip.

Since I’m interested in genetic algorithms and evolution, I focused too much in having a simulation running with mutations, crossing and selection of the fittest. Once I had that, I would then give the player the ability to interact with the world and give them some challenges. However, on Sunday morning and during most of the afternoon I barely did anything until a couple of hours before the deadline, which means I ran out of time to put on the actual “game”. I just threw a couple of unbalanced or just plain useless actions to alter things such as reproduction rates or…let’s call it “non-organic food”.

A player would have a toolbox or options to give advantages/disadvantages to the survival of creatures. The goal of a level would be to get to a given number of specimens fulfilling a set of traits in a set number of generations. Since she can’t choose the traits directly, all she  has in her hands is the power toolbox. Thus, she might raise a plague affecting…let’s say “mostly blue” creatures. Or perhaps provoking a flood. In addition to cooldowns, using those powers would use some amount of an undetermined resource.

Another really basic feature that I regret that I couldn’t implement was AI. I don’t mean flocking behaviours or anything like that (at least in the beginning ^_^), but simply giving preys the ability to detect and flee from predators, and make these able to chase them would have been a really interesting thing to do.

In the end, creatures were left with a really limited set of genes: speed, the way they got the energy, how they reproduced, their starting life…and not too much. I regret not having put things such as “sight”, “locomotion”, or “personality”, for example.

Some other, more advanced features that I had in mind included a somewhat hostile environment, and some resource management aside from the living creatures interacting with each other. This would have opened the door to new creature traits (flying creatures, amphibious, temperature…the possibilities are endless), and new ways for the players to alter the world conditions and make thing easier to increase or decrease the odds for the creatures to survive.

As you can see, the whole concept can become too complex really easily, and you have to constrain yourself to something doable in 48 hours. A noob’s mistake =_=

 No polish at all

Again, as a consequence of the lack of time, I couldn’t go past the primitive-based procedural shapes and put something nicer instead (actually, procedural wouldn’t have been that terrible if I could have done something similar to Dawkins’ biomorphs). Some sound or music could have been nice, too.

 Ø——————- Ø——————-Ø——————-Ø——————-Ø

TL;DR: For the next time, I’ll try to start small, with a clear, complete idea. Then, iterate over it, getting incremental, but working and testable functionality, and commit to the jam 100%. Also, I should favour web deployable solutions over C++ unless I had a minimum set of libraries to save some time and focus on gameplay. Last, think of the childr…eeer, of the public (meaning: test it if possible in more than one machine, and try to port it to Unix-based systems it it’s not a web release)

[cache: storing page]