Last Week was Very Busy

I didn't get the chance to code for a long time because the last week has been so busy...

Today, I got the chance to work on RubyTet. Currently, I am working on rewriting the way the game handle the data of blocks and indexes. I am integrating together. As a result, my game over code stop working. However, I don't know where is the location that determine the end game. So there are some voodoo code that I don't know about.

I hope to get some block destruction by the end of the week and I vow to work even more. I got 19 commits today so that's a good start. Moreover, I will be increasing my minimum commit rate to 15.

It is already November...If I don't finish my rubytet project soon then I am not ready to start ransoming my work in December. So I am going to self impose myself a deadline to be finished by this weekend. Here are the goal for version 0.0.1:

1. It will have ever increasing difficulty in term of speed

2. Score points properly. Bonus for straight drop.

3. Block destructions.

4. Polished opening screen.

That's all I can think of right now.

Scoring System Almost in Place

I, being a rather lazy programmer, only made 13 commits in writing RubyTet. However, it is a somewhat productive day in term of progress. I finish most of the scoring system code. The only two things left is to make it easier for players to score the game is by finishing the shape changing code and to write block crushers.

Not Much Today

I spent little time developing RubyTet today. I merely setup the classes for scoring and the UI for displaying the game score. I did get 16 commits though.

Tomorrow, I will probably do a more..rigorous development of RubyTet.

Also, I am probably going to toy with coding other sort of games...nonseriously... So any new projects that I might have started tommorow is likely to be forgotten...

A Big Puzzle of RubyTet is Solved!

Well, my solution to RubyTet's game logic problem has worked. Once again, simple solution often trump complicated answers in their correctness. So much that I have to get rid of my old solution, which were more specific and more wrong.

The above screenshot is not representative of the current situation but it is quite close to it.

I made roughly 15 commits today in the span of an hour of programming. I think that's enough for today.

By the way, thanks for the vote on the FSDaily story for the Libregamewiki article Battle for Wesnoth. I appreciated it! More votes is welcomed!

Hmm....Failure Again

Yesterday was supposed to be the 7th day of non-start stop development. It didn't happen because I was too interested in discussing ideas rather than writing games. This lapse is disappointing. But today, I resolved to program harder to make up for my failure.

I won't promise that it won't happen again but from this day forth, I hope to achevie the magical 30 days straight game development, a feat that I achieved during the summer.

In about one hour of programming today, I achieved 14 commits. In that time I laid the groundwork for a much simpler solution to the problem than I have devised with my overly complex dropping mechanism. I think...it is almost complete. I hope to finish this very core game logic by tomorrow...

As for the Libregamewiki project, I encouraged people to votes on the FSDaily story for our Wesnoth article. Making the front page again means more traffic to Libregamewiki, and hopefully contributor conversion.

Redux Day 7: Upping the Ante

Since it is Monday, I decided to increase the number of minimum commits by one.

All in all, I finished a game feature which allow players to do instantaneous drop. Otherwise, it is mostly me mucking around cleaning up the rather ugly codebase. So nothing concrete except better code organization and a new gameplay feature.

I also got a solution that's worked out for the game logic. Let see if my other work on the codebase can delay me from working on the game logics until Friday. It is not like it will be ready for consumption once after I finish the core game logics. All I am doing is shifting tasks around that would otherwise be done anyway at the end of core feature development.

Redux Day 6: Game features coming along....

Instead of banging my head against the game logic diffculty of RubyTet, I decided to work on other game features instead. So I worked on limiting the movement of the shape by figuring how much to offset. Then I went to work on player activated complete drop, which meant that the player has decided to just drop the shape.

In course of implementing this feature, I discovered that I must again make new classes so it make the task of writing new features easier. Currently, the classes are incomplete. However, I hope this task will keep me occupied as I figured out a solution to my difficulty.

Redux Day 5: RubyTet Game Logic Trouble

So I managed to make 12 commits to the RubyTet project but I never managed to get much further along with the game logic. The new method I used to check if it is necessary to drop is broken. So tomorrow, I'll have to spend good quality time doing sketching on papers and figuring out the mathematics.

Along the way, I did a few preparation on changing the speed of the game and did some bugfixes that went unnoticed before.

Redux Day 4: More Cleanup on RubyTet

I finally finished cleaning a class of RubyTet. Now that its ugliness in that area got erased, I can focus on figuring out the game logics. I havn't made much progress in that department. My assumption are wrong in the first place and I'll have to go back to drawing board and figure out what information to return.

Libregamewiki, on the other hand recevie generous contribution from the author of SDL-Ball on our article SDL-Ball. We are grateful for that contribution. It also mean that SDL-Ball is one of our bigger article on Libregamewiki. Regardless, any contribution from others is awesome!

Redux Day 3: A Little Cleanup in RubyTet

Today, not much has been focused on dealing with game logic code and more about cleaning up the codebase a little bit so it is a little bit more organized and feel "cleaner". I managed to achevie my minimum goal of 12 commits plus more.

Tomorrow, I will have luxury of working out the game logics code for RubyTet. Currently, it knows when to stop moving the shape and start a new shape to drop, but it doesn't know where to stop moving. Hopefully, by the end of tommorow, I will have something almost resembling Tetris in that you fit pieces together.

For the Libregamewiki project, I am pleased to continue to see the increase in traffic. The construction project and the promotional effort has defintely paid off. However, we will need to promote the project more and continue the construction program before I can see that Libregamewiki take care itself without my day to day editing.

Broke RubyTet's Barrier! Yay!

Second day into my redux:

Well...I finally solved the bug in RubyTet. It requires lot of debugging for me to figure it out though. Tomorrow, I can proceed doing 12 commits to the project, I hope.

Libregamewiki received much traffic thanks to your vote on FSDaily! If you haven't vote for the OpenAnno article yet, please do so! If it can get to top story of the week, that mean a continued stream of traffic to Libregamewiki. I think it already attracted a contributor :D.

Meanwhile, I continued my study in trignometry, finishing a few problem today. They were easy so far. I just have to figure out how to convert them into square root or something...

Redux and Failure

This weekend, I have unexpectedly failed to reach my goal. It all started with my inability to overcome obstacle in programming RubyTet. The rest, I wasted time and refuse to do them at all. In any case, it was a disappointment.


Today, I have come back to coding RubyTet again, along at a reduced level of productivity, because of my inability to solve difficult bugs. Nonetheless, this day will marks the redux of my effort to strengthen and maintain discipline. So this is day 1, all over again.

