Got it working. The Windows XP/Vista/7 compatible executable is now available for download at the site. Happy Ultimate-Comet-ing.

The Environment Variable problem I was able to fix just as described. On top of that, I needed to get myself a new fmod.dll file through the gosu site because the one I had before must have been the wrong saved link, which solved the second part of problem 1.

As it turned out, problem 2 where Windows said "This application has requested the Runtime to terminate it in an unusual way" occurs because of game keyboard configuration settings that Windows apparently did not understand. The solution was simply for me to delete control_config.yaml from the bundle and let the program initialize and rewrite the control_config.yaml itself, thus ensuring that operating system dependent Gosu::Button constants would not conflict. The original control_config.yaml was created in Ubuntu, so obviously it would not carry over.

Thank you for the quick feedback. Now, on to the Mac Version.

The Ultimate Comet V2.0 Windows Executable has been released on the site. This executable is compatible with Windows XP, Vista, and 7.

Please, first of all, play it. Then, if you'd be so kind, please report any errors on this forum or at the site.

My problems have most likely been discussed by someone else on some hidden previous thread, but as there is no convenient way to search the gosu forums I will raise them myself. The google code site for gosu does provide a wikipage about packaging ruby games. However, to put it simply, it's just not helpful enough for a few small reasons. So, I am taking the advice explicitly stated on that page:

>If you have any trouble, feel free to ask on the Gosu boards. Ocra is still a project in development and everybody can benefit from sharing your experience.

After leaving the blessed land of Ubuntu and venturing cautiously into the dark realm of my Windows partition, I spent hours wrangling with the beast to try and package the new Ultimate Comet V2.0. Unsuccessful, I once again resolved that Windows sucks. But I also resolved to try again, and I need some help.

Problem 1: fmod.dll

I had trouble getting my game to find fmod.dll, and the instructions on the wikipage were vague and unhelpful to me (call me an idiot all you want, but that solves nothing).

I put fmod into a "lib\" subdirectory and compiled it along with main.rb using ocra main.rb lib\*. The wiki page says I must also change the path environment "like this":

ENV['PATH'] = File.join(GAMEROOT,"lib") + ";" + ENV['PATH']

Frankly, I don't know when or where this goes. I don't even really know what it means, and when I don't understand code, it feels like crap trying to use it (ever feel that way?). Furthermore, "GAMEROOT" appears to be something I have to define myself, I just don't know what path it's supposed to be, because it sure isn't something that ruby recognized.

This is assuming that changing the environment variable will solve all my problems.

When I tried compiling fmod.dll along with the .exe through ocra main.rb fmod.dll, Windows even broke from command line protocol and popped up a message saying "fmod.dll is either not designed for windows or it has an error. Blah blah blah..." and then the game would crash with the first attempt to use a sound returning the "could not load fmod.dll" error.

Problem 2: Quitting in an "unusual way"

Even running the source code on Windows was unsuccessful. The game would run, it would get to the menus, but when I try to start up an actual adventure it would crash and windows would pop up saying something like "ruby.exe - runtime error: the application asked (something) to quit in an unusual way."

Turns out, it appears the same exact problem occurred for Dahrkael in Deathly Dimensions (he made a post 2009-12-17 12:55).

Why do my games crash like this when someone attempts to start a level, and not when the game initially starts up? And why Windows, aside from its obvious shortcomings? The source code works just fine on Ubuntu 9.10 and Snow Leopard. Granted, I was only able to test it on one Windows computer so far.

Good news, no more char_to_button_id in the new Version 2.0 release. See above original post for details on the new Ultimate Comet Game. Among many other things, it includes customizable controls. But for the new graphics alone it's worth checking out. A list of improvements is above on the original post as well as at the google code site.

Sounds like fun... too bad I can't run it because texplay segfaults for every single gosu game that touches it over here   |^(

Really wanted to check out that level editor, though.

> w00t.. so I won? .. if we count out the author :)

Uh, only if you're talking about the hunters, :/ the rank goes 1 = winner, 2 = next best, 3 = third best, etc. It can also be figured from the times that the longest prey total and shortest hunter total are the best.

> - being able for hunters to see other hunters, and not just preys .. same for the preys (this could be used to prevent swarming)

The game engine is a "fake" engine, meaning that a higher intelligence (HI) can see all the objects and handles collisions. The hunters collide with each other, but do not see each other because they do not handle their own collisions. This could easily be remedied by passing in the @hunters array with each update or something of that sort. However, the preys do not detect each other simply for optimization purposes, as stated in my first post. There are 100 preys to begin with, and anyone who can figure out some mathematical algorithm that will keep them scattered while actively avoiding the hunters deserves a gold medal. Meanwhile, 100 preys checking their position against 99 other preys is extremely inefficient and my game engine is too simple for me to care about using grids or quad trees

