making video games, where do you start?, how do you stay focus?

[dragonboy]

I want to eventually make a video game, or be part of a development team, but where exactly do I begin making the game?  First you can't make the game without the game engine but how would you know how the game engine should work if you don't know what sized sprites your going to use and how many of them without drawing the graphics first?  How do you stay attentive drawing the graphics?  I've been working on an animation of a girl dancing for about a month and I only have 9/12 (I might even need more than 12 for this, but I don't know yet) frames done.  How do you make an game engine anyway? (I'm thinking of making this game for either a Sega Genesis or a Super Nintendo)  How do you come up with a system of designing the game that allows you to do EVERYTHING?!  I have a lot of crazy game ideas that don't involve just having enemy sprites walking on a non-moving background layer.  For example, having a wall in the background crack and then the ceiling collapse on you, you can't achive with just the "sprites on one playfield background" kind of engine.  It wouldn't work because it will require the top of the background to be turned into two backgrounds and the second will be also as much as part of the game as the first background.  So how do you make a engine/system that does everything you want it to do?  What about compressing graphics?: If you do all the decompressing before you start the level you might run into RAM limitations; if you do real-time compression you might have som miserable slowdowns (unfortuanately, a lot of Snes games relied on this method, I heard from someone); and if you don't use compression you might run into ROM problems.  So what will be the solution?  Have a giant mess of different strategies, strategically chosen for all the different characters and items and stuff.  But there is two problems with that:  1) How do you know what strategy to use if you haven't drawn all the sprites and counted how much memory all this takes up?  2) How do you make an game engine that lets you use whatever kind of compression strategy whenever you want it?  Anybody who could solve all my unorginized confusion, thanks in advance!

[Beoran]

First, take a deep breath.

First of all, it takes many years to make a full length video game if you do it alone. Are you willing to invest that effort, knowing that , along the way, you'll probably have to sap your design several times and may have to start from scratch several times?

Can you program? What programming languages do you know? If you don't know how to program, you'll either have to learn how to, or you will have to find a programmer who is willing to work together with you. Both of these are hard. If you want to learn how to program and make games quickly, yet with complete flexibility, I reccommend either Pygame (Python programing language) http://www.pygame.org/ or Rubygame at http://rubygame.sourceforge.net/  (Ruby programing language). If you want to hire a programer, you'll need money. No programmer is willing to work fro free on an idea that is not his own or not close to his own.

To learn Ruby, you can start with an online demo of it here:
http://tryruby.hobix.com/ (hmm, seems to be fdown now)

You can get Ruby for windows here:
http://rubyforge.org/frs/download.php/29263/ruby186-26.exe

For Python, I don't know very wel, since I prefer Ruby.

Once you learn either Python or Ruby, contact me again, and I'll tell you how to go at it in detail. First you have to learn how to walk before you can run.

[dragonboy]

I do know assembly of a few older processors like 6502 and 68000 and Z80, but I never had the chance to use any of them.  I've tried making demos for old systems but I always fall asleep programming them.  Take for instance, a background scrolling demo, it seems really simple at first glance, but whenever I dive in I realize that I have to draw something, convert my drawing to numbers, set the GPU to the right mode, program it to load the graphic tiles, then to load the color palette, then to load the tile map, and to top that off I have to look back and forth through hardware documents to find what are the right registers to use for everything.  Programming just doesn't seem rewarding for me.  All this fuss just to display a picture.

[chriskot]

Have you tried GameMaker? It's pretty diverse, yet much simpler than programming something from scratch. Some of the best indie games use it. Also, the demo is free.

[Frychiko]

I do know assembly of a few older processors like 6502 and 68000 and Z80, but I never had the chance to use any of them.
...
and to top that off I have to look back and forth through hardware documents to find what are the right registers to use for everything.

Why the hell are you coding in assembly... on ancient machines.. when you're just starting out? Go and smack whoever said to do that. Start making games in high level languages on a pc. Start simple.

Forget about other gaming systems, compression of graphics, hardware limitations right now... that's completely irrelevant at this stage.

[Akira]

Forget about compression of graphics, hardware limitations right now... that's completely irrelevant.

...unless he wants to make a game for the snes or sega like he said in his post...

[Frychiko]

Yes, but first he needs to know how to actually make a game which is platform independent and would be best done in a higher level language on a system without any strict limitations and plenty of resources; good tutorials, documentation and help at hand. (imo)

[Beoran]

Exactly, assembly is only for programming for a very old console, you don't need it anymore these days to make a game. Gamemaker is not free, it's nor platform independent, and also, it's programming language is not something you will be able to use later for, say, a job interview. Ruby and Python are amongst the top 10 most widely known languages, and you can use them, together with the right libraries to make games relatively easily, without having to mess with all the low-level details. And Python or Ruby might help you land a job as a programmer later on. So I recommend you use either of those languages.

Oh yeah, the try ruby online link I gave you is working again, see how you like programming in a real high level language.

And you also have the Gosu development game library for ruby, which I hear is also very nice.
http://code.google.com/p/gosu/

In this tutorial, a character is moving over a background, and that in 30 lines of Ruby code:
http://code.google.com/p/gosu/wiki/RubyTutorial

If you'd try to do that in assembler for a console, I bet you'll need 300 lines or more! Why bother with assembler then? Most people don't have a SNES or a Megadrive anymore.  If you use Gosu or Rubygames, you can distribute versions for Windows, Mac OS X and Linux , all from the same source code, without any problems. 

[Akira]

hmmm yeah. i guess rereading through dragonboy's posts it probably would be better for him to go the high level way.
@beoran: people still develop for old platforms because its interesting or they like the way the old platforms feel or they are crazy. just look at grand theftendo.

i guess i'm just too much of a nostalgic old fool for you young'uns with your high level programming languages.

[Frychiko]

Young? I'd like to be that again..

[Ben2theEdge]

Speaking as both a hobbyist and a professional, I have 3 pieces of advice.

Before you do anything else I would write a design doc and lock down every feature, enemy, weapon, character, level, etc. that you want in the game. If you start a project and just keep adding stuff until it's "done" it will never be finished, you may never even get past the first level! Of course you can make changes as you see the need but the Design Doc will keep you focused and on a steady course.

Set deadlines. Even if they don't mean anything. And don't use vague deadlines like "before the end of the year" or "mid-summer". Make them concrete: November 12th. February 6th, etc. If deadlines weren't used by professionals we would never finish anything.

Finally, ambition is good but it must be kept focused. If you have many ideas, make many games. Find a "hook" for your project - one or two things that make it fun to play over and over - and focus on those. The more precision you use, the harder it is to miss your target. Observe that the best games don't attempt to do everything, but rather succeed in doing a few things very very well, in a way that's fun over and over again. Portal is a prime example of this philosophy. On the other hand games like Daiketana or Advent Rising are horror stories about games that tried to do everything and succeeded at nothing. Always keep in mind that If you can save those unused ideas for your next game!

Hope this helps!

[dragonboy]

How do high level languages work?  All the opcodes in assembly are like "MOVE A,B" which moves A into B, and "ADD A,B" which adds A into B.  All the assembly opcodes speak for themselves.  For high level opcodes you have instructions like "int" and "def" and "segren" and "felneb," what the heck do those supposed to do?

thankyou everyone for the advise!

[chriskot]

How do high level languages work?  All the opcodes in assembly are like "MOVE A,B" which moves A into B, and "ADD A,B" which adds A into B.  All the assembly opcodes speak for themselves.  For high level opcodes you have instructions like "int" and "def" and "segren" and "felneb," what the heck do those supposed to do?

Wow. The only programming languages you've ever used are assembly languages? Interesting.
Higher-Level languages are basically all about simplifying things that would become ridiculously complex in assembly, mostly though the use of variables. A higher-level language has many more commands but requires far fewer lines of code to write something substantial.

Gamemaker is not free, it's nor platform independent, and also, it's programming language is not something you will be able to use later for, say, a job interview.

True. The main reason that I recommended it is because it is a simple way to create a game very quickly. Most people have the patience to build something in GameMaker, whereas most people don't have the patience to program something substantial from scratch. Even if you can't use it for a job interview or something like that, it's a good way of working yourself up to other game-creating methods. Also, the demo is free, and if he wants to produce a 2D game, then the demo isn't really missing too much.

[dragonboy]

mostly though the use of variables.

assembly is all about using variables

[ptoing]

Most programming languages are.

What do you think why people made highlevel languages? Prolly not because Assembler is fiddley to work with and takes quite long to get stuff done, even if you are good with it.

[Ryona]

Speaking as both a hobbyist and a professional, I have 3 pieces of advice.

Before you do anything else I would write a design doc and lock down every feature, enemy, weapon, character, level, etc. that you want in the game. If you start a project and just keep adding stuff until it's "done" it will never be finished, you may never even get past the first level! Of course you can make changes as you see the need but the Design Doc will keep you focused and on a steady course.

Set deadlines. Even if they don't mean anything. And don't use vague deadlines like "before the end of the year" or "mid-summer". Make them concrete: November 12th. February 6th, etc. If deadlines weren't used by professionals we would never finish anything.

Finally, ambition is good but it must be kept focused. If you have many ideas, make many games. Find a "hook" for your project - one or two things that make it fun to play over and over - and focus on those. The more precision you use, the harder it is to miss your target. Observe that the best games don't attempt to do everything, but rather succeed in doing a few things very very well, in a way that's fun over and over again. Portal is a prime example of this philosophy. On the other hand games like Daiketana or Advent Rising are horror stories about games that tried to do everything and succeeded at nothing. Always keep in mind that If you can save those unused ideas for your next game!

Hope this helps!

All this definetly helps me right now concidering that I've been working on two games, and they have been progressing at a crawl. 
I'm going to have to take up on the advice and really get my ass in gear.

Great thread! 

[dragonboy]

I've looked through many tutorials of high-level languages and non of them tell me any stuff I need to know in making games, nor breaks it down remotely enough.  Hello World? why would I need to know this? I can easily type Hello World in note-pad and get the same result.

If they make these high-level programming languages to make things easier than assembly, why don't they have opcodes such as:

DISPLAY SPRITE: coordinates (123,201), size: 32x32, sprite number 53, 12 frames, 12 fps
COLLISION DETECTION: sprite 17, sprite 15, effect 75
MOVE SPRITE: 5 pixels left, 4 pixels up

Why can't anyone make a language with opcodes like that? because THAT would make video games easy to program.


How exactly would you guys know if assembly really is harder than high-level without knowing assembly?  Does anyone here know both assembly and high-level?  I'm starting to get a feeling that people only think assembly is hard because high-level is hard, and they hear other people saying high-level is much easy compared to assembly, and they think omg!

