Day 12 & 13: Slugging through the Weekend

Apparently, my post for Friday did not successfully materialize. All of the work I have done for that blog post disappeared. Oh well.

But for Saturday, I made a fair amount of progress on different tasks.

RubyTet: I got the shapes fixed and is working on the drop code.

Libregamewiki: I am working on coordinating the construction effort so that the Libregamewiki will see its most activity ever since the project started.

Space Fighter Ace: I finished chapter 2 of my trig book. I need to accelerate the learning process if I wanted to finish the game by Christmas.

Rubygame book: I worked on providing the neccessary images for learning how to use surfaces.

Rails tutorial: I am slowly working through the tutorial at the moment. I could probably finish the whole thing in one day if I wanted to though. That should be a bonus mission for this weekend.

Rubygame Tutorial 3 & 4

Note: Tutorial for 3 and 4 of the Rubygame book are now located here and here.


Rubygame book part 3 and part 4 are out!

Part 3 is simply setting up the controller class, which will be where all the game happening will take place. Part 4 is where you get to learn about using the clock to regulate the game speed. It also shows how to modify the titlebar to fit your purpose. In this case, we are displaying the FPS information.

If you're not already following the tutorial, start from the beginning as the series built on previous work on the game code.

Lastly, if you have any question, comment, bug report, and suggestions, please comment!

If you don't like the way I wrote the tutorial, you could alway fork my tutorial, since it is licensed under the Creative Common Attribution.

A little request: Please vote up the FSDaily story for my tutorial.

Day 30: Performance and Tutorial Work

Today, I spent time trying to optimize my game's FPS from a pitiful 15-20 FPS to acceptable 30. Though, it still seems to suffer from having too many objects in the game, which may make large scale battles impractical and possibly limit the game to a few fighters and objects.

For practically 90% of the increase in FPS, I merely eliminate most of the 900 map objects, it would still pose a significant problem if a users were to add lot of map tiles though.

It seem that the engine is improving during this iteration of game development. So much, that I decided to port the engine code back to KRPGE sooner rather than later. See the roadmap for details.

However, I soon hit a roadblock on my optimization problem because I don't know how to optimize further and the lack of available immediate help. So I decided to focus my development effort entirely somewhere. For that, I choose to work on my Rubygame Book.

The development work was especially fruitful because I finished part 3 and started work on part 4.

I still hope to return back to game development work because I got a gloomy feeling about Space Fighter Ace's development cycle. I feel it will be a long slog before I finally complete its development goal. For this, I estimated at least a month.

Well, this is the last post of the 30 days challenge log! A postmortem of the 30 days challenge will be written soon.

Day 4: The Road to Kicking Ass continues!

Well, since I didn't overcome the roadblock yesterday, I decided to focus on writing the rubygame tutorial. You can visit this project at the kibabase wiki.

As you can see, this is called the Rubygame book project, designed to be the ultimate tutorial for rubygame beginners.

I was almost completed with part 1 when I was done with the 4 hours. It didn't look like much but I have to wrestle with the mediawiki extension, which took quite a bit of time. But now the mediawiki have increased functionality when it come to source code, as it should be for a game development wiki.

Tommorow, I am going to hit the roadblock hard and hopefully break through to complete the map engine module project by next week.

26 more days until I start kicking some very serious ass and rock the world with my madz coding skills and discipline..

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.

In Between Updates

The premature death of this blog is greatly exaggerated. (Not that anybody thinks we're are.)

Anyway, I want to let the readers know that we're still working on part 2 of the Rubygame tutorial. But it is taking far longer than we thought it would be. I predict part 2 will be scary long in comparison to part 1. It already surpassed part 1 in both words count, lines, and line of code. I blame it on the sprite part of Part 2.

Have no fear, half of the goal for Rubygame tutorial part 2 are already done. I planned to have it out by the end of this week.

Did I forgot to mention that Freegamer linked to us? A splendid blog linked to us and give us some traffic! I am thrilled.

Speaking of traffics; I aimed to monetize this blog. Yes, advertising will be coming to this blogs. So don't be alarmed at all these new text ads and an ads banner when they suddenly appeared. It will be probably coming in a few weeks, or maybe shorter.

Before we let you guys off the hook, we have an interesting tidbit to share with you. If you hadn't notice yet, this blog's entire contents are licensed under the Creative Commons Attribution 3.0 License. Yep, I, the author of this blog given you the permissions to go nuts copying, distributing, modifying, and making a buck or two off my contents. In facts, I highly encourage you to do so. So long as you followed the rules of this license. A bonus: no royalty rate to pay. By the way, I would like a link back to my blog if you did these things. That would be greatly appreciated.

Until, next time; Happy Hacking,

Kiba

P.S If you think this blog post is really bad, let me know! Email me at wikipediankiba_NOSPAM@NOSPAM_gmail.com

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.