Looking back, I think I was overly ambitious to pursue many things at the same time. So this time, I will scale back and just focus on doing my homework, coding, and editing the wiki. I will have to fit my trignometry study somewhere. I wouldn't like to wait a long time before I can restart my Space Fighter Ace project.

Also, for the libregamewiki project, I would like readers to vote up the FSDaily story on OpenAnno, a recently featured article and recipient of the construction project on libregamewiki.

Day 19: 3 Day Weekend Starting!

Ah, I gone off the track a bit with Friday here. Still managed to keep doing RubyTet stuff though. I read through the rails tutorial and the trignometry book and everything. Libregamewiki got a growth spurt going on. In short, everything may be progress more slowly than ancipitated but it is still going.

But today is when the long weekend starts! Monday is student holiday and the teachers will have to drag themsleves off to work. Good thing that I am a student.

Time to make plans!

Let me see if I can finish chapter 3 of my trignometry in one evening sometime this weekend. Also, I am going to finish part 5 of my rubygame book.

RubyTet will be going under hyperactive development mode. So expect lot of commits and lot of progress, barring unforseen obstacle.

I am going to try to finish the rails tutorial too so I can start building RubyTet's home and the beginning of a gaming framework integrating websites with video games.

If I make good use of my time, I should be able to get lot of these goals done. If not, than I only have myself to blame for squandering such a pecious opportunity. Here hope that it turn out wonderfully.

Good night all!

Day 18: Homework Thursday

Today, all at once, my teachers decided to give everybody lot of homework. So I got clogged with homework in my backlog. This limits my time and force me to spend time coding on other parts of RubyTet such as cleaning up the viewer class. In the rush, I made several careless mistakes and has to correct them later.

I should have made better uses of my time though. That way, I can think about solving the problem instead of the mad rush to do easier but less essential tasks. But tomorrow will be Friday and there will be an extended weekend too! So this school cruft will be over soon!

Beside homework, this day is business as usual. I am slowly progressing through everything...

Day 17: Adding controls to RubyTet

For RubyTet today, I wrote the game control so that you can move around shapes. I still have not implement the shape changer though. Then I worked on adding rules for adding shapes since it isn't enough to be adding shapes to the field, but actually inserting in the correct position.

As for my other stuff...

Rails: I am momentary confused about rails migration. Tomorrow will clear up as I start over again over the migration part of the tutorial.

Trigonometry: I am proceeding slowly through chapter 3. Still many questions to go.

Libregamewiki: It is business as usual. Not much is going on there.

Day 16: RubyTet game logics coming along....

Today, RubyTet development got 13 commits. During these commits, I renamed the Create class into the ShapeField class and wrote shape adder for the PlayField class. Then I went to work on the buggy viewer because it failed to update to the next shape. I also fixed the z and s shape because they were switched around.

As for my pursuit of trignometry and rails skills, I am heading into rather lengthy chapter it seem. There are like 80 questions that I have to do. Rails tutorial, I am doing like a page a day. It is really short and really easy so far.

Day 15: Week 2 into Development!

Ah! I reached a critical milestone. I done about 2 weeks of game development so far. I think I have established myself as a disciplined developer able to work under the stress of school and the energy that it drain.

Today, RubyTet got 12 commits, over the miniumum requirement of 11 commits per day. The 11 commits a day is not much increment over 10 commits, but I think it will add up to cutting the game development cycle by a few days. If successful, I will increase the minimum by 1 commits every week.

As for my Trignometry(which I am learning for Space Fighter Ace), I am crusing chapter 3 at a leasiurely pace. With the rails tutorial I am doing, I finally got the mysql server fixed and so I am now unstuck. For my Libregamewiki project, I worked on the OpenAnno article quite a bit. I also get valuable freedback from CyaNox regarding the state of the wiki. Also, he kindly upgraded the mediawiki installation of Libregamewiki.


Finally, I recongnize that I need to manage my schoolwork load more efficently since my grade has took a drop from my stay at the hospital. Maintaining my grades is neccessary for me to aim for my game development career without restriant. I am aiming for all A's, so it will be a tough challenge to tackle. So with this in mind, I established a mandate to study my Latin vocabluary words every day. Once I can deal with schoolworks with ease, I think this will open up more energy for me to work on developing video games for a living.

Day 14: RubyTet is starting to Resemble a Game!

RubyTet now have shapes dropping! It took us agonizing 14 days for this project to mature because I merely complete the minimum amount of commits needed everyday, which is 10. I think it will take the rest of this month for the first version to be completed. As a matter of fact, I am going to bump it up the minimum requirement a notch. It will be now 11 commits, instead of 10!

As for the rails tutorial I been doing, I got stuck with the mysql database. It apperantly doesn't like me because I got the password wrong.

As for Space Fighter Ace, I am taking my first step with chapter 3 of my trignometry book. It will take a while for me to digest this infromation over distracting schoolworks(especially my math class). I wish to return to coding soon but not knowing trignometry won't make it go any faster.

In Libregamewiki news, we got a new wikiproject going on, the construction project. We're aming to make OpenAnno a big fat article. Once that's done, I got plans to use the article to promote the Libregamewiki.

Since it is the weekend, I took the time to work on the Rubygame Book. I fleshed out the introduction of part 5 a little bit, but not much else.

Day 12 & 13: Slugging through the Weekend

Apparently, my post for Friday did not successfully materialize. All of the work I have done for that blog post disappeared. Oh well.

But for Saturday, I made a fair amount of progress on different tasks.

RubyTet: I got the shapes fixed and is working on the drop code.

Libregamewiki: I am working on coordinating the construction effort so that the Libregamewiki will see its most activity ever since the project started.

Space Fighter Ace: I finished chapter 2 of my trig book. I need to accelerate the learning process if I wanted to finish the game by Christmas.

Rubygame book: I worked on providing the neccessary images for learning how to use surfaces.

Rails tutorial: I am slowly working through the tutorial at the moment. I could probably finish the whole thing in one day if I wanted to though. That should be a bonus mission for this weekend.

Day 11: A Chapter Is Finished

I just finished chapter 1 of the trig book I am reading today. It took me a while because I was doing them between classes. Now, I am a little bit closer to having enough knowledge to complete my Space Fighter Ace project.

As for RubyTet, I got the viewer working. I just need to work out the kinks out.

I am also getting started on a rails tutorial. Once I complete that tutorial, I am going to go create a rails site for RubyTet. There, it will form the website framework for future games. My hope that it will evolve into a general framework for integrating games into sites.

Day 10: I Got Forked

To my surprise, my Space Fighter Ace project got forked. That mean it must be good enough for a project fork! I am excited to see what will happen. I am also learning my trig at a steady pace.

