Trying out RPG Maker VX Ace

October 12, 2014

Well, I’d never have figured I would get into this sort of 2D game making tool but Humble Bundle’s (now over) Game Development competition had me psyched. I purchased VX Ace and worked on a mini-game for 3 weeks. Sadly, a week before submission I had to jump into Industrial Training and was forced to drop this small project. Oh how I wish I could have submitted it.

Nevertheless, I had some pretty fun and wonderful experiences, and really ventured into RPG Maker VX Ace in those three weeks.

166 hours into it! I know others probably have in the thousands, but I guess it goes to show that if you’re spirited enough you can keep going at it no matter how alien it is to you at first.

In an attempt to make my main menu different from the other submissions, I jumped into RPG Maker’s scripting engine which runs on Ruby. I’d never touched Ruby as a language before, so this was a fresh first.

With those minor alterations to the base code for the main menu, I was able to add a credits and controls page for players. If I had more time on my hands, I know I would have done so much more!

Added some shameless self promoting in the credits as well, all in good fun!
The Credits page that players will see.

Setting up the first mountain village was pretty easy after figuring out what each button did in RPG Maker VX Ace.

I relied heavily on GIMP 2.8.10 to produce certain tiles and images I needed. Whilst art and drawing is most definitely not my strong suit, I figured out how to do some pixel art in GIMP. The workflow is quite different for producing pixel based art instead of the usual brush style work.

Finally, here is a look at a bit of the game itself running and interacting with NPCs.

Making up the world that Suria would explore to reach his destiny was one of a lot of fun! I wrote down different story endings, discussed some with a close friend and threw ideas back and forth. If there was one thing I wished more for than being able to submit my project, it would have been to have a partner to work alongside with (and the option to export to Linux!).

LOVE2D Ubuntu Game Development

February 22, 2013

LÖVE2D is amazing to say the least. In comparison to PyGame’s documentation, LÖVE’s is way ahead. In LÖVE’s documentation, they help let you know what functionality was introduced in what version of LÖVE so you never end up using a deprecated function. On top of that, the developers even document functionality that isn’t even out yet! This means I can prepare my game for these changes coming to LÖVE2D right now, and not have to worry later on. Things are a lot more visible, well documented, and organized on LÖVE’s wiki.

To top it off, many of LÖVE’s functions are made in a way so that they are self-explanatory. Even then, they make sure to include how it should be used in the wiki (sometimes with the guidance of images, or even example code). Not to mention there’s even a math section to help you get going! PyGame’s documentation really lacked visibility and organization. It made it that much harder to move forward programming my simple fruit catcher game in PyGame. Not to mention, LÖVE2D has such an easy way to “compile” and run the game. I just select all my .lua files and data files (images sounds etc) and compress them into a .zip, then I just rename it to .love instead. On top of that I can just send my .love file to a friend, and that friend can double click it to run it and play (So long as they have LÖVE installed on their computer).

In the past 4 days, I’ve already managed to create the following:

  • Start Menu
  • Options Menu
  • Game level

Some interesting things to note is that, in my main menu background and options menu background, I have animated clouds sliding through and the text above growing and shrinking. This helps make my menus a lot more interesting and “alive”!

My current main menu design

My current main menu design

LÖVE2D is really good on performance. I’ve been testing it on my desktop, and naturally it will run well. What’s really amazing is that it runs exactly similar with same fps of 60 on my friend’s 2009 Macbook pro model running Ubuntu 12.10. They’ve really worked hard to make it smooth and robust. Currently, I already know how to change between different resolutions and go fullscreen/windowed-mode. I’m just in the midst of figuring out how to make a suitable method for the player to choose the resolution (e.g drop-down menu, or scroll menu etc). I think I can safely say at this point, I won’t be using PyGame anymore (especially since it seems there’s no more active development going on, at least not visibly noticable).

Giving LOVE2D a Chance

February 17, 2013

My holidays have finally started!

Now that I have some time on my hands, I’ve started looking at alternatives to PyGame. Previously I thought about using Unity 4.0 and turning Fruit Catcher into a 3D game. It would be easy enough to do, since I’ve already done a basic first person shooter in Unity 3.5. The problem lies in the fact that I’d have to continously boot out of Windows and boot into Ubuntu to test the game. So I’ve scrapped that idea for now.

Working with LOVE2D in Ubuntu 12.10

Working with LOVE2D in Ubuntu 12.10

Thus, today I tried out LOVE2D. In previous versions, LOVE2D was too heavy on resources and would bring my measly laptop to it’s knees. Now, however, the 0.8.0 release is pretty solid. Not to mention they’ve added more functionality, updated their documentation, and optimized LOVE itself. From my laptop, my friend’s laptop, and my desktop, we all get a solid 60 fps with my basic game thus far.

Running Fruit Catcher in LOVE2D.

Running Fruit Catcher in LOVE2D.

The real test of course, will be down the line. I have not yet implemented my star particle system in this Lua port. When I get all apples and bananas dropping, with stars jumping around on screen, that’s when we’ll see how the framerate handles. For now though, this is a lot of fun!

GIF showing Fruit Catcher running in Love2D

GIF showing Fruit Catcher running in Love2D

New Year, New Code, New Challenges

January 18, 2013

Been a hectic couple of past weeks. Had guests from overseas, was unable to pay the University fees in time, car died completely, had a mountain of assignments to pass up. When life comes to challenge you, it will challenge you from all directions at once.

That said, today I made some new modifications to my Fruit Catcher game. Weeks ago I worked on a new background image, and that image took about 3 to 4 hours of drawing time (I’m no artist). Today, I implement that image into my game and learn that having absolute values for object positioning is a very bad idea by design. At least in my case it is.

Using absolute values for positioning

Using absolute values for positioning

When using the new background image which was a lot larger than the original (it’s 1280×768), I discovered all my fruit objects my basket and the score values were horribly misplaced. This meant that by using absolute values, I was restricting myself to only one resolution in the future. If I ever discover how to give the player the ability to change resolutions, at least now I’ve properly implemented values that are relative to the current screen size.

Using relative values instead.

Using relative values instead.

Without much further ado, here’s what the game looks like in it’s new bigger resolution and higher quality background image.

New Background Image

New Background Image

The game is slowly coming together, but it’s at a much slower pace than I anticipated. I was even thinking of just making a 3D version of this game using Unity 4.0, since it’s multiplatform and really easy to use. I’ve found myself making a start menu, pause menu, game level and actual gameplay all really easy to do in Unity. Time will tell. I have my academic holiday soon, and I’ll hopefully spend time on this idea (whether continued in PyGame or Unity is uncertain).

More development and some new hardware!

December 21, 2012

So, my development on the fruit catcher game has been slow as of late. Three reasons for this:

  • Still a full time student (prioritize assignments/final exams)
  • Continuously fleshing out the game idea/design on paper.
  • I have to learn Python & PyGame for each new added functionality.

However, I have made a relatively big stride as of late. I’ve restructured my code in a more appropriate manner that reflects better gameplay during runtime on all three platforms (Ubuntu, Mac, Windows). Previously, my main game loop was pretty messed up. I mingled code that was meant to handle input and events with code that were meant to update game counters/states.
This caused some serious problems when blitting to the screen. For example, my particle system would disappear from the screen whenever I pressed an arrow key.

Fruit Catcher Update

Running the new update on Ubuntu 12.10

In this new code, I’ve also started numbering the versions to keep track of what I have changed and what needs improvement or is broken. I’ve added a simple scoring system that checks for collision between a fruit and the basket, and then adds 1 to the score. I’ve also added a new fruit! A banana! Yay for random fruits dropping out of one tree…

More importantly, multiple fruits drop down from the tree now. And they do this in random order (but not yet random speeds). One moment you may get all Apples, next maybe bananas, or both. At the time, I have only 5 fruits at any given time falling from the tree.

I am now looking into adding more fruits, randomizing fruit drop speeds and maybe (just maybe) adding joystick controls for input. Like using an Xbox 360 controller, or my Logitech Rumblepad 2, or my PS1 controller with the game. If I can successfully do that, that will probably be enough motivation for me to start designing a start menu and figure out how in the heavens do I change Pygame’s window resolution at will. In Ubuntu, and Linux in general, there is a joystick library that can handle all types of joystick input. I don’t know if such a thing exists on Windows and Mac yet.

Last, but not least, I got some new hardware for my desktop. Specifically, an Nvidia GTX 680 (ASUS DirectCU 2). I got this because I’ve become fed up with my AMD RadeonHD 6870’s Linux drivers. The non-stop windows tearing, lagging games, and slow to support the latest Xorg are all reasons behind this. While Nvidia users were enjoying performance increases with the new drivers, I instead got an error message saying “Your card is not supported by this driver”. I am aware AMD drops support for their older cards faster than Nvidia, but this is ridiculous. One generation behind their current cards, and already they leave me in the dust. So much for the 12.12 Catalyst driver. That was the last straw.

Nvidia GTX 680 vs AMD 6870

Nvidia GTX 680 vs AMD 6870

The 680 is a beast. Not only does it max out ALL my games at the moment (including BF3, Saints Row the Third, Serious Sam 3[Linux], Dungeon Defenders[Linux]), it does it without a sweat. To better perceive this, my AMD RadeonHD 6870 when idle will average 60 degrees Celsius. On full load, it will go up to 80 degrees Celsius (and become really noisy). What about my 680? It’s literally jaw dropping. The 680 when idle will average 30 degrees Celsius (ROOM TEMPERATURE FOR GOODNESS SAKE). On load, it goes up to 60 degrees Celsius at most so far. Not to mention I can barely hear my desktop now [all on 1080p gaming]. This has to be one of my most worthwhile purchases in a long time. My first ever Nvidia card was a OManli 9400GT and that wasn’t a very awesome experience. Graphics cards have really come a long way in just 3 years time.

