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.

                          

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.

                     

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.

Wow, can't wait! Blame it on both the screenshots that look totally unlike Mario or CptnRuby, and the details on your collision and scrolling :)

Very Nice,Would like to try it out sometime

If you are getting some slowdown then you could try Ruby 1.9 as Ive read that is has better efficiency than 1.8.6 ,thats assuming you are
not already using V1.9 

Are you going to upload it here?as you can attach files :)

I would love to checkout the source code for it

I am also making my own game based on Cptn Ruby called "Arthur's Adventures"
which is in the Gosu Showcase,there are a few screen shots of it at the moment,will add a playable demo in few months

I was having some issues with collisions slowing things down, I used chipmunk to deal with collisions just for speed sake.

does look good

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.

>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.

I don't know if you're already doing this, but a trick to avoid the slow down when a level has many objects (items, enemies and such) is to "freeze" somehow these objects until they are close enough to the main character (usually a portion a bit larger than the screen), so you don't run the update method in them.

also dont draw anything that is'nt in the screen. I ran into that mistake.

Also if you want to go really high-tech and improve your speed learn 2D quad trees!

Yes, I was one of his "beta testers" of this game. I remember the game to be quite difficult and challenging when he had me first play it. Now, the game has become a little easier for me because I got used to the controls and what not.

However. I will say that this game doesn't quite resemble Super Mario Bros. (at least the original) that much, because if I play your game, and then immediately switch to Super Mario Bros., the control feels different, as if Super Mario Bros. is in slow motion compared to your game, but that's just my opinion.

Hey Maverick

do you have an example of 2D quad trees

I would love to look at some code to see how 2D quad trees work

Shinobi Chef

a simpler way than resorting to quadtrees is just to divide your map into a bunch of quadrants and have objects only collision detect against objects in the same quadrant

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

I like the movement, plays very smooth! Just like holding down the space bar etc., very polished.

First quick suggestion, you should check both alt and ctrl keys though. I had to stop playing because I didn't have a right ctrl key on my Mac, and it's too late to hack the game right now :)

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?

Well, technically, nothing prevents me from plugging in a USB keyboard that has two ctrl keys :) I just don't have any. And even with the alt key, I intuitively tried using the left one. Not sure why :)

But I'll hack it to work with my gamepad, harr :D

Hey

Thanks for uploading the source code,

Though I got a problem running it,when I run main.rb it loads the title screen but it is minimized,how do you stop it doing this?
Im running it with Ruby 1.8.6 on vista with Gosu 0.7.13.2

That can happen when the window resolution is larger than the desktop resolution, and the window wouldn't fit. It has been on the ToDo for a few versions :(

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.

You can work around this with the new screen_width/screen_height methods, but only if your code is resolution independent. Or you can turn on fullscreen. Or, well, just poke me until i fix it ;)

Ah, nice game overall, but I can't help but notice these 2 shortcomings:
-Bad graphics   > the game would be so much better if you just notched up the detail a bit
-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.

Really liked the gameplay though.. I haven't played it much but it behaves quite professionally.
Also liked your tile-drawing method. It's way better than what I have in my latest (not released yet) version of the map-editor, where I tried to optimize it too.
I had it simply call 'next' if it was out of the screen, but yours is way smarter!

I also like it that you used my editor as a base for yours :D  .. I have a better version sitting on my hard-drive, if you want to take a look at it..
( ..see screenshots.. )

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.

A new level for you tastes :P

Pillars of Doom!

>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.

Yeah, the pop-up is just a static image with some text though :( .. still.. a nice idea in theory.

>    >-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.

I'm just saying, a few upgrades to your sprites can really make a game jump out. And if game quality improves, so does one's opinion about the underlying code! (really, the human mind is sooo easy to fool!)

>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.

Hah! I beat you at not-top-of-the-line'ness then! XD

Haha, yet another level that I created for you guys to enjoy!! Here is a little bit about the trouble with this level. So this level is based on a horizontal layout, and I needed a way where a player wouldn't be able to cheat and just fall to victory. So I devised to use lava platforms, which had random lava placed throughout, however, I noticed with the placement of this lava, the game lagged horribly, so thus I replaced ALL of the lava with death pits and color coded the course. So here is the official description of this course.

Welcome to Skyholder!! Where you're enemies have trapped you within the realm of the sky. Since you're in the sky (of course) the sun tends to get a little... how should I say this... HOT. And you must avoid touching the red bricks at all costs or you will die instantly from the heat that the bricks are giving off. Travel your way down the course, until you reach the bottom where you will find the key, and the door to freedom being guarded by 4 guards who don't have any patience, tolerance, caring, or IQ for that matter.

Please enjoy, Skyholder! 

Hey Thanks for the Bonus Levels

I got around the minamize thing by  increasing my screen res to 1280x800

Thanks again for the source code too,ive had a quick look at it,will look at it more later on
Im sure I can learn a few things from it

Have you though about adding gamepad support?

Have you had a chance to play Arthur's Adventures yet?

I was playing your game earlier today,you have done very well with it

any new features you planing to add?

New custom level to enjoy:

Weighty Decisions

Difficulty: ****
Length: **

This is most impressive.This should be one of the top examples made with Gosu thus far.

Yeh I agree,its currently Project of the Day on the main Gosu Page!

How does a game qualify for Project of the day?are they chosen at random by a script or something like that or are they manually selected

Keep up the great work man

They are randomly selected from the topics in Showcase which have a screenshot. Congrats to both of you for winning so quickly. :)

by winning so quickly you mean our games where in the project of the day?
if so when was Arthur's Adventures the project of the day?

I think just one day after Deathly Dimensions. Maybe your browser had the front page cached :) But this thread is about DD.

So I finally messed with the controls and was instantly hooked to Level8. I also still like the visual (non-)style of the game :)

Some suggestions, do you think auto-saving at doors would make it too easy? ;) Also, since I always confuse the buttons, I could have used a visual indication of whether the player is walking, sneaking or running.

I have also looked through the code, I like the Tasks bit. I'm wondering, what was the bottleneck in the game when you profiled it? The collisions? Because they already look better than the usual O(n^2) that is so easy to write ;)

> 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.

For those of us too busy to dig into your code, could you explain these Tasks? Code works too.

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.

So its like a timer just with the ability to perform a command when reaching zero.

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.

Well, there is some issues that I have noticed when I was attempting to use your game.

1 - The music would stop playing on certain levels, and wouldn't come back after that level was played; a restart of the game was required.

2 - The keys on the Level Constructor aren't working, as if I had to pre-set the controls to use the Level Constructor, just like the game. *the default controls are set to nothing so when one attempt to plays, the can't do anything except fix this problem :P

Now I don't know if this is my computer or... yeah. I want to create levels again, but I don't know what the problem is.

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.

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

Well, I must confess.. I haven't actually tried your game yet I think.. :(
How big is the file? I might be able to *temporarily* put it on my server (my host frowns upon it though)

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.

I changed the max upload size back to 10 MB, feel free to attach it, I will also set up backing up of attachments after all. :)

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.

i got a "runtime error, this program wants to terminate" or something like that when i clicked "level1.txt" to play it :/

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?

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

thats the error. Happens when i try to load any map (level1.txt, level2.txt, level14.txt, etc).
Im using ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] (yes, im cool) in WinXP SP3 and lastest gosu.
any idea?

Ouch. Sounds like a pretty bad error. Are you running the game from command line or .EXE?

source from command line.