Forum
Ruby 1.8 used "green" threads, that means they were simulated inside the Ruby process.
Ruby 1.9 on the other hand uses OS threads, so it's supposed to take advantage of multiple cores.
Here is an example apillet wrote for me to explain how I could do TDD for game dev.
Here is an instantiation of the main window game, without showing it, and proving that an actor after being killed is indeed removed from the update and draw queues.
It doesn't do "running" tests (as in calling draw and update every 16.66ms) but I think it makes a point about how you could do tests.
https://gist.github.com/d4f3c7a8c4cce07c138dI think the problem when doing testing is in HOW to test. What are the questions you need to ask (and the testing framework needs to answer) to do successful TDD.
I'd love to see this already implemented in Gosu/Ruby :) pls pls jlnr *nudge nudge wink wink*
Well, you can always pass a different number to the constructor of the Gosu::Window class. It uses 16.66666.... ms by default (60Hz, fps).
If you pass to it 0, or 1 (never done that, gonna try it), I think it will go as fast as it can, and then you can implement the timing handling yourself in the update loop for time skipping, etc., as pointed out in the article.
I really liked the idea of this post, but I'm a newcomer to Gosu, so I don't really have any cool snippet that I could extract from my code yet.
But nice idea nonetheless. :)
I think it would be a good idea to bundle the chipmunk.so with the Linux files... I haven't been able to compile it and can't try this game :(
Update
======================================
Well, finally I could get the ruby extension working...
And nice minigame! I was finally able to try it. :)
Yeah it is sad. :(
I really liked that guy, he was truly the "mad scientist" type I'm very fond of.
Hope he is back one way or another...
Ahh it looks great!
Yeah, when do we have that gem coming? :)
Or better yet, you should set up a repository... authomatic updates for everyone everytime! :D
Well, then see you around irc someday. ;)
Ahh! nice code there!
I'm working on something very similar (about routing the inputs and stuff to a "state" of sorts), and your app will help me to flesh out some stuff! :D
@fguillen: Nice. :)
Where are you from? maybe we can exchange tips or advice in our language.
What clever virtual resolution system?
Where's the link? :)
Thanks pal, great you gave us something to play with meanwhile :)
It works! :)
Finally I could play it, good job!
Hey good work! :D
What language are you using?
The updated, now entities belonging to a viewport are clipped. No more image leaking.
You can zoom in and out from viewports using your mouse scroll or up-arrow, down-arrow. This is context sensitive, it will zoom out (in) whichever viewport your mouse is over.
You can click inside viewports only.
Cleaned a bit the debug info, and cleaned a bit the way it's called.
Go take a look :)
http://github.com/lobo-tuerto/ruby_steering_behaviors/tree/master
This is the error I get, happens when I move a little, just after starting the game:
lobo@lobo-laptop:~/development/gamedev/bakery$ ./bakery
./src/customer.rb:132: [BUG] object allocation during garbage collection phase
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
Cancelado
The other error was when trying to run it from Ruby 1.9.1
Hey thx :)
Well to tell you the truth, that is expected.
The toroid is not fully implemented, I just wrap around the screen edges in a very basic way, no further calculations are made.
And maybe it wouldn't be too hard to implement, just delegate the distance calculation to the viewport... :)
Ok, I updated the code and it worked! for like 10 seconds... :(
After just starting the game, and clicked, the char started moving then the app just closed.
And yeah, it's a bit annoying the "hiding/showing" of the window. I bet it'll improve a lot if you just use screens to manage your code. :)
Hmm, just cloned from GitHub and after trying to execute it got this message:
./bakery:12:in require': /home/lobo/development/gamedev/bakery/src/shop.rb:156: syntax error, unexpected ':', expecting keyword_then or ',' or ';' or '\n' (SyntaxError)
...on_down?(Gosu::Button::MsLeft): publish(Event.new(:left_clic...
... ^
/home/lobo/development/gamedev/bakery/src/shop.rb:157: syntax error, unexpected keyword_when, expecting keyword_end
when button_down?(Gosu::Button::M...
^
/home/lobo/development/gamedev/bakery/src/shop.rb:157: syntax error, unexpected ':', expecting keyword_end
...n_down?(Gosu::Button::MsRight): publish(Event.new(:right_cli...
... ^
/home/lobo/development/gamedev/bakery/src/shop.rb:158: syntax error, unexpected keyword_when, expecting keyword_end
when button_down?(Gosu::Button::KbEscape): menu
^
/home/lobo/development/gamedev/bakery/src/shop.rb:158: syntax error, unexpected ':', expecting keyword_end
when button_down?(Gosu::Button::KbEscape): menu
^
/home/lobo/development/gamedev/bakery/src/shop.rb:363: syntax error, unexpected keyword_end, expecting $end
from ./bakery:12:in
<main>'
What am I missing?
Nice, I might give Chipmunk a try again. Last time I couldn't compile from the svn source... was getting a strange error.
Great! keep up the good work!
Hope to keep hearing about your progress. :)
Hi guys, just to let you know that I've started to code a little app that implements steering behaviors as seen in: www.red3d.com/cwr/steer/
I'm planning to use them in my next mini game (a missile commander clone).
You can try the demo and tell me what you think. It implements a number of things, although it's in a very basic state (worked on it this weekend).
There is a basic app, with 4 behaviors implemented:
* Seek
* Flee
* Arrive
* Pursuit
More to come, probably next week, if I can make myself some time. :D
Although I think I will refactor it a bit before implementing more stuff.
There is a Viewport class to that I created so I could play with my vehicles on a very large space. Think of it as a sandbox that you can configure to an arbitrary size. And right now it wraps around, treating the viewport as a toroid.
For example, you can have a 4000x3000 virtual space inside a 800x600 viewport inside your real 1024x768 screen.
I implemented this because I'm planning to showcase the behaviors each on a different viewport, but all in the same screen at once.
I think it might be used to implement a minimap, maybe?
There are 3 agents in the demo app.
Use your mouse, clicking on the screen will set a mark.
The green agent will flee from it.
The white agent will try to arrive to it.
The red one will pursue the white one, predicting it's future position (little white crosshair in front of white agent)
Press D to hide the text. Esc to leave the demo.
Here is the link to github:
http://github.com/lobo-tuerto/ruby_steering_behaviors/tree/master
Alright, I took my "old" Metris project and refactored the code.
It's called Rubytris now, and it lives on GitHub, so you can easily clone the repository and checkout the code with:
git://github.com/lobo-tuerto/rubytris.git
Or just visit the project's page here:
http://github.com/lobo-tuerto/rubytris/tree/masterRefactoring brought:
* The one-long file has been broken into various files, it's been translated to English (comments & in-game text).
* Decoupled a lot of methods (will keep working on this next weekend).
* Simplified a lot of methods, easier to understand now.
* Some ideas and planned features.
Any comments will be appreciated! :)
Thank you for the encouraging words. :)
As soon as you are done, send it to me, so I can do a quick check, and help with whatever is missing.
Cheers.
Hi guys, this is my very first game. Since I'm so much in love with Ruby, it was done in that precious language. :)
It's simple, can be improved in many ways.
It's heavily commented (Spanish only though, but if there are people interested in an English version I can do it).
It's parameterized, you can set the height and width of the board, the square size for the blocks, the times for falling pieces, times for repetition (when the user holds down a key).
You can define your own shapes easily, and define a pivot (a point that the shape rotates around), no more you have to explicitly create a shape with all the four rotations in a file.
The shapes may have an arbitrary size.
The game is moreless (very)basic-feature complete. It has a score for the player and it ends (tee-hee).
It was done in about 3 days, 2 days straight, then 1 more day a couple of days later.
If you have questions, ask away! :)
Here are some screenshots that shows how a little toying with the params, can modify the "look" of the board:
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill