LOVE2D Ubuntu Game Development

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

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

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

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.

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

New Year, New Code, New Challenges

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

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.

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

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!

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.

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

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.

Oldschool Nvidia

The American House

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.

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.

The process of adding UV textures.

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)

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…

Casual Gaming

On all computer platforms, and mobile devices casual gaming is very popular. From business men to 4 year olds.

For this very reason, I figured it would be a good way to start off my first proper 2D game that I make. This is a game I hope to complete and then get it sold on the Ubuntu Software Center. Hopefully, from there the plan would be to get it onto Desura, Gameolith and then Steam Greenlight.

I had previously ventured into using the SDL library with C++ knowledge, but this proved to be quite time consuming and I’d end up focusing more on why my syntax was wrong instead of focusing on making my game logic work right.

This is where PyGame and Python came into play. I had previously messed around with Python a couple of years back in it’s IDLE interpreter and found it fun to play with. Now looking for a serious API, PyGame has become my main tool for developing my 2D casual game.

PyGame and Python are multi-platform, easy to code and have a plethora of additional libraries for me to add more functionality to my game (like Twisted for network etc).

Without further ado, these are some screen shots of my 2D game working on both Ubuntu 12.10 and Windows 7. Note, the art I used here is self made and only temporary. They act as a placeholder while I work out the kinks in my code. I’ll definitely be making better finalized art for the final output, if I can successfully reach there.

Fruit Catcher running on Ubuntu 12.10.

Now running the same code, only slightly modified on Windows 7.

I am well aware that both Python and PyGame itself can be heavy on resources. With this in mind, I have many computers in my household amongst family members that I can test this game on. The lowest specced machine in my grasp is a HP Mini with an Intel GMA 945 chipset. The highest system I have is my current development system, my desktop. An AMD Phenom II x4 with an Asus AMD RadeonHD6870 dual booting W7 and Ubuntu 12.10. If I can successfully make the game run smooth enough on the HP Mini, then I can be certain to make it run great on higher end systems. Only time will tell though, as I get deeper into adding game functions.

To end my post today, my game has only the following functionality:

• Particle System (shoots stars within a 180 degree range, upwards)
• Animated Apple (falling down in a loop continously)
• Collision Detection (my apple hitting the basket, thus triggers the particle system)

I am able to add a self updating text unit on the top of the screen for the score, but have yet to implement it in Fruit Catcher. One
issue I currently have is that sound that plays fine in Ubuntu 12.10 in PyGame, does not play in Windows 7. I am not yet sure if this is
because of my sound file format, or if Windows 7 doesn’t play well with PyGame.