Fetch with Puppy - Unexpected Progress but no Screenshot

Well, this is interesting. It turns out that Flixel has made this go really quickly. The code that I thought would take all day took an hour and a half. I don't have graphics yet, so no screenshot. (sorry!)

Not sure what to do now. I had planned to be working all day on this logic. Hm.

In other news, I will be ditching C++ and Ogre3D for my action RPG and will use 2D graphics and AS3/FlashPunk. It seems to me that it's a better choice. I will be using the Adobe AIR platform (IE: Desktop/mobile app) rather than Flash, though.

What to do with the rest of today, though..? Not sure yet. I don't have much more time today since I've got a long-ish homework assignment that I'm starting in about 45 minutes and after that I have a class that I'll get home from at about 11PM. Bah.

Peace, love, and fast progress,

--- Henry

A Code Painting - Fetch with Puppy

I've started on a code painting. It's about a kid playing fetch with a puppy; hence the title, Fetch with Puppy.

I'm writing it in AS3 using Adobe Flex and FlashPunk.

Its mechanics boil down to the following:

• You have a puppy and a ball
• You can walk back and forth
• You can throw the ball either overhand or underhand
• Your puppy will try to catch the ball when you throw it

That's a pretty simple set of mechanics, I think.

It was inspired by the "fish pond" applet that I have on my other blog, which is usually good for calming myself down when I'm feeling stressed out.

By the end of the week, I plan to have something playable.

Today, I'm going to be busy cleaning up my room (it's gotten awful) and I also have a bit of homework to do (college does that), but I'll try to get something together by tomorrow afternoon or so.

Here's hoping I can get it done.

Peace, love, and soothing play,

   --- Henry

A Purpose for Code Paintings and a Larger Project

I've decided to ditch libPainting in favor of doing code paintings free-form. Defining the interface that strictly wasn't the best way to go about the idea.

I will be working on a large action RPG project which will likely take a very long time. I'll post updates and the occasional demo on this blog. The first demos will probably come when I get around to making a Sourceforge page for it.

As for the code paintings, I will be using them as side projects to take a break from the action RPG. The simple nature of a code painting lends itself to being a minor project.

Peace, love, and the best way forward,

   - Henry

About My Future Projects

So, without posting specifics (mainly because I'm flip-flopping about the ideas that I have for games), I'd like to talk a bit about what kinds of games I will be making.

This was covered in a more philosophical way on my other blog, just in case you'd like the philosophy behind it. For those reading later on (IE: after I have posted more on that blog), the philosophy is in this post.

I have decided to take the title of that blog for the type of game that I will make. I've decided to call this type of game a "code painting."

I am working on a specification for this type of game but have only just started on that. I will probably put the document up on Google Docs and link to it when I have the first draft completed.

Here's a summary of it, though:

• Minimal interface, menus opened with key presses
• Game starts in play state, becomes idle when not playing
• Simple concept with no unnecessary elements
• Avoid traditional or cliche premises
• Use either procedural content or as little content as possible
• Prefer polish over technology or amount of content

I will, again, post more about this idea when I have a document that actually gives a specification. I will also be creating a library for these functions that will be written in C++ and use the SDL media library.

With PyWeek coming up, there may also be a Python/Pygame version of this library.

Peace, love, and a direction to move in,

--- Henry