Friday, June 17, 2011

Coglitz

Experimental Gameplay Project's theme for June 2011 is mashup and my submission is Coglitz, a mix of games I like: Cogs and Droplitz. I just thought: what would result from this combination?

Windows users: quick play this game on Game Jolt

Download the sources in my cellar (should compile on Windows, Mac OS X and Linux).

This prototype is the opposite of Lifetime: no story, just gameplay. I guess I have to see both extremes to find the right position.

At the beginning, I wanted the tiles not to rotate, but it has appeared it is just too difficult. Anyway, you can still play with no tile rotation, called "hardcore mode". It's interesting to note that I first try to rotate the tiles and then to move them when rotation made nothing; my playtests revealed that too. Well, Cogs is more intellectual than Droplitz.

I wondered if I could make it on Flash, using Stencyl or haXe. It's actually a typical Flash game. I've finally made it in C++ because I discussed with Martin about doing some improvements on the sound design, and he heavily relies on FMod. Therefore I used SFML and it works well. It includes wrappers on top of OpenGL and OpenAL, as well as classes to handle windows and input. It also provides network and parallel computing classes, but I haven't used this part of the framework. But I have to say: avoid SFML for a tile-based game! As you may see, the tiles are not perfectly aligned, though I attempted to fix it. Among other things... Update 6/22/2011: Rémi gave me a hint to this problem (as always he was right): SFML "smooths" images by default, actually by doing some linear sampling. I disabled that for the tiles and it looks better. Sorry for this incomprehension, SFML may work for tile-based games! I keep the old screenshot to let you compare (and because I'm too lazy to change it).

As I tried to code it with iterations, I built some things which were later removed, in order to simplify them. For instance, the coglitz used at first a path system to move, a graph with points and edges fixed on the tiles. With the introduction of tile rotation, I thought it was too complex to maintain this system, and I replaced it. Now the tiles are simply described (image, and whether they have a pipe on each of their sides) and coglitz move along the axis (it may introduces some floating-point errors, but that's not important there). But as I was in a hurry to get things done, I didn't refactor as much as I wanted. I should clean the code in the next few days. Don't read the code right now.

I made the graphics the last day. It didn't need to have nice tiles before. I found wood is a nice theme, and the design quite easy to do. Tiles in Cogs are already made of wood, and it just fits with the gameplay.

But I take back what I said last time: I took two days more to do Coglitz than I needed for Lifetime, although with far simpler graphics. So I deduce: if you want to do a game, it doesn't matter whether it has good graphics, good gameplay or anything else. All you need is a clear vision of what you expect. Pretty reasonable, huh?


PS: the rabbit is just a joke for a friend. And yes, it's feature creep. Too bad.

Update 6/21/2011: Some things I'd change if I had to do it again:
  • There is no entity system and I feel quite bad about that. At first it was great because I didn't want to lose time adding generic behavior when there is no need for it, but at the end there are too many dependencies (worse, cycles!) between the objects. It could have avoided hours of search for segfaults. So I would put some system to isolate the tiles and the coglitz. When a tile moves or rotates, an event is sent to drop coglitz on top of it.
  • Maybe the tiles and the board (actually the game) should share the same interface to give coglitz directions to follow. In the current implementation, I manually set the motion of a coglitz when it appear, then on every tile it checks the available directions and whether there is a collector at the bottom. With an interface, there would be no difference. It would make the code for the movement easier.
  • Last but not least, I would do another game, because this one is really not fun to play. Well, I knew it, and the goal is to test experimental gameplays, but it's not so rewarding.

No comments:

Post a Comment