I made the game mini-engine for something quick and unrelated using etherpad.com with a friend. I considered making your said improvements when I decided to use it in AIG, but I also decided I did not care that much and clearly, given the number of entries, no one else did either.

Thanks for playing.

Competition Results

(click on image)
[results.png (22k)]

All participating classes are attached in .tgz along with game and results image.

Further Results

--AmIMeYet--

-Smart Prey: Avoided clustering by ignoring the position of any hunters and detecting proximity to edges of the screen. Preys regularly shifted acceleration to a calculated "smart" direction (instead of a random direction). Reduced the rate of consumption by requiring hunters to take them one at a time.

This one was interesting to watch, similar to watching a formation pattern of a school of fish. It represents a tactic that does not attempt to avoid the hunters, but rather slow them down.

--Dahrkael--

-Smart Prey: Simplest of tweaks to the original file. Instead of accelerating directly away from the nearest prey, accelerated at a perpendicular trajectory. A simple " + 90." Interestingly effective. Lessened clustering and frequently stalled the hunters in circular chases.

While the simplicity was highly effective, it did not make the prey "smart," nor was it particularly clever for a month-long competition. One hour competition maybe, but I was not impressed by so little effort getting such a high rank. The method did teach a thing or two about simplicity, making us all smack our foreheads, but when one is watching the single remaining prey spinning the hunters in an infinite merry-go-round loop, one isn't thinking "this is genius," but rather "this is boring." I cannot justify counting the lucky rounds that chanced to become infinite loops on the scoreboard; the recorded time is the average of the times when rounds went smoothly, unbiased. If a much more complex class had created infinite loops as frequently, I would happily count it as the winner. But part of the purpose of the competition was to share clever code. Thanks for participating anyway, however. I must commend you for submitting a quick and easy high-scoring class in the face of everyone who didn't participate for "time and schedule" constraints.

--Ippa--

-Smart Prey:  Ignored the hunters and any other obstacles to move in a oscillating pattern either left/right, up/down, or diagonally. Looked similar to AmIMeYet's prey, except this prey wasn't as smart, but the coding was simpler and more clever.

Funny to watch the hunters fail at each swipe to nab the prey that isn't even trying to dodge. Represents the same tactic of distracting the hunters for as long as possible without actually running away. Interesting, but not exactly exciting. Nice job, though.

-Smart Hunter: Gathered to the center of the screen for a few seconds before splitting off to catch the preys in the default hunter mentality. The idea was to cluster the preys as much as possible to increase the rate of consumption. Attempts were made to further improve the hunter's skill, but apparently they didn't work and were commented out before submission.

Showed effective results for the default prey, but the smart prey and dahrkael's prey weren't as easy to cluster, and AmIMeYet's and your own prey did not operate around that mind setting. It was a reasonable approach that did need representation in the competition. Unfortunately, as it turns out, herding the preys is not as rewarding as one might have hoped.

--phelps.db--

-Smart Prey: Used mathematical functions to skew the angle of acceleration. As the nearest hunter grew closer, the prey would accelerate at an increasing angle to the right. Enabled the prey to dodge hunters homing in.

Simple, but clever. I must admit this class is the most interesting one to watch. I enjoyed watching four or five hunters zone in on a single prey, but be impossibly thwarted by its ability to make subtle, seemingly precise movements that keep it alive for several seconds even when completely surrounded. If dahrkael had more time to work, I'm sure something like this would have been the result. Although, I feel a little guilty winning the competition when others of you spend more time and effort on your classes.

-Smart Hunter: Calculated the rate of change in the angle between itself and the prey to predict a more extreme angle of acceleration that would be more likely to make its path intersect with the prey.

Slightly more complex than my smart prey, yet still relatively simple and clever. I cannot say it is an absolute winner because it had only Ippa to compete against, but I think these were some all around smart hunters.

I have discovered your problem.

When you declare:

diff = angle_diff(some_angle, @dir)

You leave open the possibility that some_angle = @dir, which would make diff = 0
A couple of lines later, you include this calculation in an expression:

(diff**-1)

Which is the equivalent of saying  1/diff.
1 divided by 0 is infinity.
Turns out, this really jacks things up. I'm actually surprised the ruby interpreter didn't spit out an error.

Solution: after each declaration of diff (one for each cardinal direction) add a line of code so that all four occurances look like this:


diff = angle_diff(cardinal_direction, @dir)
diff = 0.1 if diff.abs < 0.1  # 0.1 is an arbitrary range which I use
                       #simply because it includes 0. Could be 0.01


Did this help you out?  ;)

Okay guys, I feel really stupid right now because I didn't realize there was a message inbox for forum users xD
I usually don't try to look for extra stuff like that.

