So I chose to make a game with HTML5 / Javascript using the JawsJS html5 gamelib.

I used the <canvas>-tag since I wanted to make a freeform level with pixelperfect collisions, basically I made the whole thing in graphics gale, could as well have done it in paintbrush.

The new HTML5 <canvas> tag makes it easy to get the data in raw format, basically an array with RGBA values. From there on it’s to check collisions.. 1 pixel at the feet is a decent start.

The most annoying thing is probably the audio-formats that’s supported for the new <audio>-tag.

Safari doesn’t play OGGs for some lame reason, and Firefox doesn’t do MP3s. So all audio has to be provided in 2 formats.. also you wan’t detection at asset-loading time etc. I could have lived without that cruft.

Otherwise Javascript has become amazingly fast, I think V8 is faster then ruby and python. All browsers come with good debugging possibilites.

Javascript doesn’t have the traditional classes and inheritence, but rather prototypical inheritence.. which can be confusing at first.

What I love is the dynamic nature of objects in Javascript.. basically all objects are big key-value storages (hashes).

So you can whenever you want just set a new flag/property on whatever object.

/* Player.dead has never been defined or used at this point */

if(player.dead) { … do sometting …} // won’t throw any error.. played.dead will just return undefined

player.dead = true

if(player.dead) { … do something .. } // played.dead is now true and code will be executed

The biggest upside with javascript is ofcourse ppl not having to download anything. No virus-scan etc etc. Just instant gaming. And the big players are making the javascript engines faster on a daily basis.

Play my Javascript game here:

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

Here’s a teaser-shot from the game, you start in the “west prison” and have to find your way out of a huge castle.

So .. you’re a bit of a pickle and need to use your lady-brains to get you out of it … 

Play: http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=1087

Making a 5x retro pixel adventure/puzzler:

Planning on making a HTML5 javascript game using http://www.jawsjs.com/ this time around.

Warming up by converting an old LD entry I made in Ruby into Javascript. A 10-minute canvas-tag adventure, check it out:

http://ippa.se/webgames/unexpected_outcome/

Been working a lot on a Javascript game engine called JawsJS ( http://www.jawsjs.com/ ) for the last months. Aiming to make a game with it this LD.

So why make a game in Javascript?

- ppl don’t have to download/install/unzip anything

- no securityworries where ppl have to scan your files and/or switch to their “game user”

- The new popular HTML5 comes with tons of new power, canvas tag for freeform painting, audio tags, local storage, websockets for multiplayer.

- Builds on years of experience  of my Ruby game engine Chingu

- instant deployment across all operating systems, hell even for tabs/phones if done right.

Now the last point isn’t 100% true. There’s a lot of browserquirks to take into account. But if the gamer has a decently recent Chrome of Firefox there shouldn’t be a problem. IE9 works well too (8 is kinda flaky in certain areas though).

JawsJS comes with a lot of example, here’s one:

http://jawsjs.com/jawsjs/examples/example9.html

Also made a full mini-game with it some time ago:

http://ippa.se/webgames/unwaivering/

ippa

Been messing around a lot with HTML5 / Javascript last month. So MiniLD #24 was the perfect time to test it out. Ended up making a small artsy game with a friend, pretty pleased with the result:

http://ippa.se/webgames/unwaivering/ – A small game about true love

(Will take about 2-3 minutes to play through)

I went full retro this time, I love that style of gfx.

4 different ambient “songs” made with renoise to set the mood.

An end with a twist, which I hope will make ppl remember it.

Should take about 5-15 minutes to finish.

Play it @ http://www.ludumdare.com/compo/ludum-dare-19/?action=preview&uid=1087

Made with Ruby & http://ippa.se/chingu

Pretty  happy how the game turned out:

- 10 levels of raising difficulty

- knights, horses, balloons & different tower guns, all animated

- global high scores via http://www.gamercv.com/games/14-gnorf

- sweet readable ruby source code

Play it @ http://www.ludumdare.com/compo/ludum-dare-18/?action=rate&uid=1087

Most GFX and game logic done, quite some glue and polish left. The last 20% really takes 80% of the effort. Which makes sense as no mather how well you organize your good you’ll still end up with growing complexity to look after.

…  is probably the most common reason for software project failure.

So don’t end up with it =).

So, I’ve noticed you can bump up your devspeed if you do one thing at the time. For example.

1) Figure out your general idea
2) Try to make most of your sprites
3) Start on your gamelogic

Instead of:

1) Figure out your general idea
2) Make one sprite
3) Code the gamelogic for that sprite
4) Goto #2

This is also true with sounds, try to do/generate them all at one point instead of constantly switching between your code, your sprite editor and your sound software.

And here’s my first screenshot:

… so one day before LD, I sit down and make a 12h game for Whyday.

The game become somewhat of a small puzzle platformer. I’m pretty happy with it.