Nvidia 9400GT

Oldschool Nvidia

The American House

December 1, 2012

So, I’ve been doing my Unity project work for the entire day. Been testing my game executables on Windows 7, Ubuntu 12.10 and Mac OS X 10.7. With the release of Unity 4.0, I’ve been having a lot of fun seeing my measly game work on all these platforms with minimal effort on my behalf thus far.

Today, I decided to also make some better looking house models for my game. The one I currently have is really ugly and was basically used when I was figuring out how to properly import Blender models into Unity and ensuring the Mesh collider worked. Here’s what my first and rather fugly house looked like:

My initial house for my Unity project.

My initial house for my Unity project.

The texture’s aren’t self made. I don’t currently have the time to go taking photos with my camera around the neighbourhood for this. So, instead I grabbed textures or images suitable enough and compiled them into one image using GIMP 2.8.

After getting more used to how UV mapping works, and remembering all the Blender shortcuts, I was able to produce a more visually appealing house today. Note that I don’t give it too many shapes because my university’s lab computer’s only run on Intel graphics (which suck pretty bad).

This is what my new “American House” looks like. I call it American because it has a garage, and the main body is essentially built out of wood which seems to generalise what American (U.S.A) houses look like in general.

My house without textures, rendered.

My house without textures, rendered.

The process of adding UV textures.

The process of adding UV textures.

Finished applying the textures completely.

Finished applying the textures completely.

The textures were put into a 1920×1080 canvas in GIMP 2.8. With the larger image, it was possible to have better looking textures across my house model. I know it’s no masterpiece, but it is significantly more pleasing to my eyes and I’m sure to anyone else who would judge this. Now all I have left to do is bring it into my Unity project, and hope that the textures don’t go haywire like they do sometimes. Wish I had pictures of some of my other classmates projects, who take Games Programming 2 as well, since there are some really stunning models and animations they put into their Unity world. One guy even had an awesome mecha with full animation running around, but the world wasn’t proper yet.

Working with PyGame and Python on Mac OS X Lion (10.7.5)

November 29, 2012

So, previously I managed to get my Ubuntu Pygame working in Windows 7 64bit. It was a little difficult to setup because on Windows PyGame expects Python’s IDLE to be 32bit, so I had to install the 32bit version of the IDLE before I was up and running.

Today I decided to test my game on my dad’s secondhand Mac Book Pro 64Bit (2009 model). I ran into many problems and have found the Mac to be just that more harder than Ubuntu and Windows 7 so far. Anyhow, I have to run a slightly older Python IDLE version and PyGame version for things to work out.

After trying many different guides for OS X 10.7, I stumbled upon this blog. The only solution that worked for me: link.

After struggling for a couple of hours, I’ve managed to get my game running properly on the Mac. Everything works. I’ve got my apple falling in a continuous loop. I’ve got my moveable basket on the x-axis. I have collision detected between the apple and basket appropriately. Most importantly, I have my particle system made up of self drawn stars working smoothly on this rather old hardware! It’s only a Core 2 Duo with an Nvidia 9400M GS but with 4GB of DDR3 RAM. I was very worried it might bug out or slow down to extremes, but so far it’s all smooth. The real test of course will be when I have multiple things happening at once such as score updating, particle systems starting and stopping, and multiple apples/fruits dropping and being deleted properly later on. For now though, I am happy the base game works.

Here’s a look at the game running on my Mac Book.

My pre-preAlpha PyGame running on my old MacBook Pro.

Lastly, I found it quite hard to locate ~/.idlerc to put the config-highlight.cfg file into. I dislike the IDLE’s bright white background. So I usually use this guy’s themes: link.

I found that the hidden .idlerc folder is located right inside the Users/Username folder. In my system, my folder is called iptv. Basically I copied my .cfg file in the terminal and directed it into the .idlerc folder, since I couldn’t find any way to make the hidden folder visible in the default file browser window. The following picture is basically the whole process of setting up the .cfg into the right directory for the IDLE to detect it on my system.

Using the Mac Terminal for the first time. Commands are I think almost 100% in similarity to how I use the Ubuntu terminal.

After that, it was just a matter of going into Python’s IDLE and setting it to use the tango theme. IDLE -> Preferences -> Highlighting -> Custom Theme and then selecting tango from the drop down menu. Looks like I’m now set up on all three OS’s, and can start adding further game functionality in the times to come. In the meanwhile, my Unity 3D project and Matlab Audio project are due…


Get every new post delivered to your Inbox.