Fortunately, this might just solve the cheating possibility that I kept bringing up. If everyone can submit their classes through a private message like AmIMeYet, then all will be well.

Hey, I'll be a little lax on the deadline. I don't want people to think they can't submit classes just because they're a day late; take all the time you need.

ippa, I don't really want to give out my email publicly, so is it possible for you to do that PM thing too?

AmIMeYet, I'm looking at your class right now and getting the same problem. I'll get it to you soon.

Attach the class to a post. I'll delete/change the attachment when I check it out, and hopefully I'll have it back to you in time for necessary adjustments. I really don't think anyone is going to cheat (cheat? Really, people? We're better than that). If it turns out to be some obscure error with your setup and it all works out fine on my end, then the class can still compete -- after all, the competition will officially be held on my end.

I scanned through my code, but I didn't find any lines around the level loading logic that said "@game.kill_yourself"

You will have to be a little more specific about the error before I can help you, i.e. what's your OS, version of ruby (have you tried both 1.8.x and 1.9.x), and a more directly quoted error message.

My one stab-in-the-dark hypothesis would be that maybe the game is having trouble opening and reading the file "level1.txt," or any "levelx.txt" file for that matter.

Is anyone else experiencing problems?

The deadline has now been extended to Tuesday, December 22

Hopefully this will allow enough time for more people to submit.

V1.1.1 uploaded. Attached to original post at the top.

Changelog: new to V1.1.1

- Added compatibility for ruby 1.9.1

See above 2009-9-20 post or attachment readme.txt for V1.1 changelog

Submit your custom levels created in the Level Constructor on this forum. Good levels will be added to subsequent game releases.

The deadline is created for 3 reasons:

1. There has to be a cut-off just so that people will actually get going on their classes
2. There needs to be a 24-hour period for people to submit their classes to help minimize the time window for someone to cheat off of submitted classes. Again, however, I really hope cheating isn't a problem anyway. There's seriously nothing gained from doing so.
3. I am personally going to at last have plenty of free time starting on the 19th to run the competition.

There is, however, no rulebook stating the deadline. Nobody's going to cry or sue if I move it back a few days. Since you are one of the few people who have expressed interest in participating, you are given a large percentage of popular vote over silent participants. I will push the deadline to the 22nd if by tomorrow no objections are raised. Will that be enough time?

All:
Classes still can be submitted before the deadline if you are confident that people will play fair or else if you don't care whether or not anyone does cheat. In fact, there could be a follow-up "cheat" competition where people can submit "even_smarter" classes based on the results of the original competition. The outcome of AIG depends on how many people participate.

The game size (uncompressed) is about 9MB. The soundfx folder takes up 6.2MB of this, and 2.5MB go into the images folder.

I could probably re-upload the game to this forum (unless there are objections) if I split up the stuff bigger than 5MB (the max). However, the task is not very high priority right now unless others voice a desire to check it out and help catch bugs.

Github or other repositories would be excellent places to host this project, however, I don't want to rig up a dying project to one of those sites - my development on Dimensions is coming to a close. I probably should have "gitted" it long before now.

The details of the error can be found here.

When I used "gem -v" it returned 1.3.1

As an aside, when I tried to play selene, banister, it spat out a segmentation fault in texplay of some sort.

Geez. None of the games seem to be working for me.

Ruby 1.9.1 on Ubuntu 9.10 = awesome.

I just managed to install ruby 1.9.1 and got it working with Dimensions. Things work so much better now.

Previously, I was using a crappy windows XP computer. The switch to Ubuntu on a new and relatively inexpensive computer made vast improvements. With the new version of ruby, things are even better. There isn't even any slowdown when things are exploding (which is amazing; the explosions were very costly to speed). I recommend to anyone who bothered to download the ultra-improved DimensionsV1.1 before the server crash to try it out with 1.9.1 if you have experienced problems with slower fps (slower than 60fps).

However, one adjustment will have to be made. In the file opts_handler.rb on the first line:

require 'ftools'

must be changed to something like:


if RUBY_VERSION =~ /1\.9/
     foo = 9  # do nothing, essentially, unless here
               # you want to say something like require 'fileutils'
               # "ftools is deprecated, use fileutils instead"
               # is what the experts were saying with 1.9.1
else
     require 'ftools'
end


Don't expect me to know about any other problems. I have received disappointingly very little feedback about V1.1

It appears that no such gem "opengl" exists.

I tried to gem install ruby-opengl to see if that was the same thing, but to no avail, for it tells me that it fails to build the native gem extensions and then proceeds to spit out a lecture-length error. I'm on Ubuntu 9.10 with ruby 1.9.1, if that says anything to help the problem, although it did not work with ruby 1.8.7 either.