All the puzzles kind of resonates with Why the lucky stiff and his art.

Especially the last puzzle will be hard if you never heard of him (you can scroll down and get the answer though). But if you’re a fan of him, you should try this game out!

Source: http://github.com/ippa/whygone (requires Ruby and the Rubygems “gosu” and “chingu”)

Win32 EXE: http://ippa.se/games/whygone.exe

* SPOILER *

.

.

.

.

The password for the last puzzle is “chunky bacon”.

I’m doing Ruby this LD and I feel extatic. First off my ruby game framework Chingu [ http://github.com/ippa/chingu ] has been making strides the last months. Tons of details have been polished and a lot of bugs fixed. Chingu now comes with a general editor in form of a game state.

From inside your game, just:

push_game_state(Chingu::GameStates::Edit.new)

And your current game will be paused and the editor toolbar become visible. You can now move, rotate, delete, scale, modify zorder and fade any instance of class GameObject you have on the screen. Or put out new GameObjects of your choice from the icon toolbar.

Here’s a quick ‘n dirty look at it: http://ippa.se/videos/holiday_droid_edit.avi (Yes, my screencast software borked up the colors).  That’s from my gameprotoype http://github.com/ippa/holiday_droid .

If you haven’t looked at Ruby for gamedev yet, now is the time, here’s 4 easy steps to get going on windows:

1) http://rubyinstaller.org/downloads/ – install Ruby 1.9.1-p430 or later.

2) “gem install chingu” in your cmd/”DOS” window

3) see provided examples, check README @ http://github.com/ippa/chingu

4) Use http://github.com/larsch/ocra to make standalone EXEs out of your rubyscripts

Ruby is one of the most expressive langs out there. Give it a few days of your life and you’ll never look back =).

Phew. Voting is a lot of work . Downloading everything, unpack them into folders that include the author name (makes things easier afterwords),  fixing broken entries, maybe even installing extra stuff, playing the game, thinking up fair votes and commenting.

Playing the game

I feel you have to give the game a chance. Even if it looks really boring in the beginning. Sometimes it turns out to be really boring, but I feel more often it stuff can grow on you if you open your mind, try to ignore any irritating bits and concentrate on the mood the developer try to create. I found myself really trying to finish several games (and succeeding) and steering a little grey dot over a paintbrush map for at least 10 minutes (and enjoying it) .

Voting

Voting is hard. You want to be fair (naturally). After I’ve played about 5+ entries I get a feel for what I consider a music 3.. or a humor 4. I can only decide on ratings by comparing the games.  Is this how everyone does it?

Commeting

Getting positive feedback and comments is probably the most fun, and could be a big part of the motivation to make a game for LD.  Since I enjoy it so much I feel I should write something (sometimes more, sometimes less) to 99% of  the entries I try. I doesn’t need to be much work commenting, just say what’s on your mind and focus on what’s good in the game, or how something could be made even better. If you “force” yourself to comment on every game you get good at it after a while

sfernald sank his teeth into the game engine for my LD#16 entry – the light in the end of the tunnel and the results came out swinging!

He’s used the game engine better then then me, making some winding, fun, hard to beat, acid-filled caves.

Check it out:

Source:  http://www.bitjets.com/thelight2.zip
Win32 exe:  http://ippa.se/games/the_light_2.exe

Maybe I’ll make a sequel too since the original game was so tiny. Actually I already started hacking on it. Some ideas/goals:

• The collision detection wasn’t perfect (for example you couldn’t jump while running into an obstacle)
• I’m thinking level-building from One big image instead of several small, but there’s quite some things to work out before that’s possible.
• More interaction with the world, could be levels to pull, buttons to push, doors, modification of terrain or living enemies, not just acid pools/drops.  Preferable additions that don’t complicate the level building to much, now it’s basically drawing a new image and creating one class — liberating easy.

I used my favorite language of all time, Ruby. With 1.9 Ruby has picked up speed and with Ocra you easily make a ~1-2 meg exe-file out of it. Also the excellent (and german precision engineered)  Gosu enables OpenGL accelerated 2D. On top of that I used my own Ruby/Gosu-specific framework Chingu to get game states, re-usable game logic and a boiler plate “game object”. To get a speedy get_pixel() I used the awesome Texplay by John Mair.

I have a pixel fetish. I love retro-looks in games, and I love pixel-perfect-collisions, a fetish that probably came into existence playing hours and hours of Lemmings 2-player mode on the classic Amiga 500.

So, the most time was spent up building a good pixel-perfect-collision algo, and it came out very playable, but not perfect. I ranted about it in my last blogpost.

With Ruby and Chingu my level-building got very clean, I think even ppl not into Ruby could understand what’s happening here:

