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

Making Money off Free Software Games?

(I decided to repost this article after I deleted it. Sorry for RSS readers who come to find it while missing)

For some of us, Free softwares are just nice things that they can do without. They only care about it if it is better than the alternative softwares either proprietary or Free. Some of these people promote Free softwares for only pragmatic reasons. But for some of us, we really do believe in the ideal of the four freedom that every software users should have.

The reality is, the ideal of Free softwares is something some of us live by. The pragmatic values of Free softwares are nice, but however they are only secondary. The morality and ethical concerns come first.

Sometime, when we're trying to make a living, we're forced to write proprietary softwares. To write proprietary softwares is to violate our ethical standard. To not write these softwares is to face starvation. It is a dilemma.

The solution to the dilemma is to try to make a living on Free softwares and make it viable by whatever mean. So we are no longer forced to write these type of softwares every again.

So How do You Make a Living Off Writing Free software Games?

The first thing that probably come into people's mind is RedHat and tech support. Some people might be asking "How can you do tech support with video games?"

Unless, you run MMORPG servers, you're out of luck with that business model.

Some people, who are skeptical of this idea, thinks this is not viable at all. There never been a single commercial Free software game that are Free softwares from the very beginning. This is true. However, it is because nobody even try to make a living off writing Free software games. Hackers are probably just not interested in games that much.

Just because nobody try doesn't mean that making money off Free software games for a living is impossible. It also doesn't mean that you will never get rich from writing Free softwares.

One usual way of making money from softwares is selling the softwares. This is the business model of many software vendors. Normally, these vendors use the intellectual monopoly granted by the government such as copyright to control others' abilities to distribute or modify their own copies of the software. This is usually backed by a threat of lawsuit and hefty payment. It also created artifical scarcity.

Free software programmers give up these right in exchange for the Four Freedom that users of their softwares will have(As defined by Richard Matthew Stallman). Many would have chosen license like GPL that will guarantee the four freedom(which is ironically using the same intellectual monopoly granting law). Due to our inability to control people's copies, it is harder for us to sell Free softwares. It force us to have to look at other business models.

For a business model based on entirely Free softwares to succeed in the long term, I believe you need two essential things. For the first ingredient, you need lot of good game(s) that people like to play. the second ingredient is web traffic(or customers). Without traffic, you're doomed to make no money at all.

Another essential attribute of a successful business model, is the capitalization of scarce resources. They don't try to monetize of plentiful, practically unlimited resources. Instead, it is better to encourage these resources to spread around. What might actually happen is make the scarce resources even scarcer. In that sense, instead of trying to sell Free softwares, you could encourage everyone to spread the softwares. This is much like the various SpreadFirefox marketing campaign. Then you could try to sell scarce resources at a price.

These scarce resources could be good multiplayer servers, t-shirts, or even ads space.

So how You Would Actually Do These Things in Practice?

Selling Ads on Your Website:

This is the business model of many websites. Website with a lot of traffic are scarce, so the higher traffic you receive mean that your website is more valuable. For example, if you have a website just like I do, but with higher traffic, your website would be sought after by a lot of people. The higher your traffic, the higher price you can set.

Selling Time:

You could ask your fans to donate a certain amount of money in exchange for the development of certain games. Another idea is the auction system. You could set up an auction and different options(Games to develop) that your fans can bid on. If you have rabid fans for several games and they each really want a new version of the game they would try to outbid each other. Since your time is limited, you can only do so many things at once. By fans doing the auction, they decided what games are the most important to develop and how much money they're willing to fork over.

First Sales:

This business model require you not to release the source code or the executable to the public until the sale is done. In this model, you ask for a certain amount of money in order for a game to be released. The public would then collectively donate the money that you asked for. The faster they donate, the sooner a new game will be released. If they are impatient, you'll gain all the profits pretty fast. However, slower donation means you have to wait. A spin on the idea is to increase the donation price periodically. They could be one dollars every five day. This way, fans will even have more incentive to donate in a shorter amount of time. Slower donation mean the price will be even higher, which cause a delay in the release of a video game. Fans don't like the idea of having their game delayed by several weeks. This is essentially royalty fees, just payment up front.

Selling Hosting:

For the business model, you will be selling multiplayer server hosting for your game. The idea is you'll be using your knowledge in the administration of game servers. Since you wrote the server codebase, you know how to use it more than anyone else. You could do better job of doing special additions and other features for your customers' server. Even if the server's license require every customers to release their source code, you still provide a very special service that nobody else can(Save for someone who also know every inch of the codebase) like fix new bugs. You can also offer bandwidth upgrade, space upgrade, and other various additions.

Run your own pay-to-play server:

To run your own pay-to-play server is probably one of the most lucrative business model of all. If you can get 500 people to pay you 240 dollars each year (20 dollars each month), you make 110,000 dollars each year minus expenses. This model is mostly assuming that you run an MMORPG server or something equivalent to it. A game of this type probably one of the most challenging and ambitious project, if not the most. The risk is high, but the reward could be huge.

Selling tangible items:

You might as well be selling a package of your softwares with assorted bonuses such as pretty cover art, a manual, and maybe a signature from you. Some fans, rather then donate, prefer to get something more tangible for their money. It work well for some webcomics such as Megatokyo's Megagear store. Some people sell T-shirt, others sell toys, and some sell hardware like the guys at Damn Small Linux.

Begging for Donation:

You could simply ask for donations and relies on the charity of your users. If you have a lot of traffic, such as a 500,000 people per day, it might be doable. The best way to do this method is to offer various subscription donation plans. In this way, people forget about it and continuously donate certain amount of money each month. If you can get 2,000 people to pay you 1 dollars each month, you get 24,000 dollars each year. However, if you can get them to pay you 2 dollars each, you can get 48,000 dollars each year. If you can get 500 people to pay you twenty dollars, you get 110,000 dollars each year. In this model, only maybe a few hundred or a few thousands are needed to donate to keep you going. It is really patronage on a large scale. They simply want you to produce lot and lot of good games, so they're willing to fork you some money.

Some of these business model are already tried by other people in various other area. These are not new, but they are possibilities.

Who Will Try?

Anybody who want to make a living off Free softwares instead of proprietary softwares will try.

As for an example , that would be me. I want to try. I believe strongly that you can make money off Free softwares. No proprietary softwares will be written. No contents will be left proprietary. They will all be Free.

My contents are already Free contents. So if I make a cent, I'll be one tiny step to reaching my goal(I am still waiting for an advertising service to approve my website). Beside, it would be great to be the first person on this planet who make money off writing only Free softwares games.

If there are already people who are trying to do this, I too, wish them the best luck in the world!

Happy hacking,

Kiba

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.

Welcome to Liberty Gaming

This blog is all about Free software gaming. It will include news, tutorial, and opinions about Free software games, regardless of its prices!

And by the way, freeware searchers, move along, nothing to see here. There will certainally be no proprietary games that will be reviewed on this blog! And for the people who like commercial games, you might see some commercial Free software games in the future. (Although we will probably never see one for years)

What you say? Confused? No problems, I'll refer you to this link to clear up your confusion.

Without further ado, let start blogging!

What is upcoming in Liberty Gaming contents:

A Rubygame Tutorial: A tutorial introducing you to the Ruby programming language and the obscure world of....Rubygame!

We'll have a new review of a game once we spot a promising game to try.