2nd Day Complete: Progress!

Despite the fact that there was no posting yesterday, I assure you that there were activity in the pursuit of my goal outlined in my last post. That is, my aim to start writing games again and continue the development of my wiki.

Yesterday, I was merely setting up the game's inital source code, with all the graphics. It is very much the same today, in which I attempt to build a vague code organization that deals with the logic of the games.

I also began work on improving Libregamewiki's forum, which sits neglected for too long. My plan for the future beyond the current projects I am working on is to remake the forum as part of my overall free gaming franchise.

Changes in Direction

I know I haven't develop extensively since August because school exhaust my energy. I couldn't develop 28 hours per week via the 4 hours a day goal. So all of my gains are now lost.

Now, I am changing pace and keeping my Space Fighter Ace project on hold. Right now, I am focusing on writing simple games like RubyTet, a tetris clone. What I am going to do is institute a new policy of ten commits every day. Though commits doesn't actually represent progress, it will mean that I done a little bit everyday. This is more workable than forcing myself to do 2 hours of game development everyday when I know my school works varies so much.

However, I think I'll devote 2 hours every weekend for the Space Fighter Ace project and acquires all the trignometry knowledge I need.

Also, I'll be trying to keep up updating the Libregamewiki with at least 100 edits in the past 7 days everyday.

Then I will blog everyday to ensure that I keep up with my goal.

Return To Coding

Yesterday, I was able to restart work on coding my Space Fighter Ace game again after a two week absence of not coding. It wasn't related to the roadmap that I have laid out for Space Fighter Ace, but rather for a future version of Space Fighter Ace.

What I done was to write my first network application, building a very simple server and client with no game logic code. It was as far as I got in coding the network code for my game. However, it was important because I finally got back into coding, which is a necessary activity if I want to improve my chance of getting a ransom model funded project going.

Rubygame Tutorial Part 2

NOTE: This tutorial is replaced by The Rubygame Book.





In part 2 of the Rubygame tutorial series we will be learning how to control a Rubygame application's CPU resource usage.

If you did not complete part 1 of this tutorial, it is highly recommended that you do so before continuing this tutorial. Otherwise you will miss a critical proportion of knowledge required to write video games with Rubygame. You may not also understand newer parts of this tutorial.

We'll jump right in learning how to control CPU usage so your Rubygame applications doesn't suck your computer's CPU resource dry. By controlling CPU usage, we also get the added advantage of consistent frame-rate.

CPU Usage Control

Before we go any further, I request you to run dodgeball.rb and record the CPU usage of the game. Please record it in a place where you can refer back to(Not your brain, a paper is a much better place). This data will be used to determine if whether our code actually work or not. You'll need to look at the ruby process. Please make sure the ruby process is actually dodgeball.rb and that application alone.

My data show me that dodgeball.rb uses about 99.9% of CPU.

Now that we're done recording the data, we can start writing some code.

Modify the file named loop.rb in the rubies_dodgeball's lib directory:

class GameLoop
def initialize
@screen = Screen.new([800,600],0,[Rubygame::HWSURFACE, Rubygame::DOUBLEBUF])
@q = Rubygame::EventQueue.new()
@clock = Rubygame::Clock.new
@clock.target_framerate= 40
end
def run
loop do
  @clock.tick
  @q.each do |ev|
      case ev
      when Rubygame::QuitEvent
          Rubygame.quit
          return
      end
  end
end
end
end

The Rubygame::Clock class is used primary for delaying executions of Rubygame applications. It can also tracks running time. You must specify the frame-rate of your application before executing the main game loop( in our code, we used @clock.target_framerate= ). The method tick for @clock is used for frame-rate limiting to a specified frame-rate.

When you run this program, you should notice a great reduction in CPU usage. It should be a lower than your recorded CPU usage before you modified the code. My data show me that dodgeball.rb uses about a mere 6.7% of CPU. So it work like a charm.

