Archive for November, 2007

A Rubik’s Cube that’s comfortable in your pocket

November 29, 2007

Mix The Cube! screen

If you ever threw an unsovled Rubik’s cube at a wall out of frustration- well, you probably won’t want to try this because a broken $10 puzzle is still better than a broken $150 game system. Created by Sinasquax, Mix The Cube! takes that square-spinning puzzle to a whole ‘nother level with a feature set that’s pretty extensive for a first iteration release. I never did play with the real thing that much, but this one might actually grow on me because of what it offers. Included is a set of tutorials which ease you into the game and into the challenges ahead. You start from a 2x2x2 cube, with a few shuffles and moves, working your way up, or you can solve any cube you want in Free Game mode.

Also amazing for a homebrew game is that it uses the PSP’s own built-in save system to keep and load files. This alone adds a professional feel to the game. The options are also abundant; a lot of graphical tweaks and directory options for game files are available. In-game features include screenshots, which is nifty though maybe not crucial for this type of game. I would really welcome it in action games, though.

A common complaint is that the game freezes if put in the wrong directory- it needs to be put in a directory named by your firmware version. So if you are using firmware version 3.52, put the game and its contents in PSP/GAME352. With all that said, Mix The Cube! is a good take on an already existing concept, and programming-wise, the creator of the game seems to know what he’s doing. So I look forward to a likely improvement in the future.


Mac’s new web ad: Don’t Give Up on Vista

November 27, 2007

Yeah, another YouTube link so soon, but this one’s kinda out there. Apple has usually been known for its aggressive marketing, and it’s not slowing down with its latest addition to the Mac campaign. The following internet ad appears on the CNet’s own Windows Vista Page! Better yet (or worse, depending on your perspective), it cleverly uses the page’s own content and layout to make its point against its competitor.

This marketing tactic seems so wily, so inconsiderate…it could be described as “ehhhh…I don’t think that should be legal.” What’s next, political attack ads against presidential candidates on their own websites?

Hurry up dude, boss is coming in…

November 27, 2007

Thank you, marketing department for Westwood College, for providing us with hilarious source material to work with. Because without it, people wouldn’t be making gems like this one (This is probably NSFW…you have been warned!)

Can you believe they get jobs doing this?

The .obj file format, demystified

November 27, 2007

If you have ever thought of doing any 3D games programming, your first thought might be how the graphics are done. From the highly polished Final Fantasy games, to the abstract look of Geometry Wars, the answer varies. But more often than not, you would need to use visual assets that were made with other programs. For 3D modeling programs the formats widely vary, but out of all these, the .obj (or object) file format is the most generally accepted. Think of it like the PDF for 3D modelers. Most popular packages will support this format, so it’s easy to pass along without worring too much about what software others are using. The following text is an introduction for people that are not yet familiar with this format.

The .obj file format is one of the easiest to work with in programming 3D games, since .obj files are all text and the data is organized in a very straightforward manner. A typical .obj file would contain the following:

  • Vertex locations in x, y, and z coordinates
  • Texture mapping in u and v coordinates (optional)
  • Orientation of normals in x, y, and z coordinates (optional)
  • Face represented by a set of one or more indices

An .obj file can have either texture or normal data, but it must always carry vertex data. They are represented as an array of values, each line being a new entry in the array. This line starts with “v” followed by the coordinates. Optionally, you have lines for the vertex texture data (starts with “vt”) and vertex normals (starts with “vn”). Near the end of the file, the face data is represented, as a group of integers. Each line starts with “f”, and each number corresponds to the item on the data list in the order that it’s displayed. A line containing the numbers “1 4 3” correspond to the 1st, 4th and 3rd entries of that data group. There’s something important to note here: There is no index numbered “0”, so keep this in mind when parsing .obj files.

Each line contains indices for exactly one face, whether a triangle, quad, or other convex polygon. Furthermore, the indices can be grouped as single numbers, pairs, or triplets. The grouping depends on whether any texture or normal data is given. The following groups are possible:

"n n . . . n" - vertex location only
"n/n n/n . . . n/n" - location plus texture, or vertex plus normals
"n/n/n n/n/n . . . n/n/n" - location, texture, and normals

It should be clear that in a set of pairs or triplets, the location indices are listed first. Following that are the texture mapping coordinates and then the normal coordinates.

Finally, there might be some relevant information about grouping polygons into sets (lines starting with “g”) and usage of materials specified by the program that made the file (lines starting with “usemtl”). These may be used for programming model renderers, but they are not really crucial for displaying the geometry, so we won’t talk much about them here.

Well, that’s it for understanding the structure of .obj files. In a future post, I will show you how to apply this information to create your own .obj file parser.

What happened here, Epic?

November 23, 2007

Time to break from my development run for a bit.

UT Server stats

Unreal Tournament has been out for 3 days now, enough time to savor in some good sales of an anticipated game. Let’s put aside the fact that busiest shopping day is among us…these stats were even worse a day ago. The game has been well-received from most game critics, and Epic is excited about its push to consoles. So how come it’s not been doing so well, apparently, in sales and activity? This is coming from the company that brought us Gears of War, and that was a very different shooter and still very popular. Wait, that must be it. UT games have been mostly quick paced and less methodical than most FPS games. But if the last game was very successful, where has Epic gone wrong?

