Remember that Game?

Remember that ruby-warrior game I was working on? Well, I finished it and already recevied my payment from the patron. I only added one extra feature that allows people to enable and disable the game's graphical engine.

I asked the original author to merge it into his repoistory but he didn't look and merge the codebase yet after one week. He is probably a very busy person, so it will take time.

The 50 dollars payment was pretty good for me. For a young person, 50 bucks is a lot of money. However, I decided to save money for future consideration, especially for buying my first laptop. As I want to work any place in the world, this would be a valuable investment and free me from my desktop.

If you wishes me to continue further development, you can visit my project page for details of the next job. Here is the direct link to the funding page.

Halfway through the Job

The no-fluff graphical engine for ruby-warrior is for all practical purpose, finished. It can load the maps, captives, sludge, and other monsters I didn't think of. Pretty cool.

I am just playing or rather, programming my AI to play the game to ensure that I didn't miss anything. It will be interesting to see if I can get the codebase merged back into the original game itself.

All that is left is the bonus programming that I will do. Two week is twice the estimation of this project. This is good. It is better to overestimate the difficulty and duration of a project rather than underestimate them.

My first patron is excellent. He gave me some good advice on how to manage a project and he paid me half for getting the project halfway. When the project is done, he will pay up the rest.

Now all I need is to do some bonus programming for the rest of the duration of the job and polishes them up.

I could probably promote the game at the end of this project and make some extra cash in the form of ads space. Not sure if it is a good idea to do it. Maybe it is tacky and unethical? I did create the graphical front end for it so I can probably promote my graphical front end.

Game Programming Job Scored! Victory is mine!

I got an informal contract from a fellow ruby hobbyist and programmer to work on the graphical frontend for ruby-warrior for 50 bucks. It is a small amount of money but hey we got to start somewhere, right? (For the record, 50 dollars is a lot of money for me)


Ruby-warrior is essentially an AI programming game in a hack and slash setting. It is something that only appeal to the very geeky crowd of programmers but it is also a lot of fun. My job is to basically blot a graphical engine on top of it to give it more oomph. I won't be doing pretty arts though.

Since the author already worked out the parsing details, making an engine should be a piece of cake. I done it mutiple of time already in my own projects over the years. The best part is that all the work will be made libre and freely availiable.

What I am hoping is jobs beyond this project and of course, more libre games. Every job to me would unlock the path before me and help me make my dream of writing FOSS video games for a living come true.

You can see details of the job here.

Feb 5-6 is the deadline. Let hope I make it!

RubyTet 0.0.1 is out!

Rubytet is out! It is a complete clone of tetris, although a bit different. It took me six months, on and off, working to get this finished.

So there it is, a clone that doesn't really particulary stand out. However, that's ok because it is a stepping stone to bigger and fun projects. I think I really get the memo that truely good games take long time to create, a year of nonstop coding I believe.

There you have it! My game.

Day 25: Cooking up Movement Code

The second day of development is all focused on getting the movement code for the player right.

So I spent much of my morning hours writing movement code and rotation code, although I still have to take care of fixing crash bugs because I forgot to include a few files in the mapeditor program.

The rotation code is pretty much complete. You can rotate counterclockwise and clockwise as well stop. The movement code, is on the other hand, have incomplete physics. Although you will go faster with accelerating and then you will continue to move even after you stop, it doesn't take into account the angle of movement.

This will be rectified the next day, I am sure.

5 more days to go!

Day 24: KRPGE Finished, SpaceFighterAce Next

KRPGE is finished in two days! That was quick. Then, I started work on the development of SpaceFighterAce.

First, I had to import svn into git before I can push it, which took me about an hour to figure it out. Then I pushed it to github and use the newly released KRPGE for this project.

At last, I spent time coding and finding graphic for the game. I decided to use a NASA picture as terrain.

This game is going to be awesome!

Day 16: Mapeditor Progress Report

For Day 16, here is the mapeditor progress report:

I fixed a crash bug in my rbgooey library so the mapeditor program wouldn't crash just because it is refreshing texts.

I also made the input system completely functional. The only thing missing is that it didn't launch into editmode yet.

The EditMode class got a bunch of code addition that won't be used until all the necessary classes are in place. The classes that are necessary are pretty much in place, because I am reusing many of the game engine component for the map project. It is just a matter of integration and getting all the neccessary data into place.

Day 13: Workload More Than Expected

Well, I certainly didn't ancipitate the amount of work it takes to get a framework ready. I could release just the engine but that mean developers have no context from which to work with. With the current workload, it seem that I will finish this in 3 days, not the next day. Never mind that the map editor will probably also take a long time too.

In any case, rbgooey-0.0.5 is released. This library will be necessary for the use of engine.

