Game Development

It’s little over a month since I said I wouldn’t do any more porting for Vizati. Lesson learned, don’t say never again… When I started making the engine in C++ with an OpenGL/DirectX layer, I tried to keep in mind a multi-platform environment. Keeping rendering and OS specific calls abstract from the game itself and the engine to a certain level was one of my goals. Easy to say, hard to accomplish. Anyway the engine already supports Windows, iPhone and iPad. ...

It’s been awhile since my last post. Regular visitors know that for the last months I’ve been working mainly on Vizati, bringing it first from the Xbox360 (never released, no xblig here) to a PC digital release, followed by a complete rewrite of the engine to C++/OpenGL for a iPhone port, next there was the Windows Phone 7 version. I had the iPad on a backburner since I don’t own a device and optimizing code without seeing the result is crappy but about 2 weeks ago it went gold and it’s finished. ...

I’ve been playing with polygons and collisions lately so I decided to share some stuff. Using rectangles to detect if the mouse is inside is handy for Buttons and rectangular shaped objects, but what about other irregular shaped objects? Taking this into account I decided to create a Polygon class that basically has a List of Vector3 points. Although I’m just covering 2D collision you should use Vector3 for a more generic class. ...

For my current project I’ve been working with A* as a path-finding solution. Basically it’s a way to get from point A to point B. This is used for AI in games mostly on tiled based games, It’s very simple to understand and implement. As A* traverses the graph, it follows a path of the lowest known cost, keeping a sorted priority queue of alternate path segments along the way. If, at any point, a segment of the path being traversed has a higher cost than another encountered path segment, it abandons the higher-cost path segment and traverses the lower-cost path segment instead. This process continues until the goal is reached. ...

If you read my recent posts you know I’ve been bringing Basalt to C++. The plan is to support both DirectX and OpenGL render API’s and OpenGLES for iOS devices. I’m tired of porting stuff so I want to make a better framework for future projects and I’ll leave the XNA branch for Xbox360 and Windows Phone 7. I really wished I had this before. Since the iPhone branch is stable I move on to making it compatible with Win32 and MacOSX. ...

People who follow me on twitter are probably aware, or maybe not: After 3 months tacking an iPhone port it was finally approved by Apple to the App store and it’s on sale today!!! Hypnotizing start… Buy buy buy…. On the count of 3 you will feel refreshed and happy for buying this awesome game… 1 2 3 Oh right, here’s the trailer: I’ve searched some forums and found some talking about it and that they liked, general feedback looks positive. It’s great that people have fun with out little game. If everything goes as planned a version 1.1 with retina support a few other improvements. ...

Since Windows Phone 7 doesn’t have multitask, at least for now, Microsoft implemented a Tombstone notion in WP7 apps. It’s basically a suspended state where you receive a notification that it’s going to suspend but there is no guarantee that it will resume, it might be terminated so you must treat this as an exit and a might start again state. So depending on you app you might want to save the current state just in case the app really closes. ...

Finally and after several weeks locked inside Different Pixel “dungeon” making my engine compatible with iOS, namely with iPhone/iPod touch I submitted today my first App to the Apple Store. The binary didn’t reported any issues so as of 15 September 2010 it’s “Waiting For Review” I have mixed feelings about either it’s going to be approved or rejected. On one hand we tested as much as we could, handed to some testers using iPhone 3, iPhone 4 and iPod touches. The only issues reported were usability or with game logic itself. No one reported any crashes, so I’m a little reassured on that part. On the other hand I’ve heard and read some major horror stories surrounding the submission process. Crashes that you can’t reproduce, people resubmitting same build again after failure being accepted, meaning that something is wrong there. Right now it’s a shot in the dark… ...

When loading an application on an iPhone or iPad, a launch image can be shown to provide feedback to the user that the application is loading. On the iPhone a Default.png was used, with the iPad we need to anticipate the device being started in any orientation. Filename Dimensions Default-Portrait.png * 768w x 1024h Default-PortraitUpsideDown.png 768w x 1024h Default-Landscape.png ** 1024w x 768h Default-LandscapeLeft.png 1024w x 768h Default-LandscapeRight.png 1024w x 768h Default.png Not recommended * If you have not specified a Default-PortraitUpsideDown.png file, this file will take precedence. ...

This had me scratching my head for awhile. At first I thought that glGetRenderbufferParameterivOES would properly detect Retina screen at 960×640 but it keeps returning 480×320. A little explanation on Retina screen first. Older devices have 320×480 screen resolution. With new iPhone 4 and iPod Touch 4G the screen has 640×960 but on the same physical area. This means that each pixel is 4 times as small. To properly simulate older games resolutions iOS will replace each of your 320×480 game pixel by 4, this way your game will look identical. ...