I also managed to get myself unstuck in the RubyTet project. It took me 3 try to find a solution.

As for the forum, I moved the Libregamewiki forum to the FGD network. Hopefully, it will attract new contributors to the wiki.

Day 9: Conquering New Ground

For the ninth day of development of RubyTet, I am stuck with something that I do not know how to fix. Nonetheless, I managed to do my 10 commits.

I also started reading chapter one of the trig book that I obtained. Turned out that it was in my book bag the whole time. Once I complete the book, I hope that I will be able to complete the physics of my Space Fighter Ace game.

I also picked out the website design layout for RubyTet. The color scheme has not been picked(it will be picked once I get there) and I did not yet choose the technology for the site. Will it be ruby on rails, or picked off from the shell(wordpress, mediawiki, etc)? I do not know.

One thing is for certain, I am progressing rather nicely. If it goes according to plan, I'll start asking for my first ransom in December.

Day 8: A New Week

I started off this week fixing mostly bugs in RubyTet and end up wasting my ten commits for it. I should have tested it a little bit more before committing things.

As for the Libregamewiki, I did my editing duty as usual, racking up more than ten edits and significant expansion in the Widelands article. I am also talking to Qubodup about becoming part of the Free Game Dev network. Given how much I benefit from Freegamer's generous linking, I think I ought to give back. Plus, Libregamewiki will have its own forum section at their forum, which I hope will attract contributors and revitalize the wiki. So the Libregamewiki section at my new forum will goes the way of the dodo bird. However, since the forum is really only intended for my personal gaming network, this make sense.

Among other things, I am looking into learning web application programmming and writing a gaming website for RubyTet so I can have 1)A job skill in case I don't make enough money writing free games and 2)develop my process for building games and making money off of it.

I also worked on the next part of my tutorial, which will hopefully be unveiled later this week.

Wow, that's a mouthful!

7th Day: Lazy Sunday Edition

So this is one week into nonstop game development! Yay!

Not much has goes on for Space Fighter Ace I am afraid. My selection of book is poor and over my head so I have to start all over again.

As for RubyTet, I am moving toward writing a previewer graphical element which allows player to know what is the next part going to be. Not only this is a gameplay element, it will help me tremdously with debugging the game. Since not only it will be displaying the shape that it is going to drop down but also the name of the shape.

On the Libregamewiki front, there is nothing much happening. Though AVRS, one of the Libregamewiki contributor agree with me that we need to resolve the licensing issue somehow.

6th Day: Lazy Saturday

Despite tremendous times on my hand, I have decided regrettably to do the bare minimum. As such, I just barely got started on learning my trigonometry for Space Fighter Ace.

As for my RubyTet, which now have a project page at the KibaBase, I just finished making all the shape classes.

For Libregamewiki, I updated the planet. I am not going to take it down even though Free Game Dev planet already exists. It provide me with profits, so I keep. Not much else goes on with Libregamewiki, except the usual editing activity. I am thinking of expanding the wiki to other language edition provided that we have at least one fluent and active volunteer.

5th Day: All System Back Online

Libregamewiki is back online. It also got mediawiki upgrades. I also started the first topic on my new forum concerning image licensing.

As for RubyTet, I finally got blocks drawn. It isn't much but that's progress. That's 10 commits a day for you.

I also finished upgrading the Libregamewiki blog, but there will not be a new blog post until next week. So, I am left with only Libregamewiki's planet to update. After that, I'll have to figure out something to improve Libregamewiki's service.

Tommorow, there will be definte work on learning my trignometry for Space Fighter Ace, whatever that may be.

4th Day: Bumber Ride Progression

For RubyTet, my tetris clone, development is continuing along as usual. I got to the loading the blocks and then drawing part, except it doesn't draw. Moreover, I got the position of my graphics wrong. That's woe for anytime you do something new.

Unfortunately, there seem to be an outrage for the libregamewiki server at the moment. So I couldn't exactly make much progress to upgrading Libregamewiki blog. I just downloaded the latest version of wordpress. Maybe tomorrow, I'll have better luck.

The good news is...Libregamewiki got hit with stumbleupon traffic earlier in the day. It creates lot traffic, but it doesn't exactly benefit me ads revenue wise. So this mean I ought to increase the traffic flowing to Libregamewiki without somehow annoying users. If I can do that, I could get more contributors and more articles.

Day 3: The Forum is Ready for Business!

For day 3 in my development log, I continued my vague coding effort on RubyTet. I think we're close to something dropping down into the field.

With agonizing progress of 10 commits everyday, it may take a day or three for the first shape to drop. The important thing is that I maintain progress over time. That's critical discipline training for somebody who want to be a future owner of the first full blown free gaming studio.

Anyway, the big new is that my gaming forum is open for business. This will be the future home of all of my games and gaming services. Yesterday, Charlie of Freegamer suggest that I should abandoned my effort to create my own gaming forum for his general free gaming forum. I disagree.

I don't think I should be asking the guys at forum.freegamedev.net to populate their forum with my personal kiba gaming projects, especially of a commercial nature.

Anyway, since I am officially finished with revitalizing the forum, I'll move on to resurrecting the Libregamewiki blog.

2nd Day Complete: Progress!

Despite the fact that there was no posting yesterday, I assure you that there were activity in the pursuit of my goal outlined in my last post. That is, my aim to start writing games again and continue the development of my wiki.

Yesterday, I was merely setting up the game's inital source code, with all the graphics. It is very much the same today, in which I attempt to build a vague code organization that deals with the logic of the games.

I also began work on improving Libregamewiki's forum, which sits neglected for too long. My plan for the future beyond the current projects I am working on is to remake the forum as part of my overall free gaming franchise.

Changes in Direction

I know I haven't develop extensively since August because school exhaust my energy. I couldn't develop 28 hours per week via the 4 hours a day goal. So all of my gains are now lost.

Now, I am changing pace and keeping my Space Fighter Ace project on hold. Right now, I am focusing on writing simple games like RubyTet, a tetris clone. What I am going to do is institute a new policy of ten commits every day. Though commits doesn't actually represent progress, it will mean that I done a little bit everyday. This is more workable than forcing myself to do 2 hours of game development everyday when I know my school works varies so much.

However, I think I'll devote 2 hours every weekend for the Space Fighter Ace project and acquires all the trignometry knowledge I need.

Also, I'll be trying to keep up updating the Libregamewiki with at least 100 edits in the past 7 days everyday.

Then I will blog everyday to ensure that I keep up with my goal.

Rubygame Tutorial 3 & 4

Note: Tutorial for 3 and 4 of the Rubygame book are now located here and here.