As for the experiment, I finished 13 days doing 4 hours of programming. As usual, there's a lot of commits. 17 more days to go.

Day 11: Nearing Completion

I like self-mandated work hours. It make things goes WHOOOOOSH!

And it did for me today. Day 11 with 50 commits, marking 44 hours total of development logged. 19 more days to go

Well, my prediction that I won't finish the engine this week, barely. Unless you count Sunday as the end of the week, in that case, I will finish the engine.

Progress so far:

I finished pretty much everything except updating the file format and the player related features. The Player class isn't fully integrated into CharacterTracker class yet. The code, for the most part are there to support the full integration. It is just that there are special assumptions that are made about the Player class that shouldn't be there.

The CharactersTracker class also got some addition to help make life for users of the engine easier. For example, it can display the name of every characters on that map and return that list. The Character class also got an addition, the name attribute. This will make identifying the different characters on the map easier.


Plan:

Tommorow, I will probably be finished. I hope tommorow will be the release day of the game engine. If not, than it will be Monday. Then, I will start work on the vim inspired map editing tool.

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.

Day 7: Slowly but Surely

Day 7 marks another day in the development of the map editor. I am still stuck in the mapeditor's file menu system. The good news is that I am on the verge of moving toward the editing system.

I created three distinct UI element. These are typepad, the logger, and the file scroller. I also used the modal system instead of the regular toolbars. The logger element lists event that has tooken place such as loading files. The scroller is responsible for displaying files. The typepad is for typing. So far, the scroller is the only complete element. Logger's functionality is almost complete. It only lack deleting old messages thus any more messages over 5 will overflow the screen. Typepad is functional for typing but the event triggers are not programmed in yet.

The mapeditor, by design, is modal(just like vim). For example, if you want to type, you have to press tab.(and disable all keyboard functionality except typing) To finish typing, you also have to press tab. When you're finished, all the other keyboard functionality become available.

Day 6: Inching toward a Map Editor

For today, I done some work on the map editor's file menu system and the map engine code. In particular, I finished work on displaying the content directory and showing new files via pseudo scrolling. It was tricky, as it require a bit of thought to implement it.

Map engine code is relatively easy, as it is merely a cleanup job. I was dissatisfied by the ugliness of some code so I refactored them. Eventually, it lead to a code reduction as the codebase got ridden of outdated attributes and unnecessary long code. There is still the MapLaw class to go through though.

As for the productivity experiment, I got 24 days more to go.

Day 5: Roadblock Destroyed

Well, for day 5, I easily destroyed the roadblock that has plagued me the last two day.

As expected, it was my unforeseen silly mistake that has put me into this roadblock situation. Nonetheless, I did get over it.

I think I made lot of progress today. Here is the rundown of what I was able to accomplish:

Like I said, I cleared the roadblock regarding saving and writing yaml files. Then, I finished the transition from ruby file to a map format. After that, I worked on the map file menu once again. Background graphics were created and the beginning of the file browsing system begun to take shape. Before that, it displayed every single files, now it only displays 10 of them at a time. Plus I added control for looking at more files, though the menu didn't display anything new yet.

Well, I got 25 more days to go. The experiment is looking really good.

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

Day 3: Coding Roadblocks

I finished the third day of my 4 hours for 30 days productivity experiment. 27 more days to go. That's the good news.

The bad news is, I am encountering coding roadblocks for pretty much everything I tried to work on.

First, it was the rake task for generating files. I tried to write rake tasks that accept argument but I got weird bug before I was able to finished it.

Then I spent three hours trying to figure out how to use hashes loaded from yaml file.

These 4 hours are not very productive. However, the important thing is that I am learning discipline. The roadblocks are only temporary. The long term gain will pay off big. I just need to keep doing this experiment all the way to the end.

Ongoing Experiment in Right Direction

I must say, the early results were promising.

In the past two days, I was able to make in excess of 20 commits per day. And I also made a lot of progress. Here is the rundown for what I did for the last two days.


Day 1: I moved lot of code to the mapengine class and rename lot of variables. I also took time to eliminate unnecessary code and unclear magic variables. One of big highlight of this day is the work on the character class, which incorporates common elements from both Player and Enemy class. This eventually allow me to update both Player and Enemy class with the same code. At the end of the day, the codebase become more modular and less hardcoded.
I also written a rake task to lessen the burden of syncing the codebase to the remote git repoistory.

Day 2: Major work has been done on the mapengine's map format and map file management. I also started work on the map editor, which is a major project in itself. I only got so far to directory list user interface and beginning work on input system. As for the map file management class, I added major features that spit out directory information, create blank maps, as well read certain files from directory. I also created a rakefile to create maps using the new class too.

Wow. That's a lot of progress I made in two days with a mere 8 hours. 28 more days to go before I can make this practically second nature.

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.

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.