Aside from the fact that Unreal’s past console games were hit-or-miss, Epic seems to have lost its focus on what made its franchise popular. Unlike others like Halo and Super Smash Bros., Unreal Tournament seems to have pandered to the most hardcore of players, leaving the others in the dust. Most people that like UT3 also seem to prefer UT99, usually meaning they’ve been though it all. Unfortunately, what pleases the hardcore doesn’t fly for the rest of us. In fact, this is the plight that has faces most of the fighting game genre today. It made an impact on the Unreal community, I’m sure, but broke out quietly for everyone else.

So has Epic lost it? I’d say things seem bleak for the UT series, but not all is lost with the company. What seems to me is that, gaming-wise, they’re catering to both sides of the coin now, especially since Gears of War 2 is in the works. That, and the exciting announcement of the Unreal 3 engine being worked on for the Wii.

Wanted: A Good Mapmaker

November 22, 2007

No, I’m not making a post about looking for good game mapping talent (though that wouldn’t hurt), but what I am talking about is the need for a way to make maps for my upcoming quick reflexy action-puzzler. My game has finally come this far to crave this need. So it’s time to do some extensive gameplay bug testing, which would be far easier if I can make any sort of game levels without having to go back every time to code in some more polygons and re-compile. It will be my first time making a game level editor of any sort, since my past projects weren’t complex enough to really need one.

I can take two approaches:
– Script the levels with my own easy-to-read syntax in a text editor
– A fully graphical editor, with a GUI, that produces the files (either text or binary will do)

Whatever way I choose I’ll have to build the file parser first. The graphical editor is more exciting but will take some more time. I’ve looked into CEGUI as a possible solution to building a level editor, which will then take advantage of having everything rendered in OpenGL and it will blend with the game as well. I really don’t want to tinker with the obfuscated (in my opinion) Windows API to handle the interface.

So I’ve already downloaded CEGUI and hoping to play with it soon enough. If anyone has any more suggestions, I’d like to hear ’em!

Some graphical goodness

November 17, 2007

Here’s a scaled-down screenshot of how the game is looking on the PC side of things. Looking more like a Monkey Ball game, right?


Collision detection is still buggy on the edges and on angled surfaces, but angled surfaces need a different way to handle movement. But for flat surfaces the game looks totally playable, and that gives me enough progress to move on to working on the graphics a bit. So I’ll be handling that with OpenGL on the PC. Porting OpenGL functions to the PSP’s own GU graphics API would take more time, as there are some slight but important differences. Setting it up is not too different, but there are some things OpenGL does better than GU, and vice versa. I’d really like to see what visual effects the PSP is capable of.

I want to release this game on both the PC and PSP platforms, so eventually I would have to separate the platform-specific code from the game code. Using a flag to change macros before compile time sounds like the best choice for doing this, and cutting down on development time. This way I can use the same code for compiling both versions and all that would be needed to do is change one flag. It’s a lot better than updating two separate projects, and the separate compilers I use for each won’t really know the difference!

Other stuff along the way

November 13, 2007

While working on my PSP game, I’ve been thinking of continuing a few not-so-related projects.

First is PSPMyAdmin, which was supposed to be a tool to help you manage MySQL databases. Due to the lack of having a server on the PSP, the program uses SQL files and parses them to produce an image of the database structure. So it’s like editing an actual database, without the need to login or access a server. I’ve put this off a couple months ago but I could be returning to it, and use the Danzeff OSK with it. It would really cut down on time to make an interface for the program. I haven’t played with the source yet, but hopefully it should be easy to change its appearance to blend in with my program a bit more.

The next thing I’ve been working on is a simple OBJ parser. It’s based off the code from PSPMyAdmin so I got a head start there. Currently I’m working out some bugs with producing some vertex information, but it is almost done. This tool would actually be useful in helping others produce 3D homebrew games.

Code snippet – frame of collision

November 8, 2007

I whipped this little program in about an hour which helps you find the collision point of a circle to a line, and the normal in which it reflects. This principle works the same in 3D. You must have Java enabled in your browser to view the applet. The blue points connect the shortest distance between both lines, and the light blue circle shows the point of impact projected from the current path. Refreshing the applet makes a new random surface.

View applet

You can view the source files here: CircleLineCollision.pde Vert.pde
The code is written in Processing, but it’s easy to adapt to most common programming languages.

More game progress: Collision detection

November 4, 2007

Before we go on to the more tech-y stuff, a disclaimer: I like programming, but I’m an art major. My concentration is electronic media, and we do dabble in some programming in more arcane (but still easy to use) languages, and 3D modeling, but that’s as technical as my art classes get. But I took some Computer Science courses along the way, and it’s really helped me become more well-rounded in my skills. So while I’m formal source of good programming habits, I’m still learning.

Often I heard people saying that CS requires a lot of intense maths, and I thought it was just mostly logic-based. However, when I started working on the collision code for Monkey Ball Wannabe (working title 😉 ), that’s when the reliance on math in video game programming dawned on me. I tacked this problem blindly, and managed to find good tutorials and examples of code. Yet, I still have to understand a lot of the math involved even though I have some idea of what code does what.

Collision detection is a problem that must be handled in almost every action game, and in particular mine needs some realistic sphere-to-triangle collision. After getting advice from members at GameDev and, I found this document to be the best source for my needs. Anyone that wants to make sure their video game dude does not run through walls and move predictably when they slink along a wall, here you go. The sample code is so well-commented and easy to understand that I got it (almost) perfectly working in my program under an hour.

The only problem was with the edge-sphere test. If that code gets left alone, the rolling ball will probably “fall through the cracks”. Not what I want from a type of game that requires focus and good control. Once I get this fixed, I can get back to working on the controls.