Rubygame book part 3 and part 4 are out!

Part 3 is simply setting up the controller class, which will be where all the game happening will take place. Part 4 is where you get to learn about using the clock to regulate the game speed. It also shows how to modify the titlebar to fit your purpose. In this case, we are displaying the FPS information.

If you're not already following the tutorial, start from the beginning as the series built on previous work on the game code.

Lastly, if you have any question, comment, bug report, and suggestions, please comment!

If you don't like the way I wrote the tutorial, you could alway fork my tutorial, since it is licensed under the Creative Common Attribution.

A little request: Please vote up the FSDaily story for my tutorial.

Return To Coding

Yesterday, I was able to restart work on coding my Space Fighter Ace game again after a two week absence of not coding. It wasn't related to the roadmap that I have laid out for Space Fighter Ace, but rather for a future version of Space Fighter Ace.

What I done was to write my first network application, building a very simple server and client with no game logic code. It was as far as I got in coding the network code for my game. However, it was important because I finally got back into coding, which is a necessary activity if I want to improve my chance of getting a ransom model funded project going.

The 30 Days Postmortem

My 30 days 4 hours a day programming challenge is officially a success. It has propel me to new heights in such rapid pace not seen in the 2 years I been programming. I also learned what it meant to be a disciplined programmer and learned a few new tricks as well.

During the 30 days challenge, I worked on the game engine and the map editor for the KRPGE project, Playground Wars, Space Fighter Ace and the Rubygame Tutorial project.

What I Learn:

I have learned through the 28 hours workweek why my game development projects has been so slow to progress in the past. They just took a lot of work. Even with the 28 hours work week, I still felt that progress is very slow. Nonetheless, I managed to finish the KRPGE's engine proportion in about 14 days. The Map Editor is finished in about the same timeframe.

What went right:

Of course, I was able to keep the schedule despite interruption by parents and outside events. Best of all, I was able to progress phenomenally fast in comparsion to my usual pace of development.

What went wrong:

If there is any wrongdoing, it is that I was undisciplined when it come to designing my game engine's codebase. Although it was easy for me to use, for others, with no documentation, cannot use it. There are several releases of KRPGE but nobody use it except me.

What I would do differently:

I would learn unit testing and set up a bugtracker for each projects. I would also package all my games as gem. Also, it would be nice if I know more about optimization technqiues as my games tend to fall below 30.

What I gained from this challenge:

The most improtance gain is productivity, above all. I finally broke the cycle of procrastination and no game development. I tried many schemes but none work as well as the enforced work hours, in which I was driven to develop under pressure. This build upon my experience from the first RubyWeekend contest. I will continue to use this concept to help keep game development going.

I also gained a newfound apperciation of the difficulty of writing games evidenced by the slow development cycle.

Still, all of these sucess would mean nothing if I don't keep on the pressure on myself to continue game development at this kind of level. That's the next challenge.

Day 30: Performance and Tutorial Work

Today, I spent time trying to optimize my game's FPS from a pitiful 15-20 FPS to acceptable 30. Though, it still seems to suffer from having too many objects in the game, which may make large scale battles impractical and possibly limit the game to a few fighters and objects.

For practically 90% of the increase in FPS, I merely eliminate most of the 900 map objects, it would still pose a significant problem if a users were to add lot of map tiles though.

It seem that the engine is improving during this iteration of game development. So much, that I decided to port the engine code back to KRPGE sooner rather than later. See the roadmap for details.

However, I soon hit a roadblock on my optimization problem because I don't know how to optimize further and the lack of available immediate help. So I decided to focus my development effort entirely somewhere. For that, I choose to work on my Rubygame Book.

The development work was especially fruitful because I finished part 3 and started work on part 4.

I still hope to return back to game development work because I got a gloomy feeling about Space Fighter Ace's development cycle. I feel it will be a long slog before I finally complete its development goal. For this, I estimated at least a month.

Well, this is the last post of the 30 days challenge log! A postmortem of the 30 days challenge will be written soon.

Day 29: Space Fighter Ace is Slowly Being Built

Today is Day 29, so tomorrow is the last day of my programming challenge to code 4 hours a day.

With 4 hours a day, I am slowly crafting Space Fighter Ace game mechanic, with some markup in difficulty in comparison to previous projects.

Today, I finally accomplished the death mechanism of spacecraft and bullets collision, although it have no special effects. I believed it took me two hours to accomplish this task. Another hour is spent on trying to futilely finish the movement code to no avail. The rest is spent on miscellaneous task such as trying to debug the mapeditor program, writing FPS display code for the Hud, and improving the game's FPS.

Day 28: More Gameplay Work

For today, I mostly focused on writing gameplay features such as the capability to shoot projectiles and then destruction.

Though, I mostly got stuck trying to figure out why the projectile have collision problem. It took me a while that the rect size is too big for that image. I promptly fixed it.

After that, shooting finally work. I then code a feature to allow the projectile to go faster than the player at a given speed.

I also added an enemy object and remove all its unnecessary legacy code.

I cleaned up Characters Law and then started work on a new feature that will ignore certain objects for collision detection purpose. I also did refactoring that allow player, projectiles, and enemies to share common characteristics.

Day 27: Learning Trignometry and More

Although, I been practically gone all afternoon and all morning, I was able to start coding by 16:00 and finish the session for 20:00.

I got a little lecture from Beoran on trig so I can figure out what the heck I am doing with the movement code. Thus, I learned enough to figure out the angle for moving left. The lesson and movement code were incomplete though.

Since I probably didn't have much to do for movement code, I worked on other part of the game instead. I worked on the weapon, rewriting and cleaning up. Due to what the weapon system require and how I need the game to work, I extended the engine to allow for adjustable camera movement and then add an easy way to add characters. I also did the usual cleanup such as eliminating obsolete source code and data files.

Day 26: More Movement Code

Today, I started to delve into an unknown terrority, forcing me to use geometry that I never used before in game programming. Progress is slow as I struggle with the challenge.

Right now, I am trying to implement angle based movement so that my space craft has a more realistic movement. I think I got the up angle movement right.

I also accomplish other task. For example, I decided to expand the resolution to allow for UI. Then, I implement a HUD class to give me information on velocity for debugging purpose.

Day 25: Cooking up Movement Code

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

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

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

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

5 more days to go!

Day 24: KRPGE Finished, SpaceFighterAce Next

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

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

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

This game is going to be awesome!

Release Log #4

KRPGE-0.0.3 is out!

This release now support terrains. It also got a bit of code cleanup too.

As for the map editor, the README documentation for it was improved. It also got FPS boost.

Day 23: KRPGE 0.0.3 Works Began