Deadline: (I already posted this, but it was destroyed in the server crash)
Tuesday, December 22, 2009 (no specific time range/zone - all 24 hours of your day to submit)

All entries may be submitted before this deadline, however, this is discouraged to prevent others from receiving ample time to cheat and/or plagiarize other code. It is the expectation that this should not be a problem anyway.

The results will most likely be posted within a week after the deadline. After submitting all entries, a contestant can download other entries to see the results for themselves, but "even_smarter" classes submitted based on these results will not be eligible for the original competition.

The calculus is more conceptual than complex. I estimated the rate of change in angle that the hunter must accelerate toward by using the difference between the current calculated angle and the previous calculated angle. This is a kind of differential approximation - quite simple really. I then added this change in angle to the current calculation so that the hunter can essentially "predict" the next angle it must accelerate toward.

Example:
The last angle (in the last frame) from hunter to prey = 36
The current angle = 38
Rate of change in angle in degrees/frame = current - last = 2
accelerate_toward(current angle + rate of change)
# Using a slope differential (the rate of change) to predict
# future values of the angle is very simple calculus

This helped the hunters zone in on the preys and effectively killed the "merry-go-round" effect of hunters orbiting the prey. I ended up multiplying this rate of change by 4 because that improved testing results. The word "calculus" might scare some people away from the competition, but I was not implying that my coding had any true complexity to it. That was just a fancy way of describing a simple modification ;)

Okay, I've fixed my smart_hunter.rb and it is now attached here as a .txt file.

Description: The time it took to consume the preys was reduced by about 10 seconds using differential approximation in the angle to accelerate toward. I've included as a convenience the drawing of little white boxes to show the angle of acceleration, not velocity, of the hunters (this is not required in your own games).

This did not take me very long to make, and it does not specialize at all. Some improvements you can make to your own smart hunters would be predicting the path of motion instead of the angle to accelerate toward, specializing behavior at edges and corners, ignoring the "closest" target and focusing only on one until it is destroyed, etc.

Change the name from '.txt' to '.rb', plug and play.

Note: this "smart hunter" did well against the regular prey, but it was terrible when put against the "smart_prey." Keep in mind some tactics don't work in all situations. You may consider submitting multiple smart hunters/preys for the second part of the competition when competitors will face each others' classes.

Gee, that sounds just like what I tried to do with Dimensions. I even took the time to create and super improve the level editor specifically for my game. Way better than a text editor. And guess what? No takers. Just EuphGuy, but I know him personally.

I'll make you a level just so that I can show that I actually appreciate the work other people put into their projects to make it community interactive. In fact, I might have suggested that you borrow my level editing setup from Dimensions, but hey, that obviously didn't get anybody interested in my game, so maybe it won't help you at all to use it with your game.

I will make time to create a level when you release the game, text editor or no text editor.

Artificial Intelligence Games 2009

Purpose: A purely recreational competition to battle each others' coding skills. Will promote and share clever Artificial Intelligence tactics for inspiration and use in other Gosu games.

Game:
The attached mini-game involves five hunters chasing and overtaking 100 preys. Once the preys are eaten, the game resimulates. Very simple, allows a very basic knowledge of programming tactics while still leaving plenty of room for clever code.

[Screenshot-1.png (15k)]

Procedure:
   1. Download and observe the simple mini-game as provided.

   2. Redefine one or both of the classes "Prey" and "Hunter" (prey.rb, hunter.rb) in the given download and replace their respective files to make the game work with your new classes.

   3. In your own classes, try to either extend or shorten the average lifetime of the preys. Make the Hunters "smarter" or else make the preys "smarter." If you submit a Hunter class, your scoring is based on how quickly the preys are consumed. Likewise, a submitted Prey class is scored on how long the preys can stay alive.

   4. Submit your new class(es) on this forum thread the day of the deadline (TBA).
   (edit) hey, you can just send me a message containing your class(es) too

Description of a Few Shortcomings to Hunter and Prey:
The hunters are fast, but dull. They can chase down the preys easily enough, but sometimes they get caught in a merry-go-round with one prey in the center, which makes them spin in circles until another hunter knocks them away. They only ever accelerate toward the nearest prey at any given moment.

The preys can avoid capture through agility, but they run in an unorganized straight line away from the nearest hunter. Often, they cluster in the corners of the screen allowing the hunters to destroy many of them in one swoop. They only ever accelerate away from the nearest hunter at any given moment. (They do not detect or collide with one another due to optimization necessity).

Special Keys:
The game runs itself through "ruby main.rb" but once the simulation begins, the display can be hidden or shown by pressing "D" and the game can be resimulated at no cost to the average time by pressing the space bar. Press the escape button to quit.

