Day 9: A Codebase in Chaos

For Day 9, I am continuing my effort to finish the RPG engine. This time, however, the codebase is thrown into chaos.

Several new classes has been created all over the place, as well placeholder code until classes are complete. We also have some bugfixes so that the game can work properly again.

One of the newfanged class is the CharactersTracker class, which track all the players, npcs, and mobs. The class will cannibalize the EnemyTracker class in favor of a more generic version. Along with the cannibalization, it will be possible to "plug" in different kind of characters.

Another happening is the cleanup of MapLaw and GameLaw classes. Documentation are added as well the cleanup of magic variables. It is also planned that the maplaw and gamelaw class will move out of mapengine class and into the game engine class.

We will also have to address the camera's following issue, as the code will have to be refactored to take into account the CharacterTracker class.

That's a lot of work right there. I think this is it...I hope.

21 more days to go until I complete this productivity training.

Day 8: The Last of the Cleanup?

For Day 8 of my productivity experiment, I decided to focus on map engine cleanup so I can have something to release by the end of this week.

Day 8 yield two important changes in the codebase.

First, the map engine class is further spilt into two new classes. In this case, the game engine class is managing the map engine class. The changes happen because there were classes that does not have anything directly to do with our map engine code. Since this was not intended to be merely a generic map engine, it was to be an RPG type, so I decided to expand the scope of the engine code. I will be expecting a few new classes and movement of code away from the map engine code as a result of this deciesion. Hopefully, it isn't something I'll regret.

Secondly, further changes were made to de-hardcode the enigne. The MapLaw class is now spilt into two classes. One is the generic MapLaw class, managing common functionality relating to the maps, while another is the GameLaw class, which defines custom triggers and events on the map and other objects. The GameLaw class inherit all the MapLaw functionality and is required by the map engine to function. I still do not know of other way to de-hardcoded it. It is also possible that further redesign and classes spilt will happen before we got the API down.

All of this changes, of course, doesn't in any way impact The CopyPirates' gameplay or multimedia capability. However, the map engine should serve as a strong foundation for the game once we're finished.

It seem that I am on the verge of finishing the engine codebase so it should be released soon. However, look can be deceving and it may take a bit longer than expected. I hope to not be disappointed by the end of this release.

RubyWeekend Postmortem

This postmortem is about my first game entry for the first ever Ruby game programming competition. This game is called The CopyPirate.

What went right?

1. I finished my game before everyone else. This is probably because I was motivated by my previous failure to submit my game in time for PyWeek, the first contest that I participate in. The shorter time also don't give me breathing room so I forged ahead of everybody.

2. Merging and reusing my code was a snap. I was able to use most of the code from Twisted Shootout and SpaceFighterAce and merge them together. Very little time is spent on coding new gameplay elements. I was probably the laziest programmer in the entire contest.

3. There are little downtime. I did not have to waste 3 hours in tracking down bugs. Because the codebase was essentially finished even before there was even a codebase, the code I used were proven to work and are generally free of bugs.

What went wrong?

1. Readme's instruction manual were difficult to get it right. Because I did not use virtual machines, I have to relies on others to check my work. It took me several try to get it right. Even as I finished the instruction, I lack information on how to install rubygem, a package manager essential to the installing process.

2. My codebase have magic number syndrome. Even though my codebase was known to work, it was also entirely undocumented. This make future modification of the codebase in delicate and complicated areas risky operations.

3. The game have uncompelling gameplay. Due to my lack of knowledge about gamepplay design, my game wasn't able to compell anybody to vote for my game. Thus I probably rank dead last or near dead last in the contest.
What I learned.

1. People like to read programming journals. It also draws traffics, which boost ads revenues as a bonus.

2. Extreme but reasonable deadline and blogging are useful productivity tools. I look forward to using it outside of this contest.

3. I learned that what I see in my text editor isn't actually what I will actually see in my git repoistory. I was also advised not to use tab space, but instead, actual spaces. Tabs ruins formatting I believed I was told.

What I would do differently.

1. I would clean up, document, and port my map engine so I haave more time to work on the gameplay during the contest.

2. I would try a rush hour every 8 hours or so. The rush hour is when I just simply focus all my energy on coding rather than spending part of my time chatting on IRC.

3. I would try to find a teammate to do the artwork for me so I can focus purely on coding and gameplay design.

News: Rubygame 2.0.1 Released

Today, Rubygame 2.0.1 is released! This is a release I been anticipating all this month. Included into this releases are some bugfixes. For example, C code segfault are fixed. So you will not be meet with a strange error, thus saving you time.

Rubygame is the library that I used to develop games in the Ruby programming languages. Thanks Jacius for developing this library. None of my games wouldn't be in a graphical form without Jacius!

Withou further delay, I present you the changelog and the download page. If you missed the homepage link, here it is.

I highly encourage you guys to download it. This way, when you download my future games, you don't have to brother installing Rubygame further down the road. You might even become game developers with it!

Happy Hacking,


Kiba

A Considerable Delay.......

This image below is all the progress I managed to make for this weekend for my space arcade game, Space Fighter Ace. The game will have to wait, or simply released later this week. It is not because I am busy or lazy, and other reasons relating to my productivity. Rather, I managed to get myself locked out from rubyforge(after giving the wrong passwords too many time), making me unable to commit anything to my project's subversion repository, thus delaying the progress. Afterward, I finally managed to regain access after the rubyforge administrator undo the automatic blacklist me but not enough time for me to meet my Saturday self imposed deadline.