Though I didn't do game development in the morning as I usually do, I still managed to do 4 hours of development.

The main objective for KRPGE 0.0.3 was achieved surprisingly fast and with a few improvement and slight modification over Playground Wars's code. Terrain support, though it suprisngly requires more code than I expected, was completed in the span of two hours. Huzzah!

I also began work on eliminating the redundancy found in EditEngine and GameEngine found in the KRPGE's two program as a neccessary unplanned project along the way to the secondary objective, which is to clean up the Camera's redundant codebase.

Than I began work on the camera itself, writing a method that can be used in all 4 directions and then getting the horzontial movement methods to use the new all purpose method.


Today is fantastic.

7 more days until I achevie my goal!

Release Log #3

The next version of KRPGE is out!

Version 0.0.2 features a map editor. It even come with more documentation than the engine itself.

You can download it here.

Day 22: Finished MapEditor and Doing Tutorial Work

Well, I finished MapEditor's rendering bug and made it ready to be released. For that, I spent 1 hours getting nowhere and the finishing it relatively quickly the next hour after being confused for 10 minutes.

Since I have nothing to do, I decided to work on my tutorial. I completed part 1 and even managed to start working on part 2.

Tommorow, I will start work on KRPGE 0.0.3. For now, I must release my mapeditor in the form of KRPGE 0.0.2

Day 21: Wrapping up Mapeditor Development

Today, I finished both the map stamping option scroller and the editing system as well. So you can edit maps and cycle through the options that you want to stamp.

The only thing left is writing messages for the logger and fixing typing rendering bug, as well writing the README for the map editor.

It will be released as KRPGE-0.0.2 instead of a standalone application. After that, I'll be working on the next version of KRPGE, incorporating any useful stuff leftover from the playground project.

9 more days left! :D

Day 20: You can delete!

It is now possible to delete stuff in your mapeditor! It took me a good two hours to code out the functionality and then debug and fix it. Along the way, I made an improvement to the map engine's camera. You can save it and then reload it to see if it work.

I also learned that integers are immutable. Bumber!

Then the rest of my time are spent on figuring a way to display these characters and items graphics on the object chooser so I can get started on adding support for modifying the map. They don't work quite the same way as the map engine do. By the end of my 4 hours effort, I think I was quite close to finishing the mechanism for drawing these images.

A Roadmap

In order to keep the development of various projects from stagnating for a long period of time as well having a fresh release every so often, I devised a roadmap at the KibaBase wiki to follow.

The roadmap assumed that 28 hours are needed to complete each projects' goal. Thus a week is needed to achieve these goals, which is intentionally chosen for the purpose of having a release every week. Also it alternate between game tool development and game development to balance the need to create games and the need to create tools that will help create games.

This will hopefully achevie a sense of direction and progress as well keep me focused on what I need to do in order to achevie the goal of self employment by writing free games.

Day 19: Kept getting interrupted

I kept getting interrupted by my parents for task that they want me to get done. This mean I had to restart the hour I am in before it is an hour to me for sure. Nonetheless, I managed to get the 4 hours done and lot of commits in.

Here is the stuff that I accomplished and work on:

The typing system work now and you can use it to save your file. It even send a message to LoggerUI about the fact that the file has been written to disk.

The object of choice you want to stamp are now displayed. You can even change the object that you want to stamp. I still need to add support for characters and items though.

RubyWeekend #2 Postmortem

Here is my postmortem for Playground Wars for the RubyWeekend #2 contest. I hope it will be useful for future RubyWeekend newbies and veterans alike as well present day RubyWeekend pioneers.

What went right:

1. Getting an art partner is a very smart choice, especially if he/she is good. Qubodup is good and he free up my time so I can program. Division of labors kick butt!

2. Prior to the contest, I spent at least 30 hours on the KRPGE engine for the purpose of writing RPG games. Nonetheless, it was quite adaptable to RTS format. Plus, most of the map stuff has been done for me. I had to modify it so it can support terrain images. This free up my time to work on gameplay features. Code reuse ROCK!

What went wrong:

1. Choosing the wrong ideas can be fatal, even if the idea is a good idea. It need to be implementable in a short period of time. I think the lesson is clear here: DO NOT! I REPEAT! DO NOT attempt RTS games in a 48 hours contest. There is no way you're going to implement all the units, the tech tree, the whole 9 yards of features and test, blanace them all, let alone a stripped down RTS game.

2. Do not jeapodrize your contest entry with a bad sleep schelude. 4 hours of sleep each is not enough. Please make sure you get plenty of sleep before the contest start. It might not hurt(Actually it probably does) but you need every bit of energy and focus you can get. I was very tired so I stop coding several hours before the contest end.

3. Communication is hard. Time and time again, I learned that the communication of ideas is rather faulty. For example, Qubodup told me about a bug and I didn't realize what the bug is about after the contest. Qubodup and I had to explain our ideas to each other repeatly or correct misinformation each other have. For example, I didn't realize that Qubodup was asking about the whole map resolution, not the indiviual resolution of map terrain images.

What I Would Do Differently:

1. Write more engine code. Having more code that you can use to create games is a good thing, as well let you focus on writing games instead of writing an engine.

2. Complete the map editor or any other tools that you will need first. It does you no good to have a very difficult map to edit when you got better things to do.

3. Try to choose a less amibitious game so you can actually complete it and have a better chance of rocking everyone's boat.

General Thought About the Compos:

We need a RubyWeekend site, seriously. And advertising. Lot more advertising. We advertise quite a bit more this time around, but apparently that is not enough. We got the same amount of entries as last time(7 of them).

That is all.

I am out!

Day 18: Engine Bugfix and Completed Map Display

For Day 18, I divided my effort among several features of the mapeditor.

First, I worked on displaying the map. Then I wrote the code that eliminate drawing the majority of maps on the object, making sure that it only got drawn on the proportion of the screen. This has lead to engine code cleanup.

Next, I worked on integrating the map stamp into the engine's camera. There I have to fix a few bugs relating to the synchronization of the objects. I also have to write code for objects that does not inherit the Character class so that the map stamp can work.

Lastly, I worked on implementing the frame rate for debugging and performance analysis purpose.

12 more days to go than my 4 hours experiment will be completed.

Day 17: Resume Work on MapEditor

Today, I resume my work on the mapeditor part of my KRPGE framework.

It now load the map for editing and the editing stamp has been implemented.
Beyond that, I reused the engine code in preparation for display. There is some cleanup work on LoggerUI and the EditMode class.

That conclude Day 17 of the productivity experiment.

I expect to display the maps for tomorrow and start implementing the editing system.