If you made this far, you finished the second part of this tutorial. Well done! In the next part of the tutorial, we'll show you how to how to move images.




Anyway, happy hacking!

Kiba


P.S If you have any problem with the tutorial, please email me at wikipediankiba_________AT______________gmail.com

NOTES: There used to be a lot of content packed into this part of tutorial. It was decided that there are too much content. Plus there are many bugs in the code shown so it is removed in order to preserve the quality of the tutorial.

Rubygame Tutorial Part 1

NOTE: This tutorial is replaced by The Rubygame Book.




This tutorial series is a crash course in writing video games using the Ruby programming languages and Rubygame, a game development library for Ruby. It assumes that you have basic knowledge of programming along with knowledge of the Ruby programming language.

If you do not have Rubygame and/or the Ruby interpreter installed, it is suggested that you do so before continuing this tutorial. This tutorial will assume you're using 2.0.1 version of Rubygame.

In this series, we will be creating a dodgeball game using just Rubygame and Ruby as we write this tutorial out. No other libraries will be used. The final game will be licensed under the GPL. This game will be called Rubies Dodgeball!

In Part 1 of this tutorial, we'll be creating a screen and than setting up a basic game loop.

Initialize a Display Screen

We'll start by assuming that everything will be in one directory named rubies_dodgeball.


The first thing you will do is set up the neccessary items to create a rubygame application. After you accomplish that task, you will create a screen, the display window for the game.

Create a file in the rubies_dodgeball directory: dodgeball.rb


require"rubygame"
require"lib/loop.rb"
include Rubygame


Setting up Rubies Dodgeball to use rubygame.

Create a file in the rubies_dodgeball/lib directory: loop.rb


class GameLoop
def initialize
@screen = Screen.new([800,600],0,[Rubygame::HWSURFACE, Rubygame::DOUBLEBUF])
end
end


We set up the display screen with the size of 800 by 600 resolution in the first agurement of Screen.new, next one with no depth, and the last with flags Rubygame::HWSURFACE(It makes a video surface in video memory) and the Rubygame::DOUBLEBUF will enable hardware double buffering. There are other king of flags such as the one that can enable fullscreen mode. Of course, we need to initialize the GameLoop class in order to take effects. This should be placed at the end of file dodgeball.rb


game = GameLoop.new


Once you run the program, it should display a brief display window. Since it has no loop, the program will terminates quickly.

Adding a Loop and an EventQueue

Next, we add an EventQueue with a loop into the game. We modify loop.rb's GameLoop class in the following fashion:


class GameLoop
def initialize
@screen = Screen.new([800,600],0,[Rubygame::HWSURFACE, Rubygame::DOUBLEBUF])
@q = Rubygame::EventQueue.new()
end
def run
loop do
@q.each do |ev|
case ev
when Rubygame::QuitEvent
Rubygame.quit
return
end
end
end
end
end


Rubygame::EventQueue is used to detect keyboard presses, mouseclicks, movements of mouse, and other input devices.There are hundreds of constants that correspond to a particular keyboard keys, mouse buttons, and more. For example Rubygame:K_ESCAPE is for the escape button.

Rubygame.quit() is a method that should be used when Rubygame applications are about to be terminated. Notes that it isn't used for quiting the application, rather it clean up the messes it might have. For example, if you exit while in Fullscreen mode, users' desktop resolution will become that application's dispaly screen size, which is very annoying. Rubygame.quit() helps prevent such annoyance and confusions from happening.

Don't forget to add game.run() at the end of the file dodgeball.rb!


game.run()


When you run it, the application should go on forever, sucking all the available CPU resources that it can get, until you click that X button in the window.

You can download the file here.

This is it, folks. That is all we're going to learn for this part.

What's coming next in part 2!:

How to reduce the CPU resource usage to a saner level

Addition of a sprite system.


Until next time!

Kiba,


If you like this tutorial, you might to subscribe to my blog's RSS feed.