[AlexHW]

until you try, all you do then is speculate.

[ptoing]

I myself am no coder but I know plenty of people who are both excellent with ASM and high level stuff. And everyone of those would tell you getting stuff done is faster with high level languages.

Also these languages were not made primarily to make games with. What you would need is some kind of API. Like RGS (Retro Game System) for example. That still needs knowledge of Python and/or C.

[Beoran]

Ben2theedge, that's  good advice that even I have problems to adhere to for my hobby project. Gotta focus a bit more.

Yeah, it's true that gamemaker is even easier, for impatient people. Dragonboy,, if you are very impatient, you could try that first.

Of course , you need an API (that is, libraries) to write games in a high level language. That's what Pygame, Rubygame, or Gosu are good for, they really make game programming as easy as it can be, and you don't need to know any C or C++, just Puthon or Ruby, which are all easier to use and learn.

Dragon boy, you're in an interesting situation, knowing assembly but nothing more high level. If you want to learn how to program in a high level language, you'll have to learn the basics first, before you can go on and write a game. It's the same for assembler, really. In short, have a little patience with learning a language. That's what those "Hello world" examples are for, to give you an idea how to use the language.

Did you ever try to write Hello world in assembler? Look here for hello world for DOS assembler:  http://www2.latech.edu/~acm/helloworld/asm.html. That's 17 lines!

In Ruby it's just

puts "hello world"

That's the whole advantage of a high level language, no need to bother with details or opcodes, you use a high level view, in which everything can be  handle like an object, which you give commands to do things, and make queries from. But don't 'expect those languages to be like assembler. High level programing is somewhat different from assembler, you'll just have to grab the cow by the horns, and open your mind for something new. 


In Ruby, using Rubgame, managing sprites can be as easy as:
 
sprite_1 = Sprite.new(10, 20, "image1.png") # Make a new sprite at this position and with this image file loaded
sprite_2 = Sprite.new(30, 40, "image1.png") # Make a new sprite at this position and with this image file loaded
if sprite_1.collide_sprite?  sprite_2  # if sprite 1 collides with sprite 2 do something
 puts "Boom!" # just an example
end

How much easier do you want it? There are competitions in which people are able to write a game in
Python with Pygame or in Ruby with Rubygame or Gosu in only one weekend, but the people who do this,
did learn one of those languages first.  If you really don't have patience to learn how to program, then you don't
stand a chance to successfully write a big game.

Don't knock it until you have tried it! Install ruby and gosu or rubygames,  python and pygames and give both languages
a spin to see what you like best. If you choose Ruby, I'll be able to mentor you for a while (together with anyone else who
wants to learn how to make games in Ruby), but not on this mailing list. Please send me a private message for that.

[dragonboy]

until you try, all you do then is speculate.

I did try several times.  I can't understand high-level nomatter how hard I try and how hard I research.

[Beoran]

Sorry, but it sounds to me like you've been trying only for a short while. Please don't be too impatient. What exactly is the problem? If you want me to tutor you a bit, I'm game, just contact me by private message, we can set up a meeting over IRC or skype or something.

[Helm]

Beoran, you're being kinda wonderful! I hope you like cookies.

dragonboy: it's strange that you can understand assembler but not a considerably easier to handle high level language. Where exactly do you get stuck in trying to make something in high level that you can do in assembler? Also, especially since you're getting such good help in this thread, why not post some of your code or game-attempts in assembler so people can critique what you're doing wrong in specific.

Also though this forum isn't about programming, I'd rather this thread ran a while more in the open than in PMs because others of us that dabble I think could benefit from this discussion. So don't worry about it being OT.

[dragonboy]

Sorry, but it sounds to me like you've been trying only for a short while. Please don't be too impatient. What exactly is the problem? If you want me to tutor you a bit, I'm game, just contact me by private message, we can set up a meeting over IRC or skype or something.

I answered his post before I read yours.  Thankyou for those sprite opcodes you told me about.  I would like to be tutored!

[willfaulds]

I'm going to just through these 2 into the mix;

Flash/actionscript = by no means a perfect language but it is superblyl documented on the internet and really very easy to use. There are loads of tutorials, even specific to gaming, available.

A pre made game engine such as Garage Games Torque engine = a fairly easy and reasonably documented head start.


Both of these suggestions are very genre specific though. What type of game are you going for?

[Beoran]

Ok, so seeing we have the moderator's blessing, I'll tutorial a bit here too, on high level languages, using Ruby as an example. But please ask me relatively specific questions ,and tell me if it gets out of hand. Please open http://tryruby.hobix.com/ so you can try things I'm telling yourself. Don't worry if you want to use a different language, much of what you learn about Ruby can be used in other high level languages by changing the notation a bit.

Ok, so any game console or pc has a CPU that does the calculations, RAM memory to temporarily store data, and all kinds of input and output and storage devices you can use in various ways, like the graphics chip , the mouse, keyboard or joypad, etc. In assembler, you're working with registers, memory locations, and input and output ports. Registers are special "locations" in the cpu you can store numbers in to perform calulations to make descions based upon those calculations, and other various operations.  Memory locations are "locations", addresssed by a numerical index in the memory that you can read from or store data to. Some memory locations are "special", and connected to the various devices. Ports can be read or written to in order to communicate with the devices.

To get anything done in  assembler, you'll fill in the registers, either with constants, or by reading from ports or memory, and then you perform the needed operations, finally writing the data to memory or a port (if that is needed). It seems simple at first sight, however, you are limited to the instructions that the CPU understands. That means to get anything done you have to use a lot of different instructions to get anything done.
In a high level language, all these steps are "hidden" and simplified into one step. On a video game console, when writing in assembler, you can use the graphics chip to display sprites on the screen, etc. In a high level language, you don't access the CPU or the memory or the graphics chip directly. Rather, you let the programing language handle the details.

The most simple thing you can do in programming is math. You need math for all games (to move sprites, for collisions, etc.)
For example, in ruby, to make a sum, you would simply write it like you do in math:
1 + 2
>> 3
And you should be able too guess what 3 - 2 should do. As for multiplications, we write
2 * 3
>> 6
I know it's funny, but in most programing languages, * is used for multiplication.
For division it's like this:
6 / 2
>> 3

That's all very simple, however, what if you want to use the result later? It's best to store the result somewhere.
a = 1 + 2
>> 3
The = here is different from math. It doesnt' mean "equals", but "store", as in store into the variable called a
the sum of 1 and 2. What's a variable? Simply a named "thing" or "place" that you can use to store things in.

Now what will a + 3 do?
a + 3
>> 6
The computer remembers that we stored 3 in a , so now ,it takes the value stored in a, and adds 3 to it, giving 6

That's all fine and dandy, of course, but the burning question is of course, how do you do thing like accessing the graphics card, drawing sprites to the screen, playing music, etc? For such things, you will use 'libraries'. Libraries are pre-built  sets of functionality that you can reuse in your own program. But to use those libraries, you have to understand how to call them from the programming language you are using.

The most simple way to access functionality that is present in the language is to invoke it though a name. For example, to write something to the output you can use the name "puts",  short for "PUT on the Screen"  together with what you want to write.

puts 3
3
>> nil

You could also write puts(3) in Ruby, here it's the same as puts 3.
You're just telling the computer, hey, do this funky thing called "puts".  The computer then looks into the libraries of Ruby,
and finds that puts means you gotta write  what comes after it to the output.

Ok, that's part 1 of my very basic intruduction to high level languages. please tell me if it is too simple. More to come later based upon your questions.

[dragonboy]

Okay I'm going to try this on the Ruby program I just downloaded, but where exactly in the ruby folder is the actual program you write the codes on?

[Beoran]