Release Log #2

Hi, you can download Qubodup and me's RubyWeekend contest entry from the Kibabase wiki.

It is a very incomplete first version of the Playground Wars real time strategy game. I gave up finishing the game for the contest, but I submitted it nonetheless.

Description: The opposite sexes has decided to go to war over the ownership of the playground!

RubyWeekend 2 Log #7 Disappointment

I gave up.

Apparently, I couldn't achieve what I did last time. This contest is a major disappointment for me.

There is probably a lot of reason why I couldn't finish it. Lack of sleep, lack of willpower, too ambitious, etc.

Whatever the case, qubodup and I are too crazy. Maybe someday, I'll be able to code a whole RTS game within 48 hours.

At this point, I am just an angry programmer. I don't want to code more.

RubyWeekend 2 Log #6 Time to Panic?

Now, I am almost finished with the resupply mechanism. I just got a few bug to iron out. Once that's done, it is also done for the girl resupply units as well. I will be adding the resupply girl unit after this.

Today is the last day and I still haven't finished all the gameplay work, never mind pathfinding, AI, state of being, etc. And I got about 12 hours left to finish this game. I think it is time to PANIC!(Code frantically)

RubyWeekedn 2 Log #5 Progress So Far

I got point and click system almost done. It is just that it needs to notify the player whether if someone is selected or not. I am working on providing that indicator.

I also worked quite a bit on the energy system and the resupply game mechanic that goes with it. The SupplyBoy just needs to know how to retrieve energy source and then deliver it to the intended destination.

Qubodup worked to get all the units done as well upgrade the map. He is currently working on adding the state of units(KO and asleep).

RubyWeekend 2 Log #4: SWEET!

Qubodup finished his terrain map. It got too much water though. I also have to fix rendering and camera issue with my map engine.

Meanwhile, I finished moving around the map with the mouse functionality. It can even invoke a character to respond to the mouse click.

Now, I am working on point and click so I can move these units around.

RubyWeekend 2 Log #3: Do You Seriously Want to Continue This Insanity? You Cannot Save After This.

Qubodup and I have a discussion on whether or not we should ditch the game design. Since we don't have any better ideas, we decided to say yes to the question of whether or not to continue our insanity.

To compenstate for our insanity, we scale down our RTS design. Many of the features are simply cut outright in favor of completing the game in time. We can alway add them back into the game later. However we will suffer gameplay quality loss.

The biggest obstacle we see is probably pathfinding, since I have no experience in writing such system. It will probably be the most time consuming and difficult envendor that I have to do.

I managed to finish the game's terrain system and the game terrain map is currently being designed. But to me, this is not a lot of progress. I felt that we fell behind already. Completely my fault since I have to code all the features.

RubyWeekend 2 Log #2

I am coding support for terrains so it will be replacing the background image. I also have some problem with git but I figured it out. This terrain system will definitely be merged back into the KRPGE codebase.

The progress is painstakingly slow though.

Qubodup has been working on the unit graphics. They are defintely better than what I can do.

I hope to finish the terrain system pretty soon. If not, qubodup and me are in serious trouble.

RubyWeekend 2 Log #1

The theme is Opposites.

The first hour or so, qubodup and I are coming up with game ideas. Then we settle on a game called Playground Wars.

It is about a bunch of kids, divided among gender line going to war with each other for ownership of the playground. Of course the adults all thought it was a cute game and is oblivious to the seriousness of the war.

You can visit the Playground Wars's github repository if you want to see some of the latest changes.

RubyWeekend Contest Goal

Since the RubyWeekend contest will start in one hour(assuming that the contest organizer is not tardy), I decided to write my goal for this contest.

My goal for the RubyWeekend contest:

1. Create a fun game to play.

2. Not rank dead last.

3. Have lot of fun!

And qubodup is my art partner in this contest. I'll also be blogging this contest the whole way like I did last time.

Release Log #1

Hi, I just released a new version of the rbgooey library in preparation for the RubyWeekend contest.

This version is 0.0.6 and it fix the crash bug associated with opening too many TTF objects.

You can download it at rbgooey's rubyforge page.

Day 16: Mapeditor Progress Report

For Day 16, here is the mapeditor progress report:

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

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

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

Day 15: Restarting Work on Map Editor

For Day 15, I restarted work on the map editor program for my KRPGE framework. However, I did not make much visible progress.

I have a tendency to have rendering problem but eventually that get solved. There were quite a bit of work on the input system and also work on gathering data so it can load files. The class for editing is created but not much is in there yet.

For the last hour of my programming time, I was investigating an interesting bug that crash my map editor after a certain amount of rendering. I found out that all the font that was opened stay open...so when I open enough of them, it crash.

Tommorow, I'll have to fix rbgooey's textrender class so it doesn't create excess files to the point of crashing the program and continue writing my map editor program.

Day 14: Engine Release!

The KRPGE engine is finally released! You can visit the KRPGE homepage for more information and download.

Tomorrow, I will be tackling writing the KRPGE map editor.

That's it. I don't have much else to say.

Day 14 is complete and 16 more days to go.

Day 13: Workload More Than Expected

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

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

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

Day 12: Game Engine Complete

Day 12: 45 commits and 48 hours logged so far.

Well, the game engine is completed and it now have a name: KRPGE(Kiba Role Playing Game Engine).

The only thing left is actually preparing it for release. I have to get rbgooey out the door first since rbgooey was updated for use on the engine.

After that, I will be working on preparing the game engine framework so people can actually use it. It will have blanks placeholder files so people can add their code to it.

Once I am done with releasing the framework, I will be working on the map editor again.

I hope to finish it all before RubyWeekend #2. If not, at least I have some advantage over my peers in term of how much I have to do.(assuming at least I get the engine out)

18 more days to go before I complete my training. :)

Day 11: Nearing Completion

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

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

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

Progress so far:

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

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


Plan:

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

Day 10: Racing Toward the Deadline

For day 10, I made 54 commits and finished a task completely.

The enemytracker class is now officially cannibalized. It no longer exists and now live on through the characters tracker class. This mean that the characters, whether they are foes, npcs, or players are now managed by a single class.

I also begun work on moving the ItemsTracker out of the map engine, since it also have no direct relation to the map engine codebase.

The adapter class also completed it transition.

MapLaw got a bit cleaned out as a side effect of all the work on the other tasks.

The good news is that I have no consideration for redesign of the engine, for now. This should mean no unexpected delay, bar coding roadblocks. However, I don't expect to finish the codebase by the end of this week unless I pull an all nighter. The goal is to finish it by the time of the RubyWeekend contest. If neccessary, I will do a longer coding session to finish it.