Specs and Restrictions:
  - There is no real reward to the contest. It should not take much time to submit a simple improved class, do it just for fun and to face off with other competitors' classes.
  - Anyone can join, there is no official signup. Just submit however many classes you want on the deadline. Competitors are discouraged from submitting code early to avoid plagiarism (other players might steal your AI ideas and then submit their "own" class before the deadline).
(edit) sending me a private message containing your class solves any cheating problems. I didn't realize this at first. Do that instead xD
  - You are permitted only to change the classes Prey and Hunter (prey.rb, hunter.rb)
  - You cannot adjust the acceleration, radius, or other such set values in either class
  - You cannot "stupefy" or else make "less smart" any class. There simply is no point: any and all classes you send in will be tested separate from each other.
  - Average time is measured in seconds relative to game loops and is unaffected by the performance of your computer.
  - Entities cannot "warp" in any way whatsoever (deliberate setting of x and y position)
  - Let's be honest: The line between clever code and cheap loophole is obvious. Cheating at this competition is about as impressive as playing chess with a broom.
  - Scoring will be based on how well your class stands up against the default counterpart and then against other competitors' classes. All submitted hunter classes will be pitted against the default Prey class and vice versa. At the end, some of the best classes of different competitors will be put against each other.
  - The deadline has not yet been finalized, but is anticipated to be toward the end of December. Plenty of time.

(edit)
Deadline:
Tuesday, December 22, 2009 (no specific time range/zone - all 24 hours of your day to submit)

All entries may be submitted before this deadline, however, this is discouraged to prevent others from receiving ample time to cheat and/or plagiarize other code. It is the expectation that this should not be a problem anyway.

The results will most likely be posted within a week after the deadline. After submitting all entries, a contestant can download other entries to see the results for themselves, but "even_smarter" classes submitted based on these results will not be eligible for the original competition.

Note:
I'm not pretending to be Ludum Dare or anything. I just thought there would be no better way to promote cool code than hosting an AIG. Please post a reply if you wish to join, although it is not required. If it turns out nobody cares, then I'll just shut it down and get out of the way.

If this actually works out, however, there could be more AIG in the future with more elaborate scenarios. Just take a day or two and improve the Prey/Hunter classes. Use my own "smart_prey.rb" as an example - an addition of two or three lines of code increased the preys' lifetime by 30sec. The month-long deadline is just to allow anyone short on time to be able to submit.

Inform me of any errors, if you want fewer restrictions, or if you need help debugging your own classes.

class Entity

Location: entity.rb

--Members--
x, y        read only
vx, vy    read and write, but read only for competition purposes

--Public Class Methods--

new(game)
  game - the Gosu::Window instance being used.

--Public Instance Methods--

move
  Call this function exactly one time in the update method of its subclasses Prey and Hunter. No exceptions. This really should have been called by GameWindow rather than the instances themselves, in fact.

find_closest(targets)
  targets - an array of the counterpart entities, ex: hunters would call "find_closest(array_of_preys)"
  Iterates through targets and returns the instance of the closest Prey/Hunter. Use at your pleasure.

accelerate(dir)
  dir - the angle to accelerated toward.
  Call this function once or not at all in your own code. Do not call it more than once or else the submission is illegitimate.

class Hunter

Location: hunter.rb

--Relevant Instance Methods--

update(preys)
  preys - an array given by GameWindow of all the preys on the screen. Use at you pleasure
  Probably the only method intended to be adjusted in this competition for Hunter. Initialize may be adjusted to accommodate new instance variables, etc. You can find the closest prey in here via find_closest(preys). Note that the code where preys are eaten should not be adjusted to work on more than one prey per cycle and the distance < 5 should not be in any way changed for a larger eating radius.

class Prey

Location: prey.rb

--Members--
eaten      read, boolean for whether or not the prey has been destroyed

--Relevant Instance Methods--

update(hunters)
  hunters - array given by GameWindow containing all the hunter instances. Use at your pleasure.
  The only method that really needs tweaking in this competition. You may consider using find_closest(hunters) and accelerate away. Use "move" exactly one time and "accelerate" at most once or not at all. Always have !@eaten as the last line of this method to tell GameWindow that the prey still exists.

Ippa:

Yeah, that was exactly the Captain Ruby collision that my game used to have before I switched to bounding box.

> This would stop the sprites head from going through the roof. The problem with 4 (or more) pixels is that if terrain
> has something very pointy that you jump into .. the player can get "stuck", since (when jumping forward) the
> rightmost pixel could hit something solid from above.. while the bottom pixel is in the air.

I knew that pixel collision was circling the drain when my dude got impaled by a platform.

The combination of CC and BB to create a collision mask for an entity sounds like a good idea.

