ApathyWorks

Development Diaries, Volume 13

Posted by Alex Jordan on

I wasn't kidding when I said I was going to have a Development Diary in the "imminent future", was I?

Above, you finally get a taste of the gameplay I'm going for. With four random locations that you can choose to either answer or ignore, the player will have to juggle these options in his or her head while deciding where to move the Selector. There's also the difficulty factor: on the Pie Wheel at the bottom, Red means Hard, Yellow means Intermediate, and Green means Easy. Beyond that, there's also the accuracy with which the player must place the Selector, with different multipliers awarded for how close you can get to the city in question.

As far as things stand under the hood, this video shows off several features that I've been working diligently on. Although I've posted screenshots and videos with a rudimentary Heads Up Display (HUD) in place, this one shows most of the HUD in action, as well as the animation system I set up for choosing a location. The HUD is still incomplete, as I have yet to include the score bar or the Timer that will force players to race against the clock. Those will be added in the near future.

The video is right there for reference, but here are the specifics: You pick one of the four locations, move your Selector, and hit the corresponding face button the Xbox 360 controller. The bullseye shows up to give you the gradient on which your accuracy will be judged. Then, the green arrow drops down to show where the actual location is. The game scores you on where in the bullseye that arrow drops, assigns you a multiplier (or doesn't, if you suck), and awards you some points. Hooray! Away goes the bullseye, away goes the arrow, and a new location slides in for your next question. And you can seek out these locations as fast as you want, in whatever order you want.

While the cosmetics of the HUD and its animation system are in place, the actual data structure behind it is nowhere near ready. Watch how towards the end of the video, I don't even bother to accurately select the locations I'm given. Note how the green arrow always drops at the dead center of the bullseye, and that the message is always "Great!" with an award of 5,000 points. That occurs because the scoring framework isn't in place yet. And that framework isn't in place because I don't have geospatial positioning data for all my locations yet. And I don't have that because I'm still manually building a list of locations. I've covered North America, Central America, Europe, Russia, and some of Africa, but there's still much more to do.

However, despite the fact that I haven't generated the needed geospatial data yet, I do have an (incomplete!) list of locations. In my spare time, I've been staring at maps, randomly entering cities and countries into a Google Docs spreadsheet. Knowing that I wanted to make another video for the blog, I imported my incomplete list into Microsoft Access and generated a database. I then exported that database into XML format, which I briefly mentioned yesterday. XML means "Extensible Markup Language", and it's a flexible, all-purpose formatting system that allows users to store any number of data types in any number of ways. That makes it ideally suited for XNA development, and XNA has many useful features for reading and writing XML files.

I read up on a few XML tutorials, but this one proved to be really useful, as I only needed to do ad-hoc XML reading at this point in Around The World's development. My game now reads all of the city, country, and difficulty level data from my XML file, although all the X, Y, and Z coordinates (for storing my geospatial data) remain 0s until I can get to work on them.

So, what's next? Well, I need to finish my location list. Sub-Saharan Africa, the Middle East, Asia, and Oceania all remain, which is a lot of places that need to be added. Fortunately, I work quickly. Once the list is complete, I'll again bounce it from Google Docs to Access, to XML, to my game. At that point, I'll have to abandon the ad-hoc XML reader method described above and generate an honest-to-God "content writer" for my game. This means that my game will be able to write its own XML files. And why do I need that?

Because I need to manually enter in all the proper location coordinates in the game itself. Which, assuming the final list will have more than a thousand locations, will be horrible. I'll have a debug feature in my game read me each location, in order, and I'll move the Selector myself, hit a button to write the Selector's position into the location's geospatial data, and save it as an external XML file for later usage. I anticipate this being tedious as all hell.

Is there an easier way to do it? Well, all the imagery data is in a projection format called "Equirectangular Projection", instead of Mercator or whatever else one might use. Latitude and Longitude data for just about every city ever is readily available online, and I'll look and see if there's a handy method for adjusting that data for Equirectangular Projection. But then there's the matter of taking the Latitude and Longitude and converting it into an X and Y coordinate (the Z coordinate will always be 0, since it's a flat map). That will be horrendously tricky, as the visuals of my game have been really, really tampered with. First, I had to convert the Equirectangular Projection map into a texture size that's friendly to video cards. Then, I had to paste that texture onto a 3D model that has its own specific size. Then, I have to render that 3D model in a way that's a specific distance away from the camera (the point of visual reference in a 3D game). I'm not sure what all these adjustments would do to otherwise-pristine Latitudinal and Longitudinal data. Then, there's the fact that I'd still have to manually enter all the Latitudes and Longitudes into my spreadsheet/XML database. So, bear with me when I think that, however obnoxious it will be to consult a map and manually do all this work in-game, acquiring and converting all the Latitudes and Longitudes to work in 3D might prove to be infinitely worse. Or, flat-out impossible.

But we'll see, won't we? It also might be time to distract myself with something more straightforward, like finally adding sound and music to the game. Stay tuned!