class Level7 < Level
  def setup
    self.background = "level7.bmp"
    every(1000) { Enemy.create(:image => "acid_drop.bmp", x => 150, :velocity_y => 5) }
    every(1500) { Enemy.create(:image => "acid_drop.bmp", x => 250, :velocity_y => 5) }
  end
end

or here (this is from the mainloop):

player.each_collision(Enemy) do |player, enemy|
  unless player.paused?
    player.pause!
    Sound["die.wav"].play(0.3)
    after(1000) {  player.x = @entry_x; player.y = @entry_y; player.unpause!; }
  end
end

It’s nice when it’s silly simple building readable levels.

I also got a very basic and simple Map-class going so I could build on my matrix of screens that made up the game:

map = [
[LevelUp, nil, nil, nil],
[Level1, Level2,Level22, nil],
[LevelAir, nil, Level3, nil],
[LevelAir2, Level5, Level4, nil],
[nil, Level6, Level7, nil],
[nil, Level8, Level9, End],
]

Basically if you exited a screen to the right I would increment a column_counter and fetch a new screen from the matrix. If exiting downwards, increment row_counter an fetch a new screen.

If you like OO, short readable code and scripting languages in general and haven’t checked out Ruby or Gosu yet, now is the time to do it.

… with a twist. Give it 4 minutes of your life and I’ll give you a smile.

http://www.ludumdare.com/compo/ludum-dare-16/?action=preview&uid=1087  <– Here it is.

Every time I use pixel perfect collision in a game I try a slightly different approach, trying to perfect the algorithm.

First it seems very very simple. Let’s just check 1 pixel at the center bottom (at the players “feet”) for a non-transparent pixel. If there’s a collision, follow Y-axis upwards (say, max 5 pixels) until we hit a transparent pixel (non-terrain). Put player there. This will make him walk on the terrain.. and also climb 5 pixel high obstacles. Higher obstacles needs to be jumped.

Cool enough, just checking one pixel and we get all that.

But then you realise you can jump into the roof.. and player will only stop first when his feet head is way into it and his feet his touching the roof.

So you check another pixel for collision, one at the head of the player, now you can stop him when he jumps into the roof. It works well.

Then you start painting more levels, and soon enough you’ll make a pointy object. The player jumps into it, not hitting the head or feet, just the mid-section. Player falls down by gravity, head hits the floor of the pointy object, and the player gets stuck.

You could either not paint pointy objects.. or you could extend your collision detection algo. One of the reasons I went with pixel perfect collisions is that I wanted levelbuilding freedom, just being creative and painting whatever fun terrain in paintbrush or graphics gale. I WANT pointy objects. Makes for nice ladders the player could jump on .

So, we add pixel checks on the left and the right side of the player so we don’t jump into pointy things. It works decent, but you realise just checking 1 pixel at each side doesn’t cut it in all situations, objects you jump into could be Very pointy. So you basically end up checking all pixels on all sides. A bounding box if you so will, and we check all the pixels along the borders of it.

This is totally ok if you got a fast get_pixel()-method for your disposal. Now, how I usually do small games is I have a “physics”-behavior which I plug in into my player-class. This adds some instance variables to the player-object, velocity_x, velocity_y, acceleration_y etc. Before each update() the plugin will read those and modify x and y accordingly. Then I land in the update() method of the player with my new x and y (the behavior even saves previous_x and previous_y for me if I need to revert to the most recent position).

So, I’m in player update() and I got a new set of x and y .. and I got my collision_left?, collision_right?, collision_bottom? and collision_top? methods (I do Ruby so “?” is totally OK in method-names).

Still sounds like this should be simple, but it turns out it’s not.

What side do I check collisions for first? Depending on what I start with I’ll get different player controls. If I start by checking collision_bottom? and reverting y to previous_y on collision, then checking left/right and reverting x to  previous_x on collision I will be able to stick the player to a vertical wall just be jumping (say to the right) into it and keep holding right arrow-button. And if I check right/left first there’s other effects.

Though this might an effect of first doing all the physics and then doing all the collision detection. Maybe it’s a must to them at the same time, and with that I mean, if a right arrow key is detected, you “fake move” your player 1 pixel to the right and if right_collision? is true, you revert instantly. And so on.

I want to end up with something simple and readable, and I feel it should be possible.

Here’s a screenshot of the game I’m fiddling with, to give you a sense of what kind of terrain we’re talking about:

Who’s got the perfect pixel collision algo with simple physics? (only acceleration_y / gravity is OK)

So..

First screenshot:  http://ippa.se/ghost.PNG

Rubyc0de @ http://github.com/ippa/ghost

You just died, floating above your cross… such a tragedy..

After tons of  last minute tweaks and fixes I’m done. As they say, the last 0.1% takes 99.9% of the time .

I’m happy how it turned out, and I got to put my new ruby/gosu framework Chingu ( http://github.com/ippa/chingu/tree/master ) to the test.

Oh.. and don’t awake him…