I admit that I cannot offer any ingenious collision engine substantially better than what Chipmunk has to offer. I just supposed that, from what I understood about your game, BB collision would be a useful little trick to implement as opposed to pixel iterations. I am an advocate of neat little tricks like these that provide very practical framework in few lines of code. As brilliant as chipmunk may be, I personally prefer to "learn" and "own" my code rather than plug in a "do it all for me" library. I feel just as reluctant to resort to chipmunk as I would hiring some technician to fix my computer because I'm too unlearned to do it myself.

Because Chipmunk is open source, it's not so much of a big deal. It saves a lot of time for someone who has higher priorities than setting up an original collision framework. I'll probably wind up using it sometime in the future, but not until I have some kind of idea how it works.

You may consider bounding box collision. I implemented it in Dimensions because originally I was using the collision detection in the Captain Ruby Gosu example game, which essentially plotted four pixels on the character for collision. This was ineffective as it allowed my own character to get impaled on ledges by blind spots. Instead of filling in these blind spots with more pixels, I looked at http://www.gamedev.net/reference/articles/article735.asp.

You only need four numbers to define a rectangle - two x's and two y's. From the values of two rectangles comes only four check statements to tell whether the position of one box intersects with another box/pixel. This turned out to be a very efficient way for handling collisions in my game.

From what it sounds like, this won't be applicable to collision with your map, but your player and other entities can use this method to check their boxes against the map's pixels rather than 50+ of their pixels against 50+ of the map's pixels. Much fewer pixels to check. Does this help any?

I have made a slight improvement to the source code.

The physics engine behind the black holes was originally thrown together with duct tape and chewing gum. I have fixed this engine and the holes now present more realistic manipulation of the player. This realistic approach now also makes them a little easier to live with, literally. I beat my old high score by 1 level.

Try it out if you want, compare the two engines. This is not a major update, and although the source has been updated, there is not yet a new executable download available on the site, but it has been an inconsistency that bothered me ever since I slapped on the old method.

Never underestimate the power of math.

I'm still open to comments from anyone who's trying this game out for the first time.

The music problem doesn't sound like the game's fault. I did very little tinkering with the music in this latest version. Try playing other gosu games to see if you get the same problem.

The level constructor keys are not configurable like the gameplay keys. They operate from the Gosu::Button module and Gosu.char_to_button_id(). It is possible that there are some inconsistencies across operating systems.

These issues cannot be confirmed until someone else downloads V1.1 and gives a similar complaint. If it turns out to be just your computer, then there is nothing I can do to the game that would fix this.

Deathly Dimensions has returned as version 1.1 with many improvements that directly solve the inconveniences mentioned by beta testers.

New to Dimensions V1.1:

Control custom configuration - set any input buttons to move the player.
Resolution Independence - supports 640 x 480, 800 x 600, and 1024 x 768 as well as fullscreen for all of them.
In game tips deactivation - annoyed by all the textboxes that keep popping up? Fear not.
Option saving - no having to reset your preferences every time you restart the game.
Level Constructor accessible through game - found in the main menu.
Test mode in Level Constructor - Test your levels through the editor with cheat mode activated.
New levels - Play 17 adventure levels with difficulties ranging from easy to intense. Special thanks to EuphGuy19 for contributing two of these levels.
Selectively improved graphics - not all, but some graphics have been modified. The dog looks 1.9824e203 times better.

I hope that with these improvements, all of you will become more interested in the game and perhaps post some custom levels. Sorry that I did not yet get to optimization, but DD is starting to grow smaller in the rear view mirror. If I have time, I may get to it, but in the meantime I hope that I have made plenty for you all to play with.

Play by entering "ruby main.rb" into the command line.

Inform me of any gross errors I may have committed and I will crank out a V1.1.1 to solve them.

The download is attached to the first post of this thread.

Another issue: pushing mirrors over spots where destructible tiles used to be causes the mirror to disappear. This makes level 55 quite impossible.

Level 35 is broken. The red and purple lasers aren't properly reacting with the blue portal.

You'll find the big picture in the file task.rb. The Task class is called in various other places of the code such as in player.rb or game.rb.
Let's say I want to restart the level after the player dies. I don't want everything to snap right back to the beginning just as soon as health hits zero, I want to give the user a second to say, "Oh @#$%!" and allow a smoother transition back to the beginning.

Task.new(self, :wait => 240) { restart_level }

This sets a "time bomb," if you will, that will explode in 240 cycles (4 seconds). When it explodes, the block { restart_level } will be executed. Here's another example:

Task.new(self, :wait => 150) do
    # reset everything after the player dies
    @player.respawn
    reload_course
    @objects = []
    @player.warp_to(@course.warps[0])
end

