What happened here, Epic?

Time to break from my development run for a bit.

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

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

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

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

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

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 psp-programming.com, 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.

Keeping the ball rolling with this game

For my first Monkey Ball clone update, here’s a screenshot of what’s coming up so far. Last week I’ve tested some textures and using my own state manager display to handle the switching between parts of the game. That would be put aside until much later. And for obvious reasons, I won’t actually be using the monkeys in the game.

Right now I have to work on the controls. Using the PSP’s single joystick makes sense for tilting the level in this game, and already took care of the “dead zone” in the middle. I’m still not set at the maximum angles in which it should tilt, though. The camera would have to be just far enough so that the floor won’t completely obscure the player’s view. Using the camera to point where I want it to was easier than I thought.

As a test for the bounce, I have the ball falling from a great height to the floor and having the camera rotate to follow it. That worked pretty well. The actual tilt doesn’t move the ball, though. For debugging purposes, the ball is moved with the D-pad around a fixed camera. This creates a movement area where the player can circumnavigate with Left or Right, the preferred control scheme for a fixed camera. In practice, the camera would be following the moving ball as the floor is tilted. But more on how that will work for another day. Next on the list, polygonal collision detection. Hope you like math…

First post of a development log.

For over a year I’ve been an active member of the PSP homebrew community and just now hoping to make a significant release sometime in the future. I’ve programmed some simple utility software but now it’s time to aim bigger. Development for 3D homebrew is slowly growing and I want to make my contribution with a game. So this is the first time I will publicly announce it will be a Super Monkey Ball-style game, in full 3D of course. My reasons for this choice are that it’s not too broad and ambitious like so many RPG projects out there, and it doesn’t demand a lot of creative assets (like storyline, characters, etc) meaning I won’t have much to distract me from working on the gameplay.

However, making a Monkey Ball clone is harder than once thought, mostly because of its deceptively simple gameplay. Simply put, the whole game revolves around physics. Good ol’ physics that need some time to work out the nasty math stuff. So right away I knew physics would be the first (and possibly biggest) technical hurdle I must encounter, and this is the area I’m currently working on. Burying myself under a lot of code and examples, this is definitely a new area for me to work with, but it will be a nice learning process. Currently I’m doing everything on the PC so I can progress faster, and the physics code itself should be easy to port to the PSP since there are virtually no dependencies.

This is something I want to be in for the long haul and I want this to be one of the best PSP homebrew out there (there will be a PC version too). So I’ll keep you posted on the progress, and many posts will vary from the purely technical to the broad and wide-reaching. Perhaps, through my steps in figuring things out, I hope that others might find this information useful as well.

Sonic for SSBB confirmed – Official German site

Well, all speculations about Sonic being in Smash Bros. Brawl are put to rest- the blue blur will make his debut in Nintendo’s popular fighting series! As of this posting, the American English site has not listed this bit of news yet- it was found in the German version of the site. Maybe the maintainers of the site are working on it, or maybe this news is supposed to be only present for October 10, since the US is just starting on that day. Whatever the case may be, with Sonic and Snake as newcomers, a lot of big third-party characters are fair game now. LET US THROW OPEN THE FLOOR TO WILD ACCUSATIONS!!

Ahem. From the video, looks like Sonic is a bit too fast for his own good. Yeah, it’s Sonic the Hedgehog. But everything about him, not just his running, goes at a rapid pace. His punches, jumps, kicks- he might just give Sheik and Ganondorf a run for their money. Holy unbalanced fighting, Batman! But wait- maybe his attacks might be toned down damage-wise, as well as be less tolerant of taking damage from others. The video also hints at a Super Sonic starring along. Maybe as a hard-to-get unlockable character?

The best (free!) puzzle game for PSP.

Hexaxis XXI is a puzzle game that started life on the PC and has been ported successfully to the PSP. Developer Darksoft has just released a new update for the homebrew title (version 8), and it’s almost as good as the big screen version. Look familiar to some of you? Yes, it’s based off of Devil Dice and the more recent Bombastic, but with Hexaxis you can get it for the low, low price of free. However, it’s not a total copycat. Hexaxis has added a few twists- most noticeably, the playing field is tilted vertically and feels a bit like Tetris. While in Devil Dice you can move the dice in any direction, here the dice fall from the top, moving them left or right before they reach the end. The game’s presentation is very polished for a PSP homebrew title, including some pro-sounding music as well as a 3D interface. If you have a homebrew-ready PSP (this won’t work on official Sony firmware), this game is a great addition for any puzzle enthusiast.