I see the screenshots and think "bestguigui" immediately. I was always quite, erm, affectionate with this "2.5D" gfx style - good job!

Overlap2D seems like a nice tool for non-tiled level design:
http://overlap2d.com/

Well, if your game state is complex, then your save file can get complex too. So what do you serialize? Well, that depends on you. You can, as stated above, marshalize almost everything. You can have a state object for every game object that can be altered and iterate through them. You could have a Save class that would be a minimal representation from which you are able to restore game state (good idea when yous savefiles are getting too big, but will require additional coding + it might be tricky to keep it consistent during development).

Also, ask yourself how exactly should the save mechanism work - should I spawn in the exact same position or in the checkpoint? should enemies/exploding barrel respawn? should my health regen? etc., because some of these choices may complicate/simplify your saving mechanics.

It is a perfectly valid question and there's definitely more than one valid answer. Also, it has very little to do with the technology you use, and much more with your design choices.

First of all, you have to answer yourself what defines your "game state" - for example it would be variables for level number and user position. Easy approach would be to wrap these variables into a GameState class. Now when your game has a game_state object you can serialize/deserialize it on save/load events - and that's about it.

I found a little while to give it a try and sadly it doesn't work for me. I tried to run your examples as well as some of my own code and the only one I got to work was the pong example.

The other ones I can rake build, but running in browser all I get is a blank rectangle where the game is supposed to be. JS console shows one of the following errors:
Uncaught NameError: uninitialized constant Dare::AnimationState
or
NoMethodError: undefined method 'on' for Dare::Window
depending on how I tamper with appending /lib folder in rakefile.

Tested with Ruby 1.9.3 and 2.0.0-p598 (32 bit) on Win8 box.

Yeah I was wondering if something like this would be possible - and I thought why not then. Now I love how someone actually made it.

Also +1 for basing the API on gosu. Please keep working on it, this will be big.

Don't ask a Windows user :)

But sure, I can provide an example when I get home.

Making GUIs is actually quite straightforward so you should go ahead and try doing it your way. First, think what elements you need, and then just write it how you feel it.

For example, if you need a dialog box, it needs a state for it - and then you can have a method for invoking a dialog in game, i.e. game pauses and the box with given contents is shown on top.
Then, to let user actually do something, you need a concept of button (that has some text on it and a certain action), and then a concept of the action itself. E.g. there will be a 'Cancel' button, that invokes 'cancel' action when clicked, and this action does nothing but return to previous state.
Of course there's more than one way to implement the above and you can hardly go wrong with such simple stuff, so again - do it how you feel it and then think if it makes sense. Eventually you will end up with a piece of code that does exactly what you need, and not "everything that anyone could ever need".

On a not-so-relevant thought, I played with actual ruby GUI libraries once and turns out you can easily use gosu and wx together (meaning you can have separate gosu window and wx app and they can communicate in real time).

Gosu is awesome, but there's lots of reasons.
1) Portability. Forget about mobile devices. Forget about easy distribution. Gosu apps are supposed to be compatible with Windows, Linux and Macs, but they never really are.
2) It doesn't provide very much. It's great for handling input and graphics, but all the mechanics and physics and stuff is up to you. I actually like it, because obviously it makes you learn a lot in the process, but there's a lot of people out there that just want to create something without having to worry about complicated logic and algorithms. Compared to other game libraries/frameworks Gosu can't help you much with that, and I'm not even talking about monstrosities like Unity, but eg. Phaser provides you with not just one but three! ready-to-use physics models.
Sure you can use external tools like Chipmunk etc, but they are not neccessarily always well documented, and tend to break compatibility even more.
3) Handling sound is oversimplified. It's enough in most cases, but if you want something more complex like focusing your actual gameplay around sounds or implementing dynamic music, you might not be able to (or at least it would be tricky).
4) Debugging. Being an enterprise developer, I learnt to appreciate the importance of a good debugger. OK, you can debug Ruby scripts. But you don't want to. And if you want an IDE that makes this process at least half-sensible, you have to pay (quite a lot).
5) An action/reaction loop of "it's not very popular because it's not very active because it's not very popular because...". You know what I mean. It's being developed by a single fine gentleman, who obviously doesn't do it for a living, so it's quite a slow process. There's something going on all the time, but it's not much, and there's so many features I'd love to see in Gosu, and they're not quite there yet and... Blah blah.
Also, the community isn't very active. I mean, there's no problem finding help if you're stuck making something (although sometimes the answer is "you cant"), but you'll notice there's not much going on on the forums etc.

Ask me why you should use it and the list will be twice as long, but what I listed above are quite major no-noes that keep a lot of people away.