Everything between "do" and "end" will be executed after 150 cycles. There are many other applications for this other than restarting a level. Ultimate Comet uses them everywhere when telling powerups to disappear, alien ships, black holes, and comets to appear, and the player's ship to reappear a second or two after dying.

> do you think auto-saving at doors would make it too easy?

I like to design my levels so that this is not necessary. The ideal approach is something like a "Zelda: Ocarina of Time" dungeon where progress is not linear and is therefore easier to get back to where you left off when you quit. In my game, you'll notice in a few levels such as level 7 the doors are conveniently placed so that it is easy to move ahead when you've already died getting that stupid key. Hopefully, everyone has read that one textbox explaining that you retain your keys after dying.

Levels should be designed after this manner. In the Level Constructor, you can place as many of the same door as you want; they will all take you to the same warp point. Do the player a favor on really hard levels and throw a few doors in strategic places like I try to do. Once that gets taken care of, post your levels here so we can try them out.

> I'm wondering, what was the bottleneck in the game when you profiled it? The collisions?

To be honest, I couldn't quite puzzle out the profile too well. It did tell me, however, that tons of time was spent on the draw method, even though it has been optimized to only on-screen images, and that tons of calculations were going on. When I disabled #draw and ran the game, things sped up. When I disabled the inter-object collision, things sped up. When I play a level and come back to the start after blowing up bad guys and collecting powerups, things have sped up.

I run into complications when I think about how quad trees or octrees might be implemented, such as a guard's patrol, a turret shooting bullets far and wide, and objects falling off cliffs into lower parts of the level. I wish I could find just one little rogue line of code that, if repaired, would really boost things. I played the game on my friend's Mac and everything ran beautifully. Heck, let's all just get Macs   :)

> I have also looked through the code, I like the Tasks bit.

The Tasks bit are mostly thanks to rmphelps who showed them to me in the early days of Ultimate Comet when I was I naive, ignorant programmer, head spinning with questions. After I gained proficiency, I implemented them on Ultimate Comet. I can't imagine living without them, there are so many things in a game that need delayed execution.

You can also multiply it the vy/vx by a constant less than 1 each time it hits the floor/wall. This will dampen the bounce until it eventually hits zero and the shield rests on the ground just to make things look lifelike. If you don't do this, the objects will bounce unceasingly reaching the same peak height with each rebound.

It's just a suggestion, though. I don't know which you would prefer.

For those of you who have seen the source for Dimensions, you may have noticed a clumsy #check_collision method in game.rb. The course-interaction collision detection is separate and more advanced than this one, which is inter-object collision. Ideally, it verifies the object identity, cycles through specific other object(s) to check overlap, and executes code accordingly.

This could use optimization. Does anyone have specific ideas? I would try chipmunk, but unfortunately I'm running on windows which means that downloading and setting up any intelligent piece of software is a nightmare. I'm trying to make energy-efficient "green" code out of Ruby rather than updating and downloading new stuff.

New custom level to enjoy:

Weighty Decisions

Difficulty: ****
Length: **

Thanks for the feedback :)
Even though there are just two screenshots, I like your new editor. A button menu bar and prompt pop-ups is definitely what my editor is needing, but making a really good user interface is also really, really hard.

>-Bad graphics   - the game would be so much better if you just notched up the detail a bit

I started off just carefully bitmapping all the images in paint. Extremely dull. Later, I discovered gimp and used it on a few images. I just think that creating images is very boring and has little to show off for, unlike good code.