Ok, so you downloaded the Windows one click installer for Ruby (http://rubyforge.org/frs/download.php/29263/ruby186-26.exe) and installed it? Good. Could you please tel me in what folder you installed it? (You should know since the installer normally asks you, normally it's in C:\Ruby )
You'll also have to install Gosu or Rubygame, as they are libraries to write games. I reccomend you install Rubygame, because that's what I use and know best. Rubygame for windows is here: http://sourceforge.net/project/downloading.php?group_id=172781&use_mirror=mesh&filename=rubygame-2.3.0-x86-mswin32-60.gem&65252267. T read about how to install this "gem" file, please read here:
http://rubygame.wiki.sourceforge.net/win32_install_gem
You'll have to download and install a lot of stuff before Rubygame works, so perhaps you'd like to wait a couple of days until you have given Ruby itself a solid try. But I guess you're burning with impatience, so, go ahead with installing Rubygame if you feel you "just can't wait to be king".

So let me explain a bit more on how to get started writing programs for a high level language. First of all, you'll need a text editor that lets you write "plain text" format. You could just use notepad, but that will be a bit hard to use because it doesn't have anything convenient to help you programing. That's why it's more easy to use a "programmer's editor". A programmer's editor will  help you because it will color the program in different colors (red, blue, gree, etc) as you are typing it to help you understand it. The programmer's editor also allows you to "run" the program, that is, make it do what you are telling it to do, by pressing a button.   

Now, fortunately for us, in the windows one click installer for Ruby, there is a programmer's editor included, called 'SciTE'. You should find that either on your desktop or somewhere in your start menu (It has a kind of a blue ball with "ribs" icon). Please start that program.  You'll have an "untitled" document to begin with. Now, let's save a file that will be our first program. In the menu, go to "File" -> "Save As". With the "create folder" button in the file dialog, let's make a folder to hold our programs, perhaps on your desktop or wherever you thin is convenient. You can call it whatever you like , like "programs". Then go inside that newly made folder by (double) clicking on i. Then type the name of the program in the  name box, again, you can call it whatever you like, but I just called it "program1.rb". The .rb at the end is important, because it will tell SciTE and the Windows operating system that that file is a ruby program, so they both know how to handle it. 

Now just type in the document
puts 123
Then save the document by going File->Save or clicking the save icon on the toolbar, or by pressing the shortcut control-s. Now, in the menu, go to Tools -> Go   or press the F5 shortcut button. A window should pop up with the following in it (among others):
123
That's the "output window" where you can see your program working. You tell it to put 123 in the output and it does so. So, that's how you can write your program and get it to run (do what you are telling it to do).

If you can get all that a working OK, then you're ready to start with the serious work. So tell me how you're doing, and in the next installment, I'll go further with more useful explanations on high level game programming.



 

[Beoran]

Next short installment: Errors in your program

What's with errors? Evey high level programming language has some rules you have to follow for it to understand what you want it to do. Those rules are called the "syntax" of that program. If you don't stick to those rules, the programing language will not understand what you want it to do, or worse, in some cases, misunderstand what you want it to do. If the high level programming language really doesn't understand what you want it to do, it will stop running your program and give you an error message.

You can try it by making a program1.rb that contains just of this
a = 10 +
and run it (with F5 or Tools/go, remember) and this is what you'll get

program1.rb:1: syntax error, unexpected $end
a = 10 +

In other words, the programming language is complaining about the "syntax", that is, you are not following the rules. you want to store a sum into a but the sum of 10 and what? So the programming language just gives up and says: hey, you made an error there, on line 1 of your program. I'm outta here!

Let's correct our program and run it again: change it to
a = 10 + 10
puts a
And run it, and you will see "20" in the output window. No errors, since you're following the rules of the Ruby language, so Ruby understands what you want it to do for you, and does it.

[Beoran]

Next installment! On to a bit about handling text and some types of commands named "methods"

Ok, now we already talked about how to do simple math in Ruby. And you also know how to display something on the screen using puts.
How about working with text? That 's important for things like dialogs between characters and the NPC's, high score lists, etc.

So, let's see how to write the words The dragon eats the goat to the output window. You just do

puts "The dragon eats the goat"

Why is the text between double quotes? Because that's how the programming language can see that it's a text, and not soe insruction for what it should do. In the jargon of computer programmers, such text is called a "string" like a bunch of letters stringed together on a wire. In Ruby (but not in some other programming languages), you can also put text between single quotes, like

puts 'The dragon eats the goat'

And of course, with text strings you can do several things, a bit like how you can calculate with numbers. For example
s = "Bob's" + " goat"
puts s
will output Bob's goat when you run it as a program. The + can glue two text strings to each other, in the order given. And of course,
you can store a string in a variable, and fetch it again later, like , when you want to display it in the output  window.

Now , let's see how numbers and text strings work together.
Let's try this:
s = "The length of Bob's name is " + 3
puts s
Well, you'll get an error like this:
TypeError: can't convert Fixnum into String

Why? Because numbers and letters aren't directly compatible with each other, at least not in Ruby.  You'll have to change the 3 from a number to a text string like this:

s = "The length of Bob's name is " + 3.to_s
puts s

That's something new for you there. What's up with the  period . and the to_s after the 3?
Well, in Ruby, you can use a command like puts, and the programing language will look it up in it's currently open libraries to find what it has to do. However, you can also tell Ruby that it has to do something with an individual number or string. To do that, you put a period (.) behind the thing you want to work with, followed by the name of the command that tells what you want Ruby to do with that object. In this case , you're telling Ruby, hey, i want you to take number 3, and convert it to a text String. "to_s" is short for String. In Ruby, it's common to see many short names for commands, since they're more quick to type, and also less work to remember in the long run.

There are many more things that you can ask Ruby to do to text, numbers or values. Also, even when you tore the values into variables, you can still ask Ruby to perform the commands on them that it could do when dealing with the value direcly. Another example:

b = "Bob"
l = b.length
puts "Bob's name is " + l.to_s + " characters long"
will write "Bob's name is 3 characters long" to output. You're storing the string "Bob" in a variable called b. then You ask Ruby to take the length of that text string, that is, the amount of characters in it, and store it into a variable named l
Finally, you let  it change the length, which is a number, to text, and then glue all the parts of the text together, and then write it to output.

Commands like puts are called "functions" or  "procedures",  in the programmer's jargon. They're just instructions that the programming language looks up in the currently active libraries of the programing language, and then performs.  Commands like .to_s or .length are called "methods".  In Ruby, there's not too much difference between the two but it will help if you know the programmer's jargon a bit.

How to find out what "methods" a number or string or a value in a variable has? In other words, how to find out what ruby can do with them?  Well, in Ruby that's simple because there's also a method to get the methods, conveniently caled .methods. Just try this:
puts 3.methods
puts "hello".methods

You'll get oodles of text in your output window, all of these are the names of the methods for the number 3 or for the text "hello" that Ruby knows.
To find out what all these commands do, you can look it up in the documentation of Ruby, like here: http://www.ruby-doc.org/core-1.8.6/index.html
But for now, we don't need all those commands, but I'lll leave it up to you to explore a bit. Don't wory about using a method (command)  that Ruby doesn't know, it will simply give an error message and  stop there.

[Beoran]

Next installment: a bit about loading libraries, modules, sub-modules and constants.

Ok, so you're probably roaring to go, and actualy do something that is actually related to game programing. Well, we're almost ready to start... but first, I have walk a last side-road for a while, sorry for that.

As you may have realised from looking at what puts 3.methods wrote on the screen, there is a huge amount of commands available to Ruby. So much, in fact, that probably no one would need all of them, and that the name of the command would have to become very long and perhaps confusing if all those commands were available directly.  To prevent this mess, related commands (procedures, functions) are grouped together into neat packages called "modules" in programmer lingo.

A good example of modules is the Math module. It contains more advances math commands, like trigonometry, or  the square root which is abbreviated to sqrt like this:
puts Math.sqrt(4)
-> will write 2.0 to the output.

"Math" is a module, an it contains several math related commands, like Math.cos Math.sin Math.tan Math.sqrt . So, what Math.now means to Ruby is, look into the Math module, for the sqrt command, and do what it must do. It's actually quite similar to
s = "Bob"
puts s.length
Where you put the text bob into s ,and then tell ruby that it has to look up the command/method length into the commands that are related to text strings, and hen do what it has to do for that string.

OK, but what if you get tired of always writing the name of the module in front of the command? Well, then you can do it like this:
include Math
puts sqrt(2)
the include command will take all commands that are in the Math module, and mke them direcly available, so you don't need to type the name of the module anymore.

Now, a bit about constants.
What's a constant? Well, it's much like a variable, that is , a named location where a value has been stored. However, different from a variable, you don' t want it to change. An example might be the value of PI, you know from the formula of the circle circumference is 2 times the radius of the circle times pi. Well, in Ruby, this value is in the Math module. Try this:
puts Math::PI
-> 3.14159265358979

The value of PI is something that's not supposed to change, so, that's why it's a constant. You use the :: in stead of a . to look up the value of PI in the math module, because PI is not a command, just a constant, and it would confuse Ruby if you mixed up the two of them. How does Ruby know that PI is supposed to be a constant and not a variable? Well, simple, it looks at the first letter, and if that's a capital letter, it treats the thing thus named like a constant.

Did you notice the name of the Math module is also a capital letter? Yes, it's a constant , because, you probably don't want to change the contents of that module (the functions that it contains).

One other problem with the huge amount of commands potentially available to Ruby  is speed. The more commands that Ruby has to know about, the more time it has to spend looking them up, slowing down things. Just like a clerk in a big book shop will need more time to find a book than one working in a tiny book shop. So, that's why all of these commands have been split up into different parts, called "libraries". Almost all programing languages do split up their functionality over libraries, so you can make the program run on a "need to know" basis, which is good for speed and simplicity. Libraries also allow many different people to work on ading new commands to a programmin glanguage.

A good example of a library is of course the rubygame library, which contains a lot of commands needed for working with the screen ,audio, etc, for making games. Normally the commands in that librar are not available until you install that library, and also tell Ruby to use the library inside your program.  You'll have to tell Ruby that you really want to also use the commands related to game programming in rubygame, in the "rubygame" library. You do that like this:

require 'rubygems'
require 'rubygame'
Rubygame.init
Rubygame.quit

This program does nothing but start up Rubygame and close it down again, but it should run without giving any errors if rubygame is installed correctly.

The require 'rubygame' command tells Ruby that you really need the Rubygame library, and makes it so that Ruby will look up commands in that library.  The name of the library is between quotes, because names of libraries need to be text strings in ruby. You also need a require "rubygems" before that, because the Rubygame library itself needs some stuff that's inside a different library called "rubygems".  Once the rubugame library has ben loaded, the Rubygame module that is inside the rubygame library, and all the commands it knows about became available for use.

Which means were're almost ready to start displaying something on the screen!

But perhaps it's better if I let you digest al the stuff I wrote above before I continue. I eagerly await your questions.

[PypeBros]

Cents follow:

First you can't make the game without the game engine but how would you know how the game engine should work if you don't know what sized sprites your going to use and how many of them without drawing the graphics first?  How do you stay attentive drawing the graphics?

You can usually have two kind of game engines: those that are limited to what the hardware allows, and those that try to hide hardware limitations to the programmer. The number of frames, etc. should not be a limitation, though. At worst, you'll have (on gaming hardware) restrictions such as "16x16, 32x16, 16x32, 32x32, 64x32, 32x64 or 64x64 only", and have may end up with a 24x24 sprite on a 32x32 frame with 70% of the pixels being fully transparent.

(I'm thinking of making this game for either a Sega Genesis or a Super Nintendo)

I'd say forget it, esp. for the SNES, because it has really ugly programming (assembler only) and unless you're a veteran programmer, you'll completely get overwhelmed by technical details even with something "as simple" as the game engine of (say) Cave Story ... The Nintendo DS (and the PSP to some extent), on the other hand, show similar hardware than those beloved 16-bit consoles, but with 32-bit CPUs that can be dealt with like a PC, with "higher" level language (C, C++). Not that it will make your work as easy as in a flash game, but well, playing a game on a gaming system is definitely more fun than with a keyboard

How do you come up with a system of designing the game that allows you to do EVERYTHING?!

You don't. Not that way, at least. You can come up with an engine that handles 90% of your ideas, and you write custom code for the remaining 10%. Then you ensure you can "register" custom code to the game engine and make it trigger your custom code e.g. when the player enters a given area.

I have a lot of crazy game ideas that don't involve just having enemy sprites walking on a non-moving background layer.  For example, having a wall in the background crack and then the ceiling collapse on you, you can't achive with just the "sprites on one playfield background" kind of engine.  It wouldn't work because it will require the top of the background to be turned into two backgrounds and the second will be also as much as part of the game as the first background.

In a game engine, i'd be handling a situation like that by first editing the map (e.g. so that a previously solid area now is no longer solid) and generating sprites/polygons for the cracking wall.

What about compressing graphics?: If you do all the decompressing before you start the level you might run into RAM limitations; if you do real-time compression you might have som miserable slowdowns (unfortuanately, a lot of Snes games relied on this method, I heard from someone); and if you don't use compression you might run into ROM problems.

Guys handled that with extra hardware ... cartridge shipping RAM plus ROM and a decompressing "DMA" chip that moves and unpacks at once while the (slow) CPU of the console does the rest. Honnestly, if you instead opt for the DS, you'll have 4MB of RAM, +640KB of video ram and plenty of CPU time to unpack the next sequence... Alternative is to have some kind of "intermission" sequence where CPU needs are limited (e.g. a 'boost up' in a shoot'm'up where there are no ennemies to avoid) so that you can focus on unpacking the rest of the level. That's something you'll work on *wayy* after, anyway. This is typically a "technical detail" that you can handle later, just having two playable zones during your demo times.

** edit after a couple of PM exchanged with Beoran **
C/C++ is afaik "state of the art" (maybe the "Golden Way" too) to squeeze the best of your modern handheld gaming console (GBA, DS, PSP), but that golden way is made of spiky tiles that may throw you deep into the pitfall of segmentation fault that only meditation of the guru can avoid. Put otherwise, it's certainly not the easiest thing to start with if you have no previous experience on game programming.

[Beoran]

Pipebros:
Just a few nitpicks here, and I don't want to sound to harsh, so please don't take offense, ok?

The "level" of a language is how much work it takes out of your hands and does for you. C is not a high level language. It is a low-level language, since it almost does nothing for you implicitly. C++ is the a low level language C with a lot of high level stuff bolted on in a rather tricky way.  Of the currently top 10 popular languages (Google TIOBE Index), only Python or Ruby are truly high level and feature-complete languages. All other popular languages are either low level (C),  middle-level(Java,C#, Javascript) or miss some useful features (PHP, Basic) or are quite tricky to program in (C++, Perl).

IMO, C or C++ are only about 2 times faster to program in than assembler. Ruby and Python are easily 10 times faster to develop in than in assembler. That's why I went ahead with my series above as intro to game programing in Ruby for Dragonboy and other interested people here. Ruby or Python really are the fastest ways to get started with game programing and get something done, barring things like Gamemaker or RPG Maker (which also uses Ruby, in it's latest version, by the way). Dragonboy was already and understandably losing his patience with assembler, and thats why I chose to recommend him to start with Ruby (or Python) in stead. Although it cannot completely remove the learning curve, it will lead to encouraging results that much quicker, at least, I hope.

[Luzeke]

Removing the learning curve is a bit pointless though, since it's the curve in which you learn, hence the name. 

Anyway, I use Multimedia Fusion 2 for my own projects. It's available from www.clickteam.com and the standard version costs $100. So it's not free, but not expensive. Any sort 2D game is possible to do with it, and there's a fairly large community for it too.

I'd also recommend this book, On Game Design. It's a great book about game design, we had it in our first course on the university and I've probably read through it about a dozen times or more. Definitely a good read if you're into games. The author is also a really nice guy. 

Good luck with the game making man!

[dragonboy]

Sorry, my family keeps asking me to do stuff.  I downloaded the program but the RubyGames doesn't show up in my folder.

edit: wait I found it but it says "can't reconize file type" when I click on it, and besides all these little glitchy files are slowing my computer down.

[Beoran]

Dragonboy, normally, installing  Ruby and Rubygames does not slows your computer down. Software that isn't used does nothing. I installed Ruby using the one click installer on one of my company' s PC and it's easy and fast. Probably there is something you didn't quite understand. Which is not a problem, I'll try to make it more clear to you.

First of all, to install ruby, look at the instructions here:
http://ruby.about.com/od/tutorials/ht/installrubywin.htm

You simply ave to download the ruby ine click installer from the link I ssent you before, and then double click on it, then the installer should appear on the screen, and you'll just have to click next, next, etc. After you installed Ruby, were you able to find SciTE in the start menu? You may need to look a bit around in the menu or scroll it a bit.

If you want to get some live help with installing Rubygame, you can try to connect to IRC using http://www.mibbit.com/
Choose Freenode.net from the drop down menu, fill in Dragonboy as your nickname, and #rubygame in the chanel box.
To ask questions about installing ruby, you could do the same but fill in #ruby as the channel name. 
IRC is a kind of chat that is very popular with computer programers, so I reccomend you use it. I'll be hanging around
a bit on both #ruby and #rubygame channels the next few days, so you can also ask me there. But I'm in Europe, so keep in mind the time difference.

I have some questions for you as well:

Do you have a basic understanding of how to work with your operating system (windows?), how to work with files, copy them, and uncompress zip files, and how to install applications? If you're unsure about all these things, please ask me, or please read the online help of your OS, or borrow a book about your OS in the library, or look at one of the many tutorials like this one: http://www.helpwithpcs.com/courses/windows-xp-tutorial-desktop.htm

Do you understand what I'm writing or is my English too bad or too difficult for you? I'm not a native English speaker, so perhaps I used some words that are wrong? Don't be afraid to ask! What are you using, Windows XP, or Windows Vista? Were you able to install the Ruby one click installer? Did you understand the instructions on how to install Ruby and Rubygames?

Anyway, he most important thing is to hang in there! You will have to learn if you want to program games, and it will take some time,
but I can assure you it's all worth it. I'm sure you can do it as long as you keep it up.

[dragonboy]

I downloaded and installed Ruby Games several times.  I did all what the "how to download/install Ruby Games" said.

I've found the icon for Ruby Games but my computer doesn't know what it's supposed to "open with."  My computer was never good at detecting file types for some reason.

My folder is already full of tons of copies of the same stuff.


EDIT: Is it the SciTE thing?  I clicked on the SciTE thing and it looks like a notepad only with a "language" menu list.

[Beoran]

Ah, I see. I think you installed Ruby correctly, but didn't  know how to get started with it.

Yes, to start programing, you need SciTE, that "notepad-like" program! Programming is done by writing texts in a sort of "better" notepad, and then letting the programming language run (= execute, do what you tell to do in your program) them.  Go back and read the message above, from Saturday 2 august at 07:56:21 AM about how to use SciTE for programing in Ruby.

In short, try to write things like

puts 123

in that "notepad thing", SciTE, save the file as program1.rb, and then you can run the program you just wrote and saved by pressing F5, or going in the menu and doing Tools->Go. Something (unimpressing) should happen, and the 123 will appear in a sepaate window. That is the output of your program. Please tell me if you have any problems getting this far.

[Beoran]

Dragonboy are you still with us? Is anyone else interested in me continuing my tutorials this thread?  If neither is the case, then I'll let this thread rest for now.

[Helm]

I really am. But I guess if I'm all there is yeah, time to pack it in.

[dragonboy]

Cents follow:

First you can't make the game without the game engine but how would you know how the game engine should work if you don't know what sized sprites your going to use and how many of them without drawing the graphics first?  How do you stay attentive drawing the graphics?

You can usually have two kind of game engines: those that are limited to what the hardware allows, and those that try to hide hardware limitations to the programmer. The number of frames, etc. should not be a limitation, though. At worst, you'll have (on gaming hardware) restrictions such as "16x16, 32x16, 16x32, 32x32, 64x32, 32x64 or 64x64 only", and have may end up with a 24x24 sprite on a 32x32 frame with 70% of the pixels being fully transparent.

(I'm thinking of making this game for either a Sega Genesis or a Super Nintendo)

I'd say forget it, esp. for the SNES, because it has really ugly programming (assembler only) and unless you're a veteran programmer, you'll completely get overwhelmed by technical details even with something "as simple" as the game engine of (say) Cave Story ... The Nintendo DS (and the PSP to some extent), on the other hand, show similar hardware than those beloved 16-bit consoles, but with 32-bit CPUs that can be dealt with like a PC, with "higher" level language (C, C++). Not that it will make your work as easy as in a flash game, but well, playing a game on a gaming system is definitely more fun than with a keyboard

How do you come up with a system of designing the game that allows you to do EVERYTHING?!

You don't. Not that way, at least. You can come up with an engine that handles 90% of your ideas, and you write custom code for the remaining 10%. Then you ensure you can "register" custom code to the game engine and make it trigger your custom code e.g. when the player enters a given area.

I have a lot of crazy game ideas that don't involve just having enemy sprites walking on a non-moving background layer.  For example, having a wall in the background crack and then the ceiling collapse on you, you can't achive with just the "sprites on one playfield background" kind of engine.  It wouldn't work because it will require the top of the background to be turned into two backgrounds and the second will be also as much as part of the game as the first background.

In a game engine, i'd be handling a situation like that by first editing the map (e.g. so that a previously solid area now is no longer solid) and generating sprites/polygons for the cracking wall.

What about compressing graphics?: If you do all the decompressing before you start the level you might run into RAM limitations; if you do real-time compression you might have som miserable slowdowns (unfortuanately, a lot of Snes games relied on this method, I heard from someone); and if you don't use compression you might run into ROM problems.

Guys handled that with extra hardware ... cartridge shipping RAM plus ROM and a decompressing "DMA" chip that moves and unpacks at once while the (slow) CPU of the console does the rest. Honnestly, if you instead opt for the DS, you'll have 4MB of RAM, +640KB of video ram and plenty of CPU time to unpack the next sequence... Alternative is to have some kind of "intermission" sequence where CPU needs are limited (e.g. a 'boost up' in a shoot'm'up where there are no ennemies to avoid) so that you can focus on unpacking the rest of the level. That's something you'll work on *wayy* after, anyway. This is typically a "technical detail" that you can handle later, just having two playable zones during your demo times.

** edit after a couple of PM exchanged with Beoran **
C/C++ is afaik "state of the art" (maybe the "Golden Way" too) to squeeze the best of your modern handheld gaming console (GBA, DS, PSP), but that golden way is made of spiky tiles that may throw you deep into the pitfall of segmentation fault that only meditation of the guru can avoid. Put otherwise, it's certainly not the easiest thing to start with if you have no previous experience on game programming.

I read some interviews with real programmers who worked on old 16-bit games.  Believe it or not, most Super Nintendo were NOT written in assembly, instead they were written in a scripting language.

When using raw assembly, the 65816 running at 3.58 mhz is actually almost as fast as a 68000 running at 7.67 mhz, but because of the scripting languages used, this is not the case.  Motorola 68000 has very orthogonal and more powerful instruction set, but is held back from having every instruction using a very large number of cycles.  The 65816's instruction set is generally weaker, but every instruction takes by far less cycles to perform than the 68000 does.  Thanks to the fast instructions, the 65816 is near twice as fast as a 68000 running the same speed, WHEN they are both fully optimized; but when they are not fully optimized, the 65816 falls back in speed more than the 68000 does.  This is because of the 65816's weaker instruction set. 

With the 68000, you often get the code right (fully or near fully optimized) the first time.  When you do 65816 assembly, chances are, the code will be far from perfect on the first try, and it would need a very large amount of hand optimizing to reach it's full potential.  When the 65816 code is fully optimized there is a huge huge difference in speed compared to unoptimized 65816 code.  Much, much larger than the difference between unoptimized and optimized 68000 code.

This gets way, way exaggerated once you use higher-level/scripting language and have the computer do all the translating into assembly for you.  Big complicated things like games were programmed with script-engines to speed-up development.  Add to that, Nintendo went all cheapskate, and limited the amount of 3.58 Mhz game ROMs and made far too many games in 2.68 Mhz, just to make a little extra profit on game carts.

Add all of this up, and the Super Nintendo's CPU only ran about a hundredth of what it was actually capable of doing.  The only exceptions to this was, Space Megaforce, Smash TV, Wild Gun, and maybe very few others.

[Zurnathus]

this place might answer some of your questions
http://jharbour.com/

the Game Dev tutorials are about programming for the GBA, which is in C & assembly. so maybe it will be a little more familiar territory for you
you can always go to gamedev.net of course & read up one what game designing is & the process invovled...it really hasn't changed much since the old days, just that you have many more people involved in the process for a 3D game

as for a language to choose, it may seem like a chore (& it is) but learning a higher level language is best if you're making games. they've recommended some really good ones here, like Python & Ruby...Flash is another avenue you could try, it's basically an "any idiot can do it" language. & if you don't believe me do a search in the search engine of your choice for flash games & you will see that many idiots are doing it!! (& that's not an insult)

[PypeBros]

I read some interviews with real programmers who worked on old 16-bit games.  Believe it or not, most Super Nintendo were NOT written in assembly, instead they were written in a scripting language.
( ...)
  Big complicated things like games were programmed with script-engines to speed-up development.  Add to that, Nintendo went all cheapskate, and limited the amount of 3.58 Mhz game ROMs and made far too many games in 2.68 Mhz, just to make a little extra profit on game carts.

Hm. Interesting thing. Well, not that it surprises me lots, as that's somehow the approach i'm following on the DS in my own hobby game, and it's been the approach followed by Eric Chahi for Another World as well as by Lucas Arts for Maniac Mansion and further similar games. Yet, the core of the game -- that is the game engine itself -- that performs repetitive and things alike such as detecting collisions, manage the sprite list, etc. will likely be written for efficiency. Same goes for special effects that are triggered by the horizontal retrace -- that will be the job of the system programmer.

All the game logic, e.g. what to do when some collision occur, which action to trigger when a button is pressed in this or that circumstances, how to lit candles and open the door when you walk on that secret step and throw snakes at you if you walk on the wrong one ... All this can safely be done with a scripting language as it's "on event" only. And yes, it will represent the largest part of the code being written for the game.

If you tried to write *that* in an optimized form too, your game development would turn into a complete nightmare. The slightest change in any dialog or puzzle or whatever could completely trash your optimization -- or force you to rewrite large chunk of code just because you need one extra register somewhere

[Beoran]

Yes, that's basically the way to do it. The point is that with things like Pygame or Rubygame you get the low level stuff basically pre-programed for you "for free", and then you can concentrate on the high level logic in the "scripting" language (Python or Ruby, respecively), as most of the hard work has already been done for you.

Dragonboy, if you're still up to it, I can continue my tutorial

[Atnas]

If not for him, then please for me, if you have the time. I'm really interested and have learned a lot from your previous posts in this thread.

[Helm]

Same. It's very discouraging that dragonboy hasn't so much as said thank you for all your efforts, but I will. Thanks. So far it's been a good primer.

[Beoran]

Ok, I'm more than willing to carry on my tutorial, however, from what point should I continue? If you guys are interested, were you able to install Ruby and get started with using it? Should I start again, explaining Ruby from the very start, or just continue from where I got with Dragonboy, at the module level?

[Atnas]

I was able to install ruby and also follow your previous posts to the letter. (already had scite because I do a little php, html, and css, but about a year ago I tried to write a ruby program based on my rudimentary knowlege of rpg maker scripting, but I didn't have ruby installed so it didn't work, haha.)

The only part that wouldn't work for me was installing the gem file. I got an error every time I tried to do so.

ERROR: While executing gem ... <Gem::GemNotFoundException>
Could not find rubygame-2.0.1-mswin32.gem <> 0> in any repository

And I did tell it where to look. Stumped!

[Helm]

Beoran, I'm interested in seeing how you go from the level you're at right now to coding a simple platformer or whatnot. I have some experience with script languages like in Game Maker or AGS, I am just interested to see how somebody makes a clean base for that sort of thing, and also how the data is structured when you're receiving very complicated input from the player like in a platform game and is interpreted meaningfully and bug-free by the program. I am not actively programming as I read these, I just want to understand the logic behind the process.

[gamingjustin]

To dragonboy (and in general): [NOTE: These are my thoughts on a solo project.] You sound quite enthused about developing a game, which is great! But, try not to drown before you get in the water, you know? I think it is most important to design something you would enjoy playing. Design a game like you're the only one who matters. Design what you think others will like and it can become very difficult to focus; the more personally attached to your game the better. Design a game disregarding technical limitations of any kind. Is it really worth sacrificing a great idea just to squeeze it onto your favorite system (like Megadrive/SNES)? Even abstract ideas that are potentially great (but don't exist to play) far outweigh a technical example or demo of physics (or something of the like).

The most famous example is Cave Story; made by one person over the course of five years, mostly during late hours as a hobby (he already had a job and family, after all). Having read a few interviews he described no direction and no planning involved. When asked how he composed the music he responded something like "I'd put down a few notes. If they sounded good I kept them, if I disliked them I got rid of them. I repeated this process." I appreciate that kind of work-flow and philosophy, despite not always having the luxury of working at a "relaxed" pace. I get the sense that Cave Story was created at a snails pace; logically, thoughtfully, lots of retreads and reworkings. When (not if) you get a chance to play it you will soon realize (if you haven't already) this game is almost perfect. Really. Nothing feels tacked on, it doesn't feel pushy, it doesn't hold your hand or guide you along. It's polished and wholesomely enjoyable. http://www.miraigamer.net/cavestory/ And YES it is for Mac as well, and YES it has been translated into English. So for all who enjoy good games, good design, and good inspiration-- download this sucker now.

[Beoran]

Gaminjustin, I agree with your saying. Thanks for the tip on cave story, I must say it is *very nice*, and it even has a Linux version. This game also uses SDL. 

Atna, if you can't get Rubygame installed, perhaps you could try Ruby SDL in stead ? It's slightly more difficult to use, but the available functionality is even better than that of Rubygame. I'm in the process of switching to rubysdl myself, because I need those extras that Rubygame doesn't have yet. You can read more about how to install it here:

http://www.kmc.gr.jp/~ohai/rubysdl_download.en.html

Look for ruby/SDL version 2.0.1

You may need to install a different ruby or this though, the mswin32 ruby.
I'm sorry I can't be more helpful with a windows install, I use Linux at home.

[Beoran]

Ok, the next step in my tutorial, drawing something to the screen. I'll be using Ruby SDL this time, so sorry if anyone already installed Rubygames (it's not that different).

But first, something new about programming in Ruby.
When programing, you are writing in a language that is made to be easy to understand by the computer,
but which may sometimes be less clear to a human later on. That's why it's important to "document"
your programs. To document your programs simply means, to add a human-readable text
to the program that explains what you are doing. Such human-readable texts are called comments.
The programming language will ignore the contents of the comments, but humans can read them,
and certain tools can be used to extract them from the program for further documentation.

Now, how to add comments to your program?  In Ruby there are two ways to write coments.
The first one is like this:

Code: [Select]

=begin
 This is a comment. It can consist of many lines.
 Note that both = signs have to be at the very beginning of the line,
 so you can't put anything before them
=end

The second way to write comments is like this

Code: [Select]

# This is a one line comment. It begins with a hash sigh. You cannot write it over many lines,
# unless if you write another # sign in front of  the comment for the next line.
puts "Hello"  # This is another comment. You are allowed to put non-comment stuff in front of this comment.

From now on, I'll explain what I am doing in my ruby program inside the program itself, using comments.
That way, it's more easy for me to explain, and I hope, more easy to understand what each step does,
and also, you can copy the program as a whole and run it easily.

So, let's begin and draw something on the screen already!

Code: [Select]

require 'rubygems'
# Load the rubygems library. Most Ruby programs need the functionality of this library.
require 'sdl'
# Load the SDL library. We'll use it for accessing the screen.

screen = SDL::Screen.open(640, 480, 0, 0)
# With this, we open the screen in a 640 pixels wide by 480 pixels high.
# For now you should just get a window. I'll explain how to make a full-screen apllication later.
# Hint: it has to do with the last two zeroes.  ^_~
# As you may know, a computer screen has many very small points on it, each of them called "pixels".
# A computer can only draw on the screen by changing the color of a pixel.
# When drawing to the screen in 2D, you have to decide how many pixels you want for your screen or window.
# How many pixels a screen has is the "resolution" of that screen.
# A high resolution allows you to draw very finely, because the pixels are "smaller", but it is slower.
# For a modern computer 640x480 pixels should get very nice speeds without being too coarse.
yellow = screen.map_rgb(255,255,0)
red       = screen.map_rgb(255, 0,0)
# Create some colors from their RGB values. You're pixel artists, so you should know RGB already. ^_^
# Why do we need to make colours like this? Because the way the screen uses colours is different,
# and may be different for different people and different screens.
# from how humans use them. you need to "map" the rgb value to something the screen will understand.
screen.fill_rect(10, 20, 110, 120, yellow )
# Now, we draw a filled rectangle on the screen, using the yellow color
# What's are the numbers before the color? Well, the first two are the x and y coordinates of the
# rectangle that is drawn. A coordinate is a way to describe the position of a pixel or
# another object on the screen using numbers. The pixel in the top left corner of our screen has
# the coordinates x = 0 and y = 0. The pixel on the bottom left is at x = 0 and y = 479 (that is 480 - 1).
# The pixel on the top right is at x = 639 and y = 0.  The pixel on the bottom right is at x = 639 and y = 479.
# This all assuming our screen is 640 by 480. As you can see. x increases from left to right,
# and y increases from top to bottom.
# What are the next tow numbers? Well, they are simply the width and height of the rectangle in pixels.
screen.fill_rect(50, 50, 150, 150, red)
# And now draw a red rectangle. 
screen.fill_rect(-10, -10, 50, 50, red)
# Can you guess what this will do? If you youse negative coordinates, the rectangle will be partially outside the window.
screen.flip
# Finally, show on the screen what we have been drawing.
# Any changes to the screen will not be shown until you "flip" the screen, that is , display the changes.
# This is so because, it would be very slow to always change the screen for every time we are drawing.
# Like this, you can do all your drawing first, and then show the result when you are finished.
sleep(10)
# Finally wait 10 seconds, so we have the time to see what was drawn, because after this the program will end
# and the screen will be closed automatically.

There you have it! the first rectangles are on the screen. You can already start making Atari 2600-style drawings
on the screen using rectangles. ^_^ In the next installment, at how to handle keyboard input

(Edit: Used code tags for for Ruby program. Scroll down to read it at your own pace.)

[Atnas]

Ah lovely computers. I managed to install rubygame with a simple 'gem install rubygame' command, but upon trying it with rubysdl I get:

Code: [Select]

Building native extensions.  This could take a while...
ERROR:  Error installing rubysdl:
        ERROR: Failed to build gem native extension.

c:/ruby/bin/ruby.exe extconf.rb install rubysdl
checking for main() in SDL.lib... no
checking for SMPEG_new() in smpeg.lib... no
checking for Mix_OpenAudio() in SDL_mixer.lib... no
checking for sge_Line() in SGE.lib... no
checking for IMG_Load() in SDL_image.lib... no
checking for TTF_Init() in SDL_ttf.lib... no
checking for TTF_OpenFontIndex()... no
checking for TTF_FontFaces()... no
checking for TTF_FontFaceIsFixedWidth()... no
checking for TTF_FontFaceFamilyName()... no
checking for TTF_FontFaceStyleName()... no
checking for Mix_LoadMUS_RW()... no
checking for SDLSKK_Context_new() in SDLSKK.lib... no
creating Makefile

nmake
'nmake' is not recognized as an internal or external command,
operable program or batch file.


Gem files will remain installed in c:/ruby/lib/ruby/gems/1.8/gems/rubysdl-2.0.1
for inspection.
Results logged to c:/ruby/lib/ruby/gems/1.8/gems/rubysdl-2.0.1/gem_make.out
lovely! So all that's stopping me is nmake... whatever that is. I looked it up, downloaded nmake, and tried to run it on the makefile. Nothing. 

I'm still following along with your tutorials though, even if sdl isn't working at the moment. I really appreciate what you're doing. I'll hop into some ruby IRC channel to see if I can get some help. 

[Beoran]

Atnas, if you want to install rubysdl like that, you need a C compiler (for the C programming language, probably visual C++ or MinGW comes together with nmake or make respectively), and the SDL, SDL_image, SDL_ttf, SDL_mixer and   libraries too, so that is the hard way. There are windows binaries on the Ruby SDL homepage, although you have to look for them a bit and install them in the right place.

Anwyay, for educational purposes, I'll show you how to do about the same with Rubygame as with Ruby SDL. Here goes:

Code: [Select]

require 'rubygems'
require 'rubygame'
# Load Rubygame in stead of SDL

screen = Rubygame::Screen.new([640, 480], 0, 0)
# With this, we open the screen in a 640 pixels wide by 480 pixels high.
yellow  = [255,255,0]
red       = [255, 0,0]
# Create some colors from their RGB values.
screen.fill(yellow, [10, 20, 120, 140] )
# Now, we draw a filled rectangle on the screen, using the yellow color
# What's are the numbers after the color? Well, the first two are the x and y coordinates of the
# top left corner of the rectangle that is drawn. And the second two are the x and y coordinates
# of that same rectangle
screen.fill(red, [50, 50, 200, 200])
# And now draw a red rectangle. 
screen.fill(red, [-10, -10, 40, 40])
# Again, if you use negative coordinates, the rectangle will be partially outside the window.
screen.flip
# Finally, show on the screen what we have been drawing. Also in Rubygame we need Screeen.flip
sleep(10)
# Finally wait 10 seconds, so we have the time to see what was drawn, because after this the program will end
# and the screen will be closed automatically.

Most of this should look familiar. But wait, what' up with the stuff between square brackets?
Well, they are something called "Array"s. Now, what's an array? Well, it's basically an ordered list that contains other
objects like strings, numbers, etc, inside itself. You can get those individual objects ot of the array again by asking fro thm by their position in the array, which is a number. Here are some examples to make it more clear.

Code: [Select]

a = [10, 20, 30]
# Make an array that contains the numbers 10, 20 and 30
b = a[1]
puts b
# This will get the second number that is in the array namely 20, and print it.
# now you may say, "WTF!" why do we have to say 1 when we want to get the /second/ nuumber? Why isn't it 2?
# Well, this is because in many programming languages, when you use an array, you have to substract 1 from the
# position of the obect you want. So, this is a bit of a "programmer's tradition" that we have to get used to.
# So the first number inside a, you will get like this: a[0], the second one is a[1]
# and the third one is a[2] .
puts a[0]
# See, this is 10
puts a[2]
#
puts a.length
# You can see how many objects are inside the array like this
sa = [ "I", "like", "to", "program"] 
# You can also put strings inside an array
puts sa[3]
# And get a string out of the array again.
aa = [a, sa]
# You can even put arrays inside of arrays
puts aa[1][2]
# An get the third string out of the second array again
ma = [ a, 1 , 3 ]
# In Ruby you are allowed to mix all kinds of things together in an array.

Rubygame likes to use arrays for many things, for colors, for rectangles, and for the x and y position of a point.
This may seem complicated, but it also has some advantages.

Anyway, that's it for this episode, I really have to talk more amout input now, but that's for later. Hope you enjoyed this one.

[Ai]

Speaking as both a hobbyist and a professional, I have 3 pieces of advice.

Before you do anything else I would write a design doc and lock down every feature, enemy, weapon, character, level, etc. that you want in the game. If you start a project and just keep adding stuff until it's "done" it will never be finished, you may never even get past the first level! Of course you can make changes as you see the need but the Design Doc will keep you focused and on a steady course.

Set deadlines. Even if they don't mean anything. And don't use vague deadlines like "before the end of the year" or "mid-summer". Make them concrete: November 12th. February 6th, etc. If deadlines weren't used by professionals we would never finish anything.

Finally, ambition is good but it must be kept focused. If you have many ideas, make many games. Find a "hook" for your project - one or two things that make it fun to play over and over - and focus on those. The more precision you use, the harder it is to miss your target. Observe that the best games don't attempt to do everything, but rather succeed in doing a few things very very well, in a way that's fun over and over again. Portal is a prime example of this philosophy. On the other hand games like Daiketana or Advent Rising are horror stories about games that tried to do everything and succeeded at nothing. Always keep in mind that If you can save those unused ideas for your next game!

Hope this helps!

Thank you for making this post Ben, it helped me considerably.

[Beoran]

In this next installment, let's see how to handle keyboard input!
We'll draw a littbe yellow square and make it move to the left or
right if the player presses the left or right arrow keys.
Let's dive right in!

Code: [Select]

require 'rubygems'
require 'sdl'
# Load the libraries we need.

screen = SDL::Screen.open(640, 480, 0, 0)
# Open the screen, like usually.

yellow = screen.map_rgb(255,255,0)
green  = screen.map_rgb(0  ,255,0)
cyan   = screen.map_rgb(0, 255, 255)
# Make come colors

grass_h  = 40
player_w = 40
player_h = 40
player_v = 0
player_x = screen.w  / 2
player_y = screen.h - player_h - grass_h

done     = false
# It ain't overr 'till it's over.

while not done
# Keep doing the next lines while done is not true
  input = SDL::Event.poll
  # We ask SDL to get the input event that is occuring
  intype= input.class
  # Intype now contains what class, that is what kind of input we got
  if intype == SDL::Event::Quit
    # Clicked the close window icon.
    done = true
    # Now, it's over.
  elsif intype == SDL::Event::KeyDown
    # Someone pressed a key.
    key = input.sym
    # We get 'te "sum", that is the key sumbol for this input
    if key == SDL::Key::ESCAPE
      # If someone presses the escape key, we're also done.
      done = true
    elsif key == SDL::Key::LEFT
      player_v = -1
      # Pressing left arrow key, so the player should move to the left
      # For that, we make the speed of the player negative
    elsif key == SDL::Key::RIGHT
      player_v = 1
      # Pressing right arrow key, so the player should move to the right
      # For that, we make the speed of the player positive
    end 
  elsif intype == SDL::Event::KeyUp
    # A key was released
    key = input.sym
    # Get what key was released
    if key == SDL::Key::LEFT
      # If the left key was released, the player should stop moving.
      player_v = 0
    elsif key == SDL::Key::RIGHT
      # If the right key was released, the player should also stop moving.
      player_v = 0
    end
  end 
 
  player_x = player_x + player_v
  # Update the player's position based upon the player's speed.
  screen.fill_rect(0, 0, screen.w, screen.h, cyan)
  # Draw the sky on the background.
  screen.fill_rect(0, screen.h - grass_h, screen.w, screen.h, green)
  # Draw the grassy floor
  screen.fill_rect(player_x, player_y, player_w, player_h, yellow)
  # Draw the player as a square
  screen.flip
  # And display the screen.

end
# End of the while "loop". Everything from while to this end
# will be repeated until the variable done becomes true


You will probably notice there are quite a few new things in there.
The first thing is the use of "false" an "true". False and true are special values that indicate if something
is, well, false or true. Such values are called boolean values. The second new thing is the use of "=="
With "==" you can check if two values are the same or not, like in this example:

Code: [Select]

a = 2
puts a == 2 # Writes out true
puts a == 3 # Writes out false

Then there is the use of a whole lot of if, elsif, end  stuff. What's that for? Well, it allows you to do different
things depending on the value inside a varable.

Code: [Select]

a = 2
if a == 2
  puts  "a is equal to 2"
else
  puts  "a is not equal to 2"
end
This code writes out "a is equal to 2" What will happen if you say a = 3 at the top in stead of a = 2? Right, it will write out "a is not equal to 2" . So you can see that with if, you can make your program do different things depending on what's going on.
If the player presses the left key, something else should happen then when she presses the right key,
so you'll need an "if" to deal with that. You can put "if" inside other ifs, as long as you take care of putting the "end" in the right place,
otherwise you might get an error from ruby. To make putting several ifs into each other simpler, you can use elsif in some cases like this:

Code: [Select]

a = 3
if a == 2
  puts  "a is equal to 2"
elsif a == 3
  puts  "a is equal to 3"
else
  puts  "a is not equal to 2"
end

Finally, something new here is the "when" part. "When" is used for making a "loop" in the program, that is, for doing the same thing over and over again while a certain condition is true.

Code: [Select]

when not done
# All this between here will be repeated until done becomes true.
end

Well, that should cover it for today. I may be going a bit fast, so don't hesitate to ask if anything is unclear.

[Atnas]

Oh wow, thanks for that. You explained it perfectly.

[Beoran]

Today, we're going to learn how to improve the structure of our game a bit. You might wonder what's wrong with the structure of the previous program? Well, it's a bit messy really. Especially in side th while loop, many things are going on, and if we are going to make our game better, we'll have to add much more stuff in there, so it will become even more messy. It would be a lot nicer if we could group together certain logically related parts of what is going on in that loop.

How will we do this? Well, do you remember what I wrote about modules and functions or methods before? For example, if you say "puts a" then Ruby will look up in it's libraries what puts means, and then do whatever that is. Puts is an example of a function. But that's not all there is to functions! Actually, we can define our own functions. Like in this example:

Code: [Select]

# DEFine a fuction that simply writes "Hi there!" to the screen.
def hi
  puts "Hi there!"
end

hi # Now it will write Hi There! on the screen. You could also say hi() in Ruby

This is of course a very simple example. You might wonder what the point is of using a function when you can just write the command s immediately. But, the function above is very short. One what you want to do becomes longer, it makes a lot of sense to split up what you want to do over different functions, so your program has a nice structure. Also, you can use functions to do complicates calculations, and then get out the results of that calculations many times later on in one go. For example:

Code: [Select]

# A function that calulates the sum and the absolute difference between two numbers
def sumdiff(a, b)
  sum = a + b
  # Calculate sum
  diff   = (a - b).abs
  # Calculate difference
  return sum, diff
  # Return determines the result of the function. This function returns two values, sum and absolute difference.
end
 
s, d = sumdiff(10, 20)
# Calculate the sum and absolute difference of 10 and 20
puts "The sum is "
puts s
puts "The absolute difference is "
puts d

Sumdiff is an example of a function that "returns" with two results. That is, it calculates to values, based upon what you put inside it. The numbers, strings, or other objects you put inside a function are also called the arguments of that function. All this jargon comes from math, so, by now you should know that as a programmer you should pay (or have paid) attention in math class.

So, now we know the basics, let's try to improve our program by using function. The result is below:

Code: [Select]

require 'rubygems'
require 'sdl'
# Load the libraries we need.

# Define a function to handle the input
def handle_input(input, player_v, done)
  intype= input.class
  # Intype now contains what class, that is what kind of input we got
  if intype == SDL::Event::Quit
    # Clicked the close window icon.
    done = true
    # Now, it's over.
  elsif intype == SDL::Event::KeyDown
    # Someone pressed a key.
    key = input.sym
    # We get 'te "sum", that is the key sumbol for this input
    if key == SDL::Key::ESCAPE
      # If someone presses the escape key, we're also done.
      done = true
    elsif key == SDL::Key::LEFT
      player_v = -1
      # Pressing left arrow key, so the player should move to the left
      # For that, we make the speed of the player negative
    elsif key == SDL::Key::RIGHT
      player_v = 1
      # Pressing right arrow key, so the player should move to the right
      # For that, we make the speed of the player positive
    end 
  elsif intype == SDL::Event::KeyUp
    # A key was released
    key = input.sym
    # Get what key was released
    if key == SDL::Key::LEFT
      # If the left key was released, the player should stop moving.
      player_v = 0
    elsif key == SDL::Key::RIGHT
      # If the right key was released, the player should also stop moving.
      player_v = 0
    end
  end 
  return player_v, done
  # The result of this function will be the speed of the player and
  # whether or not the game is done.
end 


# A function to calculate the new player position
def update_player(player_x, player_v)
  new_player_x  = player_x + player_v
  return new_player_x + player_v
  # return the new position of the player
end

# A procedure to draw the screen
def draw_screen(screen, player_x, player_y, player_w, player_h,
                grass_h, cyan, green, yellow)
  screen.fill_rect(0, 0, screen.w, screen.h, cyan)
  # Draw the sky on the background.
  screen.fill_rect(0, screen.h - grass_h, screen.w, screen.h, green)
  # Draw the grassy floor
  screen.fill_rect(player_x, player_y, player_w, player_h, yellow)
  # Draw the player as a square
  screen.flip
  # And display the screen.
end


screen = SDL::Screen.open(640, 480, 0, 0)
# Open the screen, like usually.

yellow = screen.map_rgb(255,255,0)
green  = screen.map_rgb(0  ,255,0)
cyan   = screen.map_rgb(0, 255, 255)
# Make come colors

grass_h  = 40
player_w = 40
player_h = 40
player_v = 0
player_x = screen.w  / 2
player_y = screen.h - player_h - grass_h

done     = false
# It ain't overr 'till it's over.

while not done
# Keep doing the next lines while done is not true
  input          = SDL::Event.poll
  # We ask SDL to get the input event that is occuring
  player_v, done = handle_input(input, player_v, done)
  # Process the input in our own function
  player_x       = update_player(player_x, player_v)
  # Update the player's position based upon the player's speed.
  draw_screen(screen, player_x, player_y, player_w, player_h,
              grass_h, cyan, green, yellow)
  # Display the screen.
end
# End of the while "loop". Everything from while to this end
# will be reprated until the variable done becomes true

Now, one thing you may wonder about is, why do we have to pass so many arguments, for example, to the
draw_screen function? Well , you see, functions create their own little "world", in which only the arguments that
come in to the function, and the variables that you use inside the function are known. The effect that variables
that are used in one part of the program can be hidden from another part of the program is called "scope." Look at this example.

Code: [Select]

a = 10
def scope_example
a = 20
puts a
end

puts a # writes out 10
scope_example()
# will write out 20, not 10, because scope_example uses it's own version of A, not the one outside of it

Why is this useful? Well, it allows you to split up your program in parts that can't mess up each other's variables. That's very useful to allow you to keep your program orderly, and to prevent different parts from the program to interact with each others in ways which you don't want them to do!

So there, that's my installment on how you can make functions yourself. There is more we can do to improve the structure of the program, though, and that I will explain in my next installment! See you then! And remember all questions are welcome.

[Emtch]

So does anyone know any good sites with tips and tricks on ruby? I've searched and didn't really find anything relevant

[Beoran]

First of all, Sorry to stall my tutorial, I wasted a week on getting the collision detection right. But I have it now, I just need to comment it and post it here if I can get off my lazy butt. :p

As for tips on ruby, there are plenty of sites; just like this one:
http://www.rubytips.org/
Found like this:
http://www.google.com/search?q=ruby+programming+tips

[Emtch]

Now I've gotta reinstall ruby, because something is wrong with sdl (can't load it anymore) and the help files don't work. Really weird because I downloaded it from the official site.

As for tips on ruby, there are plenty of sites; just like this one:
http://www.rubytips.org/
Found like this:
http://www.google.com/search?q=ruby+programming+tips

OMG WHAT IS GOOGLE? I know how to google, thank you.

[Atnas]

Hey Boeran! Thanks to you, I was able to make a minimally functional linear text adventure for my latin class over the period of a few hours! (loops gave me trouble)

Code: [Select]

#----Define Variables--------
health = 5
maxhealth = 5
strength = 1
#Start
while health > 0
puts "Latin text adventure (press enter to continue)\n"
gets
puts "You climb into the dungeon.\n"
gets
#1
print 'It is dark. Light your torch? (1=yes 2=noo) >'
ask = gets.to_i
#1,1
if ask == 1
print "\nYou can see the passage continues, but you can not see the end.\n"
gets
break
#1,2
elsif ask == 2
puts "you were eaten by a grue"
gets
end
end
#End of first phase, Start of Second
while health > 0
print 'Will you go forward? (1=y 2=n) >'
ask = gets.to_i
if ask == 1
puts "\nYou find yourself face to face with a sphinx.\n\nHe will eat you if you do not answer him correctly.\n"
gets
puts "rawr rawr I am a sphinx what is the object of the preposition in this sentence?\n"
gets
print "Titi ex Roma\n\n"
gets
print '"Is it (1)Titi or (2), Roma?" >'
ask = gets.to_i
if ask == 1
print "You attack the sphinx for #{strength} damage."
gets
print 'He mews miserably as his entrails leak from his shuddering carcass.'
gets
print 'You gained a level! your strength increases by 1!'
strength = strength + 1
puts "\n\n Current Strength: #{strength}"
gets
elsif ask == 2
puts "no you idiot"
gets
puts "Sphinx attacks you for 1 damage, knocking you back in the process!\n"
puts "You land with a thud!!!"
gets
health = health - 1
puts "Health #{health}/#{maxhealth}"
gets
end
end
#end of second phase, start of third
while health > 0
puts "The passage continues. You reach another sphinx\n\n"
gets
print "What are the genetive case feminine endings?\n\n"
puts "1) ae, arum\n"
puts "2) am, as\n\n"
ask = gets.to_i
if ask == 1
print "You attack the sphinx for #{strength} damage."
gets
print 'He mews miserably as his entrails leak from his shuddering carcass.'
gets
print 'You gained a level! your strength increases by 1!'
strength = strength + 1
puts "\n\n Current Strength: #{strength}"
gets
break
elsif ask == 2
puts "no you idiot"
gets
puts "Sphinx attacks you for 2 damage!\n"
gets
puts "You are in pain!!!"
gets
health = health - 2
puts "Health #{health}/#{maxhealth}"
gets
end
end
#end of third start of fourth
while health > 0
puts "The passage continues. You come across yet another sphinx\n\n"
gets
print "What makes a verb passive voice?\n\n"
puts "1) When the subject performs the action of the verb."
puts "2) when the subject recieves the action of the verb\n\n"
ask = gets.to_i
if ask == 1
puts "no you idiot"
gets
puts "Sphinx attacks you for 2 damage!\n"
gets
puts "You are in pain!!!"
gets
health = health - 3
puts "Health #{health}/#{maxhealth}"
gets
elsif ask == 2
print "You attack the sphinx for #{strength} damage."
gets
print 'He mews miserably as his entrails leak from his shuddering carcass.'
gets
print 'You gained a level! your strength increases by 1!'
strength = strength + 1
puts "\n\n Current Strength: #{strength}"
gets
break
end
end
while health > 0
puts "You won yay."
gets
Process.exit
end
end
I think I need else statements because it screws up when you don't hit one or two on a question.

And compiled: www.lolipopsicle.com/latin/latin.exe

[Beoran]

Atnas, I think you could also clean it up considerably by using several procedures/functions. But today I'm too lazy to fix up yours, so sorry for that. :p

[Beoran]

Well, finally, here it is, the next installment with the beginning of Classes.

Code: [Select]

require 'rubygems'
require 'sdl'
# Load the libraries we need.

# We make a new type of object, or a class, that will be used to
# group all information about the player together
class Player
  attr_accessor :x # the player has an x position
  attr_accessor :y # the player has a y position
  attr_accessor :w # the player has a width
  attr_accessor :h # the player has a height 
  attr_accessor :vx # the player has a horizontal speed
  attr_accessor :vy # the player has a vertical speed
  attr_accessor :color # the player has a color
end

# We make a new type of object, or a class, that will be used to
# group all information about the game together
class Game
  attr_accessor :screen # the game has a screen
  attr_accessor :done   # The game is done or not done.
  attr_accessor :color  # the game has a background color 
end


# We make a new type of object, or a class, that will be used to
# group all information about the grass together
class Grass
  attr_accessor :x # the grass has an x position
  attr_accessor :y # the grass has a y position
  attr_accessor :w # the grass has a width
  attr_accessor :h # the grass has a height
  attr_accessor :color # the grass has a color
end

# Define a function to handle the input
def handle_input(input, player, game)
  intype= input.class
  # Intype now contains what class, that is what kind of input we got
  if intype == SDL::Event::Quit
    # Clicked the close window icon.
    game.done = true
    # Now, it's over.
  elsif intype == SDL::Event::KeyDown
    # Someone pressed a key.
    key = input.sym
    # We get 'te "sum", that is the key sumbol for this input
    if key == SDL::Key::ESCAPE
      # If someone presses the escape key, we're also done.
      game.done = true
    elsif key == SDL::Key::LEFT
      player.vx = -1
      # Pressing left arrow key, so the player should move to the left
      # For that, we make the speed of the player negative
    elsif key == SDL::Key::RIGHT
      player.vx = 1
      # Pressing right arrow key, so the player should move to the right
      # For that, we make the speed of the player positive
    end 
  elsif intype == SDL::Event::KeyUp
    # A key was released
    key = input.sym
    # Get what key was released
    if key == SDL::Key::LEFT
      # If the left key was released, the player should stop moving.
      player.vx = 0
    elsif key == SDL::Key::RIGHT
      # If the right key was released, the player should also stop moving.
      player.vx = 0
    end
  end 
  # Here, we don't need a result. 
end 


# A function to calculate the new player position
def update_player(player)
  player.x = player.x + player.vx
  # Set the new position of the player based upon the
  # speed of the player
end

# A procedure to draw the screen
def draw_screen(game, player, grass)
  screen = game.screen
  # Store the game screen temporarily in a variable for ease of use. 
  screen.fill_rect(0, 0, screen.w, screen.h, game.color)
  # Draw the sky on the background.
  screen.fill_rect(grass.x, grass.y, grass.w, grass.h, grass.color)
  # Draw the grassy floor
  screen.fill_rect(player.x, player.y, player.w, player.h, player.color)
  # Draw the player as a square
  screen.flip
  # And display the screen.
end


game    = Game.new
player  = Player.new
grass   = Grass.new

game.screen = SDL::Screen.open(640, 480, 0, 0)
# Open the screen, like usually, and store it in the game.
game.done   = false
# The game is not done.
game.color  = game.screen.map_rgb(0, 255, 255)
# Set the game's background color.

grass.h     = 40
grass.w     = game.screen.w
grass.x     = 0
grass.y     = game.screen.h - grass.h
grass.color = game.screen.map_rgb(0  ,255,0)
# Set the grass's attributes.

player.w      = 40
player.h      = 40
player.vx     = 0
player.x      = game.screen.w  / 2
player.y      = game.screen.h - player.h - grass.h
player.color  = game.screen.map_rgb(255,255,0)
# Set up the player's attributes.

while not game.done
# Keep doing the next lines while done is not true
  input          = SDL::Event.poll
  # We ask SDL to get the input event that is occuring
  handle_input(input, player, game)
  # Process the input in our own function
  update_player(player)
  # Update the player's position based upon the player's speed.
  draw_screen(game, player, grass)
  # Display the screen.
end
# End of the while "loop". Everything from while to this end
# will be reprated until the variable done becomes true

What is new about this? Well, remember that in the previous tutorial we had a lot of parameters that were passed from one function to another. To help with that, we make use of objects and classes to group all related data together. What's an object? Well, its a piece of data that contains different elements grouped together, and which you can access by name.  What is a class? Well, you can understand a class as being like a cookie cutter, or a template, which you can use to determine what the layout of an object created from that class will be.

So, that's why we first describe the class Player as having certain attributes. Attributes of a class or object are properties of that object in which you can store data. Basically, in ruby, there are two kinds of attributes, namely accessors, and readers. With an accessor, you can look up the data inside an object, and also change it. In Ruby, you define an acessor using attr_accessor.  With a reader, you can only look up the data and not change it. In Ruby, toy define a reader using attr_reader. So, by saying attr_accessor :color inside the Player class, we say that a player will have a color that can be changed at will.

Now, to create an object from a class, we simply use the new method of that class. Like that, a class is also acting a bit like a special kind of module. By saying player = Player.new, we create a new object that has all the attributes that we described in the class Player. Thats' why we can do things like player.vx = 0 , we are setting the x direction speed attribute of the player to zero.  Like that, th player object contains all data about the player grouped together neatly. This is a big advantage over using loose variables, since in any big program, you'll have many different variables, and it becomes quite messy when you have to keep track of them individually. With classes and objects, you can group related variables together in a neat package, keeping things more structured and  neat.

[Beoran]

Hey Atnas, here is an improved version of your program, it uses objects and functions. I hope it's not too difficult for you , but if it is, please tell me and I'll explain whatever part you don't understand. As you should understand, now, you can add easily more phases to the game.

Code: [Select]

#
# Improved version Latin game, using classes and object too. 
#

class Player
  attr_accessor :health
  attr_accessor :maxhealth
  attr_accessor :level
  attr_accessor :strength
end 

class Phase
  attr_accessor :text
  attr_accessor :question
  attr_accessor :first
  attr_accessor :second
  attr_accessor :correct
  attr_accessor :correcttext
  attr_accessor :levelup
  attr_accessor :damage
  attr_accessor :damagetext
end

def choice(question,first, second) 
  puts question
  # show question and ask one time.
  puts first + " (1), " + second + " (2)." 
  line    = gets
  answer  = line.to_i
  # keep asking if it's not 1 or 2
  while answer !=  1 and answer != 2
    puts "Please type 1 or 2 only, followed by an enter."
    puts first + " (1), " + second + " (2)." 
    line    = gets
    answer  = line.to_i
  end
  return answer
end

# Damage the player if he gives a wrong answer
def player_damage(player, damage, message) 
  puts message
  player.health -= damage
  if damage > 0
    puts "You suffered #{damage} points of damage."
    puts "Curent health: #{player.health} / #{player.maxhealth} ."
  end
  if player .health < 0
    puts "Oh my, looks like you didn't survive that one!"
    return false
  end
    return true
end

# Level up the player if he gives a right answer
def player_levelup(player)
  puts 'You gained a level! Your strength increases by 1!'
  player.strength += 1
  puts "Current Strength: #{player.strength}"
end

# Play one phase
def phase_play(phase, player)
  while (player.health > 0)
    puts phase.text
    answer    =   choice(phase.question, phase.first, phase.second)
    if answer ==  phase.correct   
      puts phase.correcttext     
      # Show text for correct answer
      # Correct answer, level up player if wwe have to
      if phase.levelup 
        player_levelup(player)
      end 
      return true
    end
    player_damage(player, phase.damage, phase.damagetext)
  end 
  return false
end

# Plays all phases
def phase_playall(player, phases)
  for phase in phases do
    alive = phase_play(phase, player)
    if not alive
      return false
    end
  end   
  return true
end

# Initialize player object
player            = Player.new
player.health     = 5
player.maxhealth  = 5
player.strength   = 1
# Initialize game object


phase1             = Phase.new
phase1.text        = "You climb into the dungeon."
phase1.question    = "It is dark. Light your torch?"
phase1.first       = 'Yes'
phase1.second      = 'No'
phase1.correct     = 1
phase1.correcttext = "You can see the passage continues, but you cannot see the end."
phase1.damagetext  = "You are attacked by hungy a grue!"
phase1.damage      = 5
phase1.levelup     = false


phase2             = Phase.new
phase2.text        = ""
phase2.question    = "Will you go forward?"
phase2.first       = 'Yes'
phase2.second      = 'No'
phase2.correct     = 1
phase2.correcttext = "You find yourself face to face with a sphinx.\nHe will eat you if you do not answer him correctly."
phase2.damagetext  = "What, you want to keep standing here forever?"
phase2.damage      = 0
phase2.levelup     = false

phase3             = Phase.new
phase3.text        = "Rawr, rawr! I am a sphinx!"
phase3.question    = "What is the object of the preposition in this sentence?\nTiti ex Roma.\n"
phase3.first       = 'Titi'
phase3.second      = 'Roma'
phase3.correct     = 1
phase3.correcttext = "You attack the sphinx! \n He mews miserably as his entrails leak from his shuddering carcass."
phase3.damagetext  = "No, you idiot! Sphinx attacks you, knocking you back in the process!\nYou land with a thud!!!"
phase3.damage      = 2
phase3.levelup     = true



phase4             = Phase.new
phase4.text        = "The passage continues. You reach another sphinx.\n"
phase4.question    = "What are the genetive case feminine endings?\n"
phase4.first       = "am, as"
phase4.second      = "ae, arum"
phase4.correct     = 2
phase4.correcttext = "You attack the sphinx! \n He mews miserably as his entrails leak from his shuddering carcass."
phase4.damagetext  = "No, you idiot! Sphinx attacks you, knocking you back in the process!\nYou land with a thud!!!"
phase4.damage      = 2
phase4.levelup     = true


puts "Latin text adventure (press enter to continue)\n"
gets

phases = [ phase1, phase2, phase3, phase4 ]

won = phase_playall(player, phases)
if won
  puts "Congratulations, you won the game!"
else
  puts "Game Over!"
end


[Atnas]

Woah, thanks man. I'm going to study this.

[Froli]

Sorry for the off topic but, is there anyone here who is both a programmer and a good pixel/graphic artist? Having both skills at your whim is pretty awesome.

[PypeBros]

Sorry for the off topic but, is there anyone here who is both a programmer and a good pixel/graphic artist? Having both skills at your whim is pretty awesome.

i do both. I let you judge whether i'm a good pixel artist.
And well, somehow, it may be awesome, but it means you've got heavier work on any project you're stepping in