As for rbgooey, the GUI library for Rubygame, their repository is hosted on a different site, so their progress wasn't delayed. Rbgooey got lucky, so we're releasing a new version after mere days of the first release. Version 0.0.2 sport a new feature and some bugs fixed. If you're a Rubygame user and in needed of a GUI library, check this out.

Tomorrow will be the start of a new project, Rubyemon. We'll chronicle this project's progress the whole week starting on Sunday. This project will enjoys one long hackathon.

By the way, we will be putting up donation links for those who enjoy our incoming and future games, and also somehow generous enough to donate some cash. We will also mention a donation request in new games coming soon like Space Fighter Ace, and as well Rubyemon. If I somehow managed to get enough money from donations to pay for web hosting for a year or two, I'll use that money to get a dirt cheap web host somewhere on the internet and get out of this place.

Good night and happy hacking,

Kiba

If you have any suggestions, opinions, ideas, etc, you're welcome to contact me at wikipediankiba_________gmail__________com. You can also comment on this blog post too.

Annoucement of New Projects

I am here to announce you my first project to be unveiled here at this blog, rbgooey!

Rbgooey is an alternative GUI library for Rubygame and also the first of its kind to be released for the Rubygame library.

This library, version 0.0.1 only support texts and limited typing operations. Over the following days, I'll continues to extend it and refine the API so everyone who use it will get a much better(and more awesome) experience in using the library. This library is the culmination of all my knowledge in writing a GUI library using Rubygame, although it isn't complete yet.

The image I show you below is the screenshot of a really cool example application I developed to demonstrate the rbgooey library. It randomly display new texts of five characters long in random locations on the display screen every second. 10 seconds latter, the application reset and the process started over. In total, there should be 50 pieces of texts every cycle.

Code:

Enough said, let get to the real code(Don't forget to install rbgooey)

require"rubygems"
require"rubygame"
require"rbgooey"
include Rubygame
TTF.setup()

class Timer
def initialize seconds , &action
 @interval = seconds
 @action = action
end
def check
 t = Time.now.tv_sec
 if t >= @fire_at
  @action.call
  @fire_at = t + @interval
 end
end
def start
 @fire_at = Time.now.tv_sec + @interval
end
end

class RandomText
def initialize
 @display = Display.new
 @display.setup(800,600,true)
 @display.color([100 , 100 ,100],[20 , 20 ,20])
 @background = Rubygame::Surface.new(@display.screen.size)
 @data = UiData.new(@display)
 @data.text.setup("freesansbold.ttf",12)
 @data.text.render.surface(@background)
 @clock = Rubygame::Clock.new
 @clock.target_frametime= 40
 @q = Rubygame::EventQueue.new()
 @data.declare(:hello)
 @random = Timer.new(1) { random() }
 @delete = Timer.new(10) { delete() }
 @random.start()
 @delete.start()
end
#http://snippets.dzone.com/posts/show/2111
def String.random_alphanumeric(size=16)
 s = ""
 size.times { s << (i = Kernel.rand(62); i += ((i < string =" String.random_alphanumeric(5)">

action = RandomText.new
action.action()

Explaining Things:

The entire codebase of the program is about 77 lines long, including space. With some data files, the application should works. Well, it certainally won't work without data, so I am just offering this place to download the whole thing, just the codebase and some data files.

This demo program will probably not work in versions later than 0.0.1

Already, I discovered the first flaw in my library. Rbgooey required a hard coded path to an image. The path is "test/mouse.png". Even though we didn't use the mouse in the program, it is required for the application to work.

The entire code of this program is public domain, excluding a code snippet for generating random texts.

While this is not a tutorial, I would like to explain a few methods that I used with rbgooey. For example, UiData#text.add(string,x,y) is used for adding strings. UiData#clear is used to clear every information about texts, rect, and so on. Before you can create texts, you will need to declare a group you want a certain group of texts to be associated with. For that, you use Ui#declare(name here). UiData#text.render.undraw clears all the rendering of texts.

I'll stress one thing, this library is not ready for consumptions. It isn't used in real rubygame applications yet. Soon, I'll use this library and implement improvements as I muck around with video game creations.

A Roadmap:

The roadmap of rbgooey look like this for the next three versions:

Version 0.0.2 will includes file based configuration of basic setting such as screen size, mode, the font, and among other settings that I forgot to mention. It should help the code manage clutter. Bugfixes are the main focus here.

Version 0.0.3 will see some features for groups(the association of texts and other user interface elements) such as the ability to change the size of all texts within that group. Support for capital letters in typing will also be added.

Version 0.0.4 is where many of the major enhancement and improvement to the text library part will be added. In this version, you will be able to change the color for each individual characters, as well display different type of fonts for different texts. There will be lot of new features to manage texts in this version.

Some Other Announcements:

Now that we're finished with rbgooey introduction, I'll have a few projects that will be coming up. First, a new version of a simple game that I developed long ago will be released sometime on the weekend. It is called Space Fighter Ace. This game is a simple space invader clone that only work with previous version of Rubygame and only work on Window(Because I wasn't aware that linux is case sensitive). The target date I am aiming for is Saturday. New version of rbgooey should come out after this project's release.

Next, I'll start work on my first big commercial Free software game project. This new game will be called Rubyemon. Rubyemon will have similiar gameplay to the game Pokemon. We will chronicle that project for at least one week of its development, and then some update between there and here.

Wow, that's a mouthful. There are about 940 words in this post! If you got here without getting bored, congratulation.

It is time for me to get cracking on the various new projects.

Happy hacking!

~Kiba

P.S If you got any comments for this post, please post it, even if it is grammar nitpicking. You can alway contact me at my email address, wikipediankiba______AT______gmail.com

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.