>Bad key-layout - now, I don't know how this is on your keyboard, but on mine it's all a bit cramped there
>I also got FPS as low as 20 :(    but that's probably just my laptop complaining.

I don't have a laptop, so the layout isn't too bad for me. However, I never got as low as 20fps except maybe when something was exploding (which only lasts a second or two) and my computer is certainly not top-of-the-line.

hima had that same problem with Ultimate Comet.

For those of you who don't know, the game window is 1024x768. Sorry if this is a problem, I probably should have started off with 800x600 or something.

I thought about that as well, but my Mac using friends didn't mention it to me, so either there's a key on the Mac that Gosu will read as "Ctrl" or else they just hacked it without telling me. For anyone else who runs into this problem: the change can be made in player.rb under the method #check_buttons.

By the way, if any of you get acquainted with that Level Constructor, post your levels on the forum so that we can all try them out (that's one of the best parts of my game). I'll even take the best custom levels and turn them into official levels to be sent out with versions of my game and I'll put your name in the credits. How's that sound?

Okay, I've just attached the game source package to the original post. Sorry if it's huge, blame it on the music. Hopefully, though, it will be worth it.

Instructions:
Untar the .tgz package and enter "ruby main.rb" to play the game.
To use the Level Constructor, enter "ruby init_editor.rb"
I recommend that you view the readme.txt before asking me questions about how to play.

Enjoy

The game will run at normal speed on my computer as long as the levels do not have too many objects (dogs, guards, lava, items, etc.) and as long as not too many tiles are on the screen at a given camera position. Thanks to the advanced tile update method I'm using, levels can be as big as they want to be tile-wise without slowing down.

What this game really could use is better coding on my part; more of these kinds of efficient methods are needed. I'll look into Ruby 1.9 and Chipmunk, but in the meantime I'll try to post some code for suggestions as soon as I can.

The entire game is about 8MB, most of that size coming from the music and soundfx (hey, making soundfx is a fun break from coding all the time :). If that doesn't bother anyone, though, I'll go ahead and make the whole fat thing available as an attachment sometime soon.

A year or so ago I received a revelation when I discovered the relative simplicity of making an adventure game such as Gosu's own Captain Ruby. And so, following the instinct that many of us programmers possess to chase after a new idea, I built my own game off of Captain Ruby.

Now, a couple thousand lines of code later, I've finally figured out, with EuphGuy19's help, what to call it. We decided on the name "Dimensions," and he added "Deathly Dimensions."

I would say that two words to describe it are be "fun" and "hard."

Those two words also match the description of the early Super Mario Brothers games, to which the physics of my game are most similar. It's a one player adventure side-scroller where the unnamed, faceless character must run, jump, and shoot his way through dogs, turrets, guards, lava, and gravity. There are a few good items to collect on the way such as coins (very original, I know), super jumps, keys, and fire bullets. Instead of tunnels as in Mario, there are doors you need to unlock and enter to progress in the game.

[screenshot_lv7.jpg (67k)]              [screenshot_lv1.jpg (198k)]             [screenshot_cs4.jpg (76k)]

Simple as the game may sound, there are plenty of novelties not seen in Captain Ruby, some of them very necessary to keep the game working. For example, my bro showed me a new bounding-box collision method that we now use as our engine to keep the entities from impaling themselves on walls. We also figured out an advanced tile drawing/updating function that makes the game only worry about on-screen tiles every cycle.

I got quite a few complaints from friends about the intense difficulty of the game. But dumbing down my levels to suit their experience would be no fun  >:)  I didn't know what to do until I saw AmIMeYet's Captain Ruby Map Editor. I snatched this nugget and used to to build a much more complex Level Constructor for my own game, allowing the user to create his/her own levels, set his/her own traps, and have his/her own fun.

[screenshot_editor_select.jpg (56k)]           [screenshot_editor_cs1.jpg (108k)]           [screenshot_cs1.jpg (99k)]

Unfortunately, my head hit the ceiling when the game finally overflowed with "stuff" and started to slow down at certain stress points from its original speed of 60fps. Those dang array iterations! Of course, my Windows computer is a piece of crap, but I imagine many others are also in my unfortunate position and don't want to wade through lag time. I'm not a pro at this, so I have no doubt that if I make the game any bigger, the code will get way too messy.

(edit) I now use Ubuntu and I highly recommend it over Windows for programmers.
(edit) I tested the game with ruby 1.9.1 and things worked much smoother. I recommend it for anyone experiencing slower fps with this game.

The source package is attached as a .tgz. I highly recommend you view the readme.txt just so that you know how things work.

(edit) current attachment is V1.1.1. See readme.txt or else further notification posts below for changelog.

I assume that you are using the windows executable download. There is a reason why the window might not be showing:
When I compiled the RBA into an executable, I created it so that no DOS window would open when starting the game. This means that "puts" and any error messages won't be applicable. I'm not sure if this is the reason; I have not seen the problem you described.

If anyone else is experiencing problems, let us know. We don't want to hand out junk to everybody.

[front_screenshot.png (200k)]

*UPDATES*

Version 2.0 has been released as an executable download for Windows XP, Vista, and 7 on the google code site - July 30, 2010

Version 2.0 has been updated to the google code repository. - July 28, 2010
This new release includes:
- Drastically improved graphics through Blender
- Improved sound effects
- New smooth menu user interface influenced by my iphone programming experience
- Ability to enter high score names
- All new singleplayer mode: Star Fleet
- Customizable controls (this means you, gamepad users)
- New options allow fullscreen/windowed, volume control, control configuration
- Gosu logo intro (made it myself)
- Are you still reading this? Go download it.

This is a one to four player space shooter game created with Ruby designed for a number of different battle or adventure modes.
Go to the Google Code project home page for downloading and more information.

This isn't a simple, written-in-a-few-seconds type of Gosu game. I spent a while on it making music, sound effects, images, and a whole lot of fun code to play around with. Hopefully, those of you who try it out will be entertained.

I had fun making and playing this game with help from my brother; I'm relatively new to programming.

(Edit) not so new to programming anymore - July 2010