Excluding the RubyWeekend #2 contest(2 days suspension), I have 20 more days to go until I complete my training and productivity experiment. Since RubyWeekend is expected to take all of my time and goes beyond a mere 4 hours, it will not void the experiment.

Day 9: A Codebase in Chaos

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

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

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

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

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

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

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

Day 8: The Last of the Cleanup?

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

Day 8 yield two important changes in the codebase.

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

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

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

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

Day 7: Slowly but Surely

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

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

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

Day 6: Inching toward a Map Editor

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

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

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

Day 5: Roadblock Destroyed

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

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

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

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

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

Day 4: The Road to Kicking Ass continues!

Well, since I didn't overcome the roadblock yesterday, I decided to focus on writing the rubygame tutorial. You can visit this project at the kibabase wiki.

As you can see, this is called the Rubygame book project, designed to be the ultimate tutorial for rubygame beginners.

I was almost completed with part 1 when I was done with the 4 hours. It didn't look like much but I have to wrestle with the mediawiki extension, which took quite a bit of time. But now the mediawiki have increased functionality when it come to source code, as it should be for a game development wiki.

Tommorow, I am going to hit the roadblock hard and hopefully break through to complete the map engine module project by next week.

26 more days until I start kicking some very serious ass and rock the world with my madz coding skills and discipline..

Day 3: Coding Roadblocks

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

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

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

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

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

Ongoing Experiment in Right Direction

I must say, the early results were promising.

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


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

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

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

4 Hours 30 Day Experiment

Today, I am going to commit an experiment in productivity. 4 hours of coding for 30 days straight on any gaming projects that I choose to do.

The idea is that 4 hours is going to add up a lot of completed games and cool game projects, as well money.

I know I didn't find the groove for productivity yet so it may yet be another in a long string of failures. Maybe I get lucky with this one. Who know?

Also, I'll try to blog my development effort with more diligence. It should provide me with extra motivation.

Plan of Attack

Here are the things that I wanted to do for the next few days until Sunday.

==Requirement==
*The CopyPirate's map engine can be forked into an engine library of some sort.
*Development of The CopyPirate 0.0.2 can begin.

==Hope for==
*Rake file for zipping things up
*Start development on Human Robohunt

==Pipe dream==
*Rbgooey being transformed in the world's most sophisticated game UI

RubyWeekend Postmortem

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

What went right?

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

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

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

What went wrong?

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

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

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

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

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

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

What I would do differently.

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

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

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

RubyWeekend Hour 33: The CopyPirate Uploaded

The CopyPirate is ready for public consumption!

Visit this site for download!

I finished first!

RubyWeekend Hour 32: Approaching Last Milestone

I finished the the maps and just got started on the HUD.

The hud will be simple. The information it will have is simply health and items collected.

Time to code it! I am going to try to finish this in the next hour.

RubyWeekend Hour 31: The End is Finally Near?

Well, I am finishing up the tiles graphics for the map. Once that is done, I will be finishing the final part of the game, the HUD.

I imagine the HUD to be an easy affair.

Once that's done, it is time to write a README and package the game and SHHHHHHHHHIP it.

Forget additional enhancement and the like during the contest, because I have ENOUGH of this.

RubyWeekend Hour 30: MapObj Organized and Design Choice

Well, the arrays in mapobj class are now organized and editable. The map engine is now no longer a nightmare to edit anything by hand for the first time in its evolutionary history.

Also, I decided to leave the weapon system as it would make the game way too easy since there are no zombie creation system.

RubyWeekend Hour 29: Map editable by hands

In theory the maps were editable by hand. However, in reality, it is difficult to edit because you do not know the location that this map part correspond to unless you count, which is a tedious and error prone process.

Creating a map editor would eat up time in the contest. Times that I don't simply have. It might be worth it in the long run but the game map must be completed
in time for the contest.

So I just organized the maps and now you don't have to count. It is very easy to find out where a part correspond on the map just by looking at it. Thus, I don't need a map editor to edit my maps.

RubyWeekend Hour 28: You can now win the game!

All parts necessary to win the game are in place. This include the item gathering and reaching the internet pipe as well the victory screen.

Next stop will be a proper map and the final gameplay element, the combat system.

RubyWeekend 28: A Slow Start

The last post is an hour late. Sorry about that.

The development is off to a slow start but nonetheless, it is a start. We have 14 hours left. Even with this much time, I feel like to have to run the whole way.


For now, the win condition code is in place.

RubyWeekend Hour 27: The Start of the Last Day

This is it. It is the last day of the contest. I started the day on working on the win condition code.

RubyWeekend Hour 26: I am out!

I finished the game over death scene and I just started working on the win condition part.

But development stop now! It already is midnight and I need sleep.

So....good night!

RubyWeekend Hour 25: You can die

Zombies can now do some real damages and even kill you. However, there is still of no real consequences when your health goes to zero other than saying that you're dead.

I am working on that death screen next and then I will call it a night. Hopefully, tomorrow is plenty of time to finish my project. The last thing I want to do is not finish a contest I proposed in the first place.

RubyWeekend Hour 24: Item gameplay down

Part one of the gameplay done. Now you can collect items necessary to unlock the way out.

Time for me to focus on the fighting aspect.

RubyWeekend Hour 23: Items are sync

The items are now sync. All we need is to add some functionality to these items to complete the whole part of that gameplay aspect.

RubyWeekend Hour 22: Items and things

The enemy zombies can't go through each other anymore.

Also, I begun work on the items, which will be essential to winning the game.

RubyWeekend Hour 21 : New walls among other things

In this hour, I finished an AI enhancement which will ensure that the roaming AIs won't get stuck.

I also added a few new walls and edit to make the beginning of the map.


Next stop, make enemies AI not be able to go through each other.

RubyWeekend Hour 20: Enemies follow the rules too

Nothing much here except that the enemy are now up to date when it come to following the rules of the gaming universe.

Time to make roaming AI more intelligent.

RubyWeekend Hour 18-19: MapLaw Finished!

The mapengine coding has spilled over to the next hour because I was in the middle of coding. It was only after the end of hour 19 that I was able to stop coding.

In that time, I finished porting MapLaw. MapLaw is basically the physics of the game world. The law I impelemented is that for some map tiles, you cannot go through it, effectively making them walls.

Now, I just need to apply it to enemies too. It also mean that I will need to reprogram the roam AI so they don't get stuck forever when they hit the walls.

RubyWeekend Hour 17: Sync complete

The sync of the enemy's goal to the map engine is complete.

Now it is time to make the map tiles a physical reality in the game world.