I had no idea that there is a book about Gosu (and ohmygod there's a lot of content!)

You could try to store the Window object in a global variable (well, it might not be something you should do, but it's the simplest solution to try), change all the references to this and then replace it with a new instance when needed. But then, it still may or may not work properly, depending on your system and myriad other things, as stated with a sad face here.

You might not have bundler gem, or have multiple versions of Ruby installed (this might cause some chaos), or something.

Just try and remove require 'bundler/setup' line. Says it's required but I believe it actually isn't.

I tried your code and did exactly:
if @state == :in_play
      if @player_1.score > 1 or @player_2.score > 1
        close
      end
# etc...

What happened was, as it should, at score 2:0 game went to :stopped, and then after pressing space the window was closed. If you want it to happen regardless of current @state, just move the condition outside the state if/elsif. There is no reason for it not to work.

Hot and Cold is now officially #654 game of Ludum Dare 30. I was hoping for top 500, but still I got to the better half! (and top 200 humor, how cool is that!?)

Just add this condition to your update loop? Like
if @state == :in_game
  if @player_1.score > 10 or @player2.score > 10
    close   # or whatever you want to do
  end
  # rest of the code
end

Or you could take this opportunity to learn how to implement the observer pattern.

By the way, why can't Song play MIDIs? Is there a reason for this? I had to convert my music to .ogg and that's like +20MB for people to download.

Hooray for platform dependences. On Windows Image::from_text (main text below) is scaled perfectly with no antialiasing, and Font::draw (button test) somewhat different, but still not bad (just don't ask why I mixed the two methods).
http://www.ludumdare.com/compo/wp-content/uploads/2014/08/screen8.png

Of course I had in mind pretty complicated levels, not only with fires and barrels but also water, lava, rocks, guards and stuff, but... 48 hours :)

Build was made with releasy. Other than some fuss about rake version, I had no problems.

48 hours is not very much time. Especially when you're me and waste more than a half of it. Still, I managed to create all of art and game mechanics from scratch. And no levels.

Yeah, so the code is chaotic and redundant and there's lots of weird logic that's not even properly tested, but it seems to work. Even if it hurts to read (seriously, don't). I didn't even have a debugger, okay?

I'm not too happy with the result, but that's only because I ran out of time right after finishing the tutorial. 2 more hours and I'd make it into something at least decent. At current state it could only be considered a prototype.

Enough talk, links!
Windows build
Github
LD page
Blog posts (drama included)

Well, I finished but not really finished. Will write more tomorrow.

I was brave enough to update while working on my LD entry. Seems to work fine (Ruby 1.9.2, no other gems used).
[http://i.imgur.com/LGEPLKDl.png]

I might, but that's not quite how FPS games work :)

Well, I don't really do it every cycle (turned out it's a bit glichy this way), but other than that it's quite what I do.
https://github.com/Jahmaican/jcaster/blob/master/class/playerClass.rb - turn method

Anyway, on completely irrelevant topic - LD30 starts tommorow, if I'll manage to find enought time (which might be a bit hard), I will participate and I'm going to use new gosu. With all these brand new bugs, it might turn out quite funny.

I also noticed strange mouse cursor behavior in one project, but I had this problem before and this might be something I did not manage too fix very well, so never mind.

I can now confirm that 0.8.0 broke my turning around code in jCaster. Here's the story behind:
It's actually quite easy to make your character turn in 3D environment by moving your cursor left and right. But cursor tends to stop whenever it reaches an edge of the screen, whether or not it's visible. Let's say I'm turning left, the moment mouse_x reaches 0, I can no longer do it.
My clever as heck solution was to reset mouse_x to the middle of the screen at some point, so the cursor could just keep moving. BUT, as it turns out, now manually setting cursor position in the middle counts as if it was physically moved to given point, so when that happens, character turns back to the angle he was facing when the cursor was at this position in the first place.
Now I don't know if this could and/or should be fixed, because I guess it is not technically a bug. But it's somewhat interesting. And now I have to figure out a hack to fix a hack.

I can confirm that fonts are no longer broken.

Any ideas about screen_width and screen_height? They both return 0 before super constructor is called and after they return actual screen dimensions. So using a launcher is a valid workaround, but... why?

Edit: what you can even do is something like:
def initialize
  super 100, 100, false
  super screen_width, screen_height, true
  ...
end
And the game will run full screen just fine.

I even tried Dir.pwd+"/media/boxybold.ttf" so the path has to be right, but still no fonts for me. Alright then :(

Yeah, thad didn't help. It has to be font-specific problem, as literally a line before I load an image from the exact same directory and it works ok.

Providing a non-existing path to the method causes different error btw. (ERROR: CreateFileMapping failed, not failed to open)

Okay, I have some issues with 0.8 as well.

Song is broken the same way on my PC.

Trying to initialize the window with super screen_width, screen_height, true throws something like:
ai.rb:30:in 'initialize': Invalid virtual resolution. (RuntimeError)
(my screen res is 1920/1080). But then, in a project where I have a fixed size window as launcher and create a new fullscreen window like above from it, it works fine. It confuses me a lot.

Custom fonts refuse to work. @font = Gosu::Font.new(self, "media/boxybold.ttf", 20) causes following error:
ERROR:  failed to open 'media/boxybold.ttf'
ERROR: CreateFile failed
Default font is used instead.

I also noticed strange mouse cursor behavior in one project, but I had this problem before and this might be something I did not manage too fix very well, so never mind.

On the bright side, this update finally fixed one of my very old problems.

Still way out of reach, sadly:
• 64-bit support on Windows
• Support for Ruby 2.0+ on Windows
• A fresh Android port based on the SDL 2 code

Now I'm sad.

Same on Win8.

Is your shift key recognized correctly by Gosu (eg. with button_down(id))? Maybe you are using an unusual keyboard layout.

I can't really take a look at your code right now, but here's a general idea of what you need to do:


class Game < Window

def initialize
  # standard init
  @state = :game
end

def button_down(id)
  if (id == KbP)
    @state = (@state == :paused) ? :game : :paused
  end
end

def update
  if (@state != :paused)
    # all your game logic here
  end
end

def draw
  # it's ok to leave draw method unchanged
  # of course you should draw something to indicate the game is paused
end

end


I just bought a new PC and I got some free soft, including Stagelight (it's cheap anyway):
http://us.openlabs.com/index.php/products/stagelight
Looks like another way to create soundtracks - simple and user friendly, with piano rolls and drum tracks. Plus loads of instruments included. I would recommend it if Chirp (mentioned above) is not enough.

Well yeah, I noticed now it doesn't look so bad on the video. But the actual game just feels... off.

I used the Windows build, couldn't run it from source because of some ashton errors.

I took a short video, notice how laggy the rocket moves:
http://youtu.be/QxTYSqT7MLk

It's quite something, but VERY laggy. I have no idea why, it shows 30-50 fps, but feels like it's 10.

Unofficial bugs are the best bugs! Your attitude is wrong though. Someone tells you something is impossible, you should try and prove him wrong. This is how lots of crazy stuff is done.

I'm sincerely suprised fiddling around with windows can be this nondeterministic. Shame that I don't have much time recently, because I'd love to do some more research on this matter.

Although, I guess the problems would be OS dependant, so if you make it work in your environment and don't mind targeting only the platform you're using, there's a good chance it'll be okay for most users too.

We don't want this thread to die, right?

So, I don't really like any pixelart/sprites/tiles editors out there, but the one I dislike the least is Aseprite:
http://www.aseprite.org/
I still use 0.9.5 and they recently released 1.0 - it costs $10 to download, but you can compile it from source for free. Gotta try it, because it seems I might finally like this one a lot.
Here's a nice palette to use with Aseprite: https://dl.dropboxusercontent.com/u/31586841/tools/atari.col

I found two nice browser based chiptune makers, great if you don't know much about music and still want to make your own soundtrack. I know there are also some quite simple standalone trackers, but I always had troubles with them.

Chirp: http://chirp.rezoner.net/composer/
This one is quite complex, yet still fairly easy to use.

Pulseboy: http://www.pulseboy.com/
This is as basic as possible, if you are more than 5 years old, you should be able to create something reasonable with it in no time. When you find yourself participating in a game jam and have like 30 minutes left, go for it.

AFAIK dynamic resolution change is impossible, but from what I understand, you just need 2 Gosu::Window classes, e.g. Launcher < Gosu::Window and Game < Gosu::Window. First you create and show the Launcher window, and inside you need a method that will call Game.new.show and close (in this order) after some event (e.g. key pressed).

If you need an existing example, check this one.

And frankly, I never tried it, but if you needed multiple windows at once, I don't see how this would be a pain. You'd just need an observer to pass data between them, or even go wild and use global variables (but then you will be judged).

Nice, but you should always convert all the audio files to ogg, as mp3 doesn't work properly in Gosu on every platform.

My opinion? There are some beautiful languages, there's a lot of "okay" languages, and then there's C++. For me, thinking about using pointers and proper garbage collection would be only ruining creative process. And it's hardly standarized, I heard C++11 tries hard, but I'm not buying it. In terms of "firendlyness" you can't get much worse among object-oriented languages. It's like Ruby's exact opposite - you'll get it to work on a microwave, you can optimize everything, but it's a massive shit.

Well, you make a valid point here and frankly, I couldn't agree more. Ruby really has these issues with portability, making monetizing your games almost impossible.

BUT playing around with Gosu made me understand all the big concepts behind game dev without much fuss and I guess it would never happen with other tools. Now I can smoothly move to something more device independant (I was looking at HTML5/JS frameworks - Phaser seems awesome!), but I'll probably always go back to Ruby for prototyping anything I'm not quite sure of.

On another thought, Ruby's popularity is still growing, so maybe (just maybe) the problems you point out are soon-to-be-ex (example).

So, this is my attempt on implementing Game of Life. It's not great, but at least looks quite good (because GRADIENTS!).

Things to try:

toad
■ □
■ ■
■ ■
□ ■

glider
■ ■ ■
■ □ □
□ ■ □

crocodile
□ □ ■ □ □ □ □ ■ □ □
■ ■ □ ■ ■ ■ ■ □ ■ ■
□ □ ■ □ □ □ □ ■ □ □

this might not have a name but becomes huge and pretty
□ ■ □
■ ■ ■
■ □ ■

this eventually spawns 12 gliders
□ □ ■ □ □
□ ■ □ ■ □
□ ■ □ ■ □
□ ■ □ ■ □
■ ■ ■ ■ ■

Have fun!

Controls:
LMB - add/remove cell
Space - start/pause simulation
R - clear
Escape - exit

Github: HERE

That's one quite relaxing game. I'm suprised you didn't call it "Flappy Cotton Candy".

You have to call enable_undocumented_retrofication method - just once, preferably on program start.

I managed to do it (on Windows) with a third-party program QRes 1.1. It's a 5KB console app that is capable of listing and changing display modes. Just copy qres.exe to your folder of choice and do something like:
modes = %x(qres.exe /L).each_line.to_a.drop(3)
modes.each_index do |n|
  x = modes[n].match(/[^x]*/)[0]
  y = modes[n].match(/(?<=x)(.*)(?=,)/)[0]
  c = modes[n].match(/(?<=, )(.*)(?= bits)/)[0]
  f = modes[n].match(/(?<=@ )(.*)(?= Hz)/)[0]
  modes[n] = { :x => x, :y => y, :c => c, :f => f }
end
puts modes
I'm not very good with regexes, but it works good enough.

A word of advice - apparently you get the list of modes supported by your GPU, not the monitor, so if you try to change to one of them, you might (and should) give user a prompt if he can see anything (and some kind of timeout in case he couldn't).

You mind using texplay? Here's a quick example:

require 'gosu'
require 'texplay'
include Gosu

class MyApp < Window
  def initialize
    super 200, 200, false
    @image = Image.new(self, "heart.png", true)
    @x = 10 # @image pos x
    @y = 10 # @image pos y
  end
 
  def needs_cursor?
    true
  end
 
  def update
    if button_down? MsLeft and (@x..@x+@image.width).include?(mouse_x) and (@y..@y+@image.height).include?(mouse_y)
      puts "clicked" if @image.get_pixel(mouse_x - @x, mouse_y - @y)[3] != 0.0
    end
  end
 
  def draw
    @image.draw(@x, @y, 1)
  end
end

MyApp.new.show

Just replace heart.png with your image of choice! Ask if anything isn't clear in this code.

In fact they're 31 and 63 bit. According to this and to the funky way Ruby deals with negative numbers in hex representation that I don't get at all, at current state exceeding a value of 63 (3F) for side 3 (on 32-bit platform) will result in conversion to Bignum which might slow down the process horribly or even destroy the world (on the other hand, there's a possibility it'll be completely fine!)

Now I can put 4 different textures on a wall:
[http://i.imgur.com/Zyzgxqns.png]
and it has virtually no negative influence on performance, because every piece of wall is still represented by an integer, eg. 0x01020304 means there will be texture 1 put on side 3, texture 2 on side 2, texture 3 on side 1 and texture 4 on side 0 . Proper texture is chosen by only two bitwise operations. And your CPU loves bitwise operations. This kind of representation also introduces a limitation of 255 wall textures per map, but I reckon it's more than enough for a raycasting engine.

I have no clue at the moment, even though I was playing a bit with your code. My notebook's resolution is limited do 1366x768 so I can't test it in proper 1200x900 but I doubt it'd change anything.

I have one more suggestion though about scaling factors. Your game's aspect ratio is 4:3 and you use scaling by width. Run it in 16:9 res fullscreen and the bottom part won't fit. You might either use separate @scale_width and @scale_height factors (this will use the entire screen but with funny proportions) or just scaling by height (proper proportions but part of the screen will be empty).

Hi, I tried your game and must admit it was tricky to get it to work. Some of these things might be related with me using gosu 1.9 and not 2.0 as recommended, but you might want to double check it.
First of all, I had to convert all mp3's to ogg (gosu likes to be fussy about this). Then I got NilClass error in Particle class (line 68), fixed it by adding rescue nil at the end but I don't really think it's the right solution.
The game started, but there's still another problem - most texts don't fit on the screen (screenshots).

Other than that, it's a cool idea that looks good and plays good. I love the particle effects!

So basically, 0x10c in 2D? Neat!