The Rubygame Book Part 1

From Kibabase

Home	Beginning	Back	Next	End
Back to Table of Content	Jump to Beginning	Back	Next	Jump to End(Part 7)

Rationale:

Before we dive into writing your first game project, we must first consider the logical organization of our project. The correct schema for the organization of the code will make it easier to write code now and in the future. An incorrect schema will make life infintely harder as the code spawn from hundred of lines to thousands, and then further beyond that.

Organization of the Game Directory

In a typical rubygame application, you could typically divide the game code into three parts: logics, events management, and draw code. This give us three directories in the one directory called app: logic, event, and draw.

Inevitablely, you will probably find yourself writing miscellenous code that will be useful to future game projects and as well past projects that you created. This give us another directory, lib. We will also use this directory to put already baked code so that we can focus on the game details rather than unneccesary code plumbing.

Sometime, you will create some sort of scripts that take care of busywork like generating scaffold code from template. It is neccesary to have a script directory.

Most likely, your game will evolve some sort of configuration system. For that, you will need the config directory.

You will defintely need a data directory to store all you media in, so create a data directory.

Since we're creating a game called RbPong. Create the RbPong directory with all the directories that I told you to create for your game project.

A test directory is needed for the unit tests you are going to write.

So in short, your directory should look like this.

1. RbPong

• app
  • logic
  • event
  • draw
• lib
• config
• data
• script
• test

Code

If the code is not modular, it will have many adverse effect on the future of the project. First, it would be incredibly difficult and time consuming to write unit tests in any kind of combination as classes grow in their requirement for elaborate setup. Eventually it would be humanely impossible to write unit tests. Secondly, the classes and methods in question will grow many side effects and miscellaneous functions. Such complexity will overwhelm the programmer and results in many hard to track bugs. Thirdly, it will be difficult to add any kind of new code. Hence, the partitioning of the app directory in accordance to logic, event, and draw code.

So why is code divided into three sections? As I said, in any given rubygame application, there will be code to manage logic flow, the logical operation itself, and the resulting drawing operation that reflect the state of the game. These are the three self-evident basic operation of a game that was gathered from years of writing games. They will serve as a guideline on how to write one's game.

In more formal term, the three basic operations is what they called model-view-controller pattern in software engineering.

The implication of the three type of operations:

1. All logical operations do not care about the sequential flow of the game.
2. All drawing operations do not care about the accurate representation of the game state.
3. Thus, it requires the existence of a communication and logical flow layer called events management.

Conclusion

Now that we are now acquainted with a basic theory on how to organize a game's codebase and structure, our next step begins with populating the directory with overarching systematic code.

In the next part of the tutorial, which is part 2 of the tutorial, we will discussing the loading of code, which is required to tie codes together from distinct files into a single integrated program.