RubyWeekend Hour 16: AI finished

I just finished writing the code for zombie movement, although it is incomplete for the roam part.

However, it also have to be synced with the map engine too. So I will be off to the mapengine again.

RubyWeekend Hour 15: More Work on Enemy AI

Argh. Like everything else, the enemy AI take forever to program. Perhaps that is due to me being distracted by other things.


In any case, the foundation are almost in place for the enemy AI.

RubyWeekend Hour 14: I Just Woke Up

OK, I just woke up so there isn't much going on, progress-wise.

We're just getting started with programming the zombie's AI. The AI will be the same for the RIAA vampire lawyers as well. However, the vampire lawyers will be more intelligent if I finished the game with time to improve on the game's gameplay.

RubyWeekend Hour 13: Done for the night

The enemies are synced up with the map engine's camera.

That's it. I am done for the night. See you all tommorow.

RubyWeekend Hour 12: Yay, the enemies are displayed

The enemies are finally displayed. They can't really do anything, not even generate new zombies. That will change tomorrow.

In the meantime, I am going to sync up the zombies to the map engine because you can't even touch a zombies because they move along with the players.

RubyWeekend Hour 11: Still coding that thing

I am going to be really brief with this post.


I am still coding that enemy generation thingie.

RubyWeekend Hour 10: A game is starting to emerge

There is not much to see here because I am still coding the foundation of enemies generation. Nonetheless, I did created the zombie graphic. My idea is to create variants of these. However, due to time constraint, I won't produce variants until the game is feature complete.

When the enemy generation feature is complete, the program will start to resembles a game.

My goal doesn't really reach far beyond feature complete stage. All I hope for is for a complete game ready to submit for judging. When the next RubyWeekend contest comes, I hope I will be a faster coder and thus able to extend my goal a little bit beyond feature complete stage.

RubyWeekend Hour 9: New graphics

Instead of coding the enemy generation system or the weapon system, I decided to create new graphics.

The first image was music item, which you will need to acquire a certain amount in order to escape the zombie infested server and win the game.

The second image was the infamous GNU tnt bomb first seen in the title screen. It have a 3 by 3 blast radius and a delay of 5 second. Anything in its radius is automatically killed, including the vampire lawyer and the player pirate himself.

RubyWeekend Hour 8: Camera complete

I finally got the camera class finished for now. That's a lot of code for one class.

Next stop, it seem will be zombie generation and weapon system.

RubyWeekend Hour 7: Take Forever to Get This One Right

The progress so far...


I finally finished the right and left proportion of the camera class. It took me a while to get it right because it crash so slow sometime. Also it involves lot of python to ruby code conversion. So it added to the time of coding the camera part.

The good thing is that I didn't have to figure how to do camera out.(Thank god!)

The next time I posts on this blog, I hope to get the camera done too.

RubyWeekend Hour 6: Yay for maps being shown!

Map tiles are shown for the first time. You can see it in the left corner.

As you can see, I gotten far enough to display these babies. I also begun work on camera, which did not see much progress after I finished the map displaying work.

It seem that I have pull an all nighter if I want to complete this project just in time for judging. Progress are pitifully slow.

RubyWeekend Hour 5: MapEngine work

There isn't much to show for the mapengine class partially because it is a lot of work and partially because I am slow.

I only added the mapobj class, which keep all of the map data in the last hours or so. I spent much of my time flipping through the files to do lot of little things.

I hope to get some map tiles showing the next hour I post on this blog.

RubyWeekend Hour 4: Brainless merging, Pirate Creativity, more Brainless Merging

New clean artwork are created for the pirate player character. Then I implemented code for moving this character. You can move up, down, right, left, and also move diagonally. Moving diagonally is hard because you need precise timing. However, I don't really care because it is a minor and unnoticeable blunder to the vague game play I have in mind.

Next, I set to work on working on the mapengine, creating the mapengine class.

The CopyPirate(the name of the game) is really a merger of two game, Twisted Shootout and SpaceFighterAce, and some pirate creativity that I have to do. Thanks to the experiences and the codebase I worked on over the year, I can really be lazy in this contest.

RubyWeekend Hour 3: The onstructioncontroller is under c

The progress thus far:

I finished the titlescreen UI and started work on controller by displaying the pine background to represent the ship(or server)'s deck. I also managed to sneak in a game loop where you can only do really basic stuff like quit the game.

The controller is basically a class that talk to every game element classes in the program and manage the game. So it basically snitches together all the stuff neccessary needed to make the game do its stuff, sorta like a car chassis.

RubyWeekend Hour 2: Titlescreen UI coming along

I got the titlescreen UI almost put together. I just need to add mouse functionality and the startup screen will be good to go!

I noticed a typo in the titlescreen jpeg but it will be easy to fix.

The progress I made so far is to make it go up and running, as well building the titlescreen UI. Not much but it is a start.


I think I am far ahead of everybody since some people are surprised that the contest just got started.

RubyWeekend Hour 1: Internet Pirates versus RIAA zombies

RubyWeekend has just started an hour ago!

Ok, it isn't exactly one hour into the contest, but it is quite close.

I already decided what my game will be and what I will be coding. Since the theme is about pirates versus zombie, I choose to parody file sharers as pirates as they're often called and the RIAA as zombies because they're accused of taking advantages of artists.

Also I am planning to port the Twisted Shootout's map engine so I can save development time and concentrate on trying to create good gameplay.

As you can see, the titlescreen is already done. I also done some inital brainless inital work.(Again using older codebase as templates)

Twisted Shootout Version 0.0.1 (pre-alpha) is OUT!

Well, Twisted Shootout is finally out.

Like I say, it will not be so much fun to play. You can expect that in later versions, but not now.

Nonetheless, Twisted Shootout is the most developed game ever by me.

Now that I finally announced the release, I can start developing the next evolution of Twisted Shootout.

It will have a revamped map system at the very least. I hope for better enemy AI and better battle mechanics(ok, that is maybe too much?). At the very best, maybe I will implement a music and sound system and a menu to go with it.

You can discuss the post here.

Twisted Shootout Release is Imminent

I been working on a game called Twisted Shootout over several months and finally it is almost ready for its first release.

Twisted Shotout is a 2d shooter game inspired by the game Metal Slugs but the first release of the game will probably not be very fun. However, it marks a milestone in my game development journey. I finally actually complete a playable game and it is also the furthest in development!

I do plan to try to make twisted shootout a fun game though as the development of the game goes on.


For now, I have a techdemo available for download for testing purposes. For more information, visit the forum thread on the techdemo release.


You can also discuss this blog post in this thread.