Tag Archives: Thoughts

iPhone RPG UI

As per an earlier post, I mentioned that I planned to continue my design work on a cross-platform game targeting both iPhone, Mac, Windows and possibly other platforms. Since I didn’t really feel like doing any programming today, I started some mockups for potential GUIs that would fit the points I mentioned in the other post. These are just rough ideas, and there are already things I think I’d like to change, but they do have the desired feel that I’d like to achieve. They’re designed for an iPhone 4+, as the resolution is intended for the Retina Display at 640×960. The nice thing is that I feel the design will scale well onto laptops and desktops as well.

This is the default interface that would be displayed if nothing was going on in the game world:

A more active UI. The top text appears when an area is entered, the icons about the dragon indicate that information has not been gathered on it’s animal type yet, and the context menu indicates the user has touched/clicked a specific tree:

The white arrows on the side will eventually open up additional menus, such as a character sheet and chat. I haven’t work this bit out yet though.

Finally, the map is opened by touch/clicking the heading indicator at the top of the screen:

All other menus will probably have the same visual style as this one.

I tried the images out on the actual device and I was very happy with how they appear. They look extremely good on the Retina Display. The only change I would make at the moment for the non-mobile versions would be the removal of the arrows in favor of shortcut keys.

That’s all for now though!



Tomorrow I turn dumb

I’m getting my wisdom teeth taken out tomorrow. I was initially a bit apprehensive about the whole deal, in part because I’ve never had surgery, and because it sounds painful. Now I’m just more interested in getting it over with.

On the bright side though, I do plan to eat a lot of ice cream and milkshakes. The Marble Slab (ice cream chain) in town turned two this summer, so they ran a bunch of coupons in the newspaper and mail. There’s a deal on milkshakes, and a buy-2-get-1-free deal on buckets of ice cream. The freezer is already stocked. Apparently ice cream is great because it’s not only easy to eat, but also helps to reduce swelling and in general feels good on the gums.

Anyways, I’m off to take my prescribed pre-op Ibuprofen and head to bed. I’ll blog again whenever I feel up for it.


Cross-Platform Games

Games on mobile platforms like iPhone and Android are getting better by the day, and with each new hardware release the limit on graphics capabilities is being pushed further. One of the top PC game engines, Unreal Engine, can now run on mobile devices; it was used to create the visually stunning Infinity Blade released at the end of last year. I gave Infinity Blade a spin the other day and it got me thinking about whether or not it would be feasible to for Windows, Mac and mobile gamers to play the same game in the same game world. In essence, an MMO that can be accessed not only from a desktop computer but from an iPhone, Droid or BB. For the rest of this article I’m going to refer to that concept as a “cross-platform” game, assuming that one platform consists of all desktop/laptop OSs and the other consists of mobile platforms.

I have no doubts as far as technology goes. The hard part of the situation is designing the game itself. You can’t just port WoW or EVE to iPhone and call it a day, nor can you write a Windows version of Shadow Cities or Infinity Blade. Each platform has its own benefits and drawbacks as far as the user experience goes, and a game that mixes users from different platforms has accommodate them. Consequently, I’ve broken the problem down in 3 main areas of interest.

1. Menus/UI

This is not an insurmountable problem, but it is definitely one of the larger issues to deal with in the development of a cross-platform  game. Traditional MMOs on PC platforms typically have plenty of menus, such as character sheets, inventories and chat and often many of these are displayed at one time. On a mobile display with <10 square inches of screen space, this isn’t entirely practical.

I think the ideal system would be somewhat like an TES:Oblivion-style interface, where the majority of the screen defaults to displaying the game world unless a menu is opened. On the PC/Mac platform menus would be access with typical keyboard shortcuts, while on the phone they would “slide out” from the sides of the screen. Menus would of course have to be designed to be extremely concise, with the understanding that an iPhone user will most likely be interacting with a menu or the game world, but not both at the same time.

2. Client-World Interaction

In a classic FPS game the player changes the view with his/her mouse, moves with WASD, runs with Shift and interacts with objects with E. Unfortunately this sort of experience cannot be efficiently emulated on a mobile platform. It’s been tried through a variety of methods, such as rendering a small joysticks on the screen, but the results are typically difficult to use. The bottom line is that FPS controls will not work on mobile devices.

Because of this, I think the best route to go is by implementing a point-and-click move and interaction system. Touching a location in the game world would initiate a path finding process that takes the user to the closest possible point, while touching an intractable object would open a small context menu with relevant actions for that object. This can work with a mouse or with a touch screen device, and wouldn’t give either platform an advantage over the other.

3.  Game Content

Given that the iPhone has significantly fewer resources and graphical capabilities when compared with a high-end desktop machine, some downsizing of textures/models and removal of effects has to take place. The smaller screens on mobile devices mean that less polygons are needed, which is helpful, but at the end of the day the mobile version of cross-platform game will properly end up looking less detailed than its desktop equivalent. There are plenty of ways to combat this though, such as decreasing view distance in exchange for an increase in nearby polygon counts, so I don’t think it’s as big of a concern.

In conclusion, I should mention I have no intention to develop such a game at this time. It’s certainly something I’d like to do though eventually, so I plan to continue fleshing out my ideas. I’ll continue to post some of them here as well as I go. That’s all for now though!


Comments and Spacination

This will probably be the last article on style for a while, though there will be more at some point. I’m going to talk about two other aspects of code formatting that are almost as important to me as variable naming: comments and the way you space/tab your code. The latter will now be referred to as “spacination”, although Chrome tells me it’s not a real word. 😦

With the exception of small programs that have run-once use cases, e.g. Project Euler entries, I try to comment all my code. I’ve often heard “if it was hard to write, it should be hard to understand” as justification for leaving code unexplained, however this is in my opinion just shooting yourself in the foot. What if you come back later and need to change something? I always treat my code as if someone else is going to read/use/modify it at some point in time, regardless if that someone is me or not.

I’ve also gotten into the habit of writing Doxygen-compliant comments on all class, method and variable definitions, especially on larger projects. Doxygen is kinda like JavaDoc, in that it generates documentation from comments written directly in the source. It also provides inheritance trees, lists of constructors, members and pretty much everything you’d expect from such a tool. The rules are pretty flexible for creating these types of comments, as you can use either /// or /**  */ to catch the attention of the Doxygen tool. Some examples:

Regular comments, such as the ones describing the internals of a method, are of course the regular double slash. Even if you don’t use Doxygen, it’s still good practice to comment things. I find it makes for better code in the long run, at least for me.

The next one I’m a bit pickier about. I’m not sure why as I’m not really a neat person in everyday life, but when I write and read code my brain requires it to be spaced out in a very specific way. Maybe it’s because I learned Python first, where indentation was part of the syntax. Either way, I’m very picky about making things line up. There has to be clear levels of indentation, in tabsteps from the left hand margin. I also prefer to have curly braces ({}) on their own line, as opposed to at the end of a function or class definition. Example: 

Again, like the variable names, these are just personal preferences and not hard fast rules. I just find these conventions improve the quality and appearance of the code.


Top 5 Annoyances in Objective-C

I recently got into iOS programming after purchasing my first iPhone a few months ago (iPhone 4). As a result, I’ve also had to learn to use Xcode and Objective-C. Previously I’d only used Eclipse as my development IDE, since I only really did Java programming on the Mac. As neat as some of Objective-C’s features are, there are several things that bother me when using the language.


5. What’s up with the boolean type keywords? Why do you need YES, TRUE and true? Why not just stick with the standard true and false, instead of adding all these other ones? And they all mean the same thing, of course, because a boolean is a boolean. I guess the thinking behind it is that using YES might make the language feel more “Englishy”, but who knows. Same goes for having bool and BOOL, and nil and NULL. Just pick one and use it.

4. One of the things I disliked about Java was that the file name and the contents of the file had a definite link. If your file is called MyFile.java, the public class inside is required to be named MyFile. With C++, you’re not bound by any such rule and for the most part you aren’t with a Objective-C. Except, if you want to include C++ code in Objective-C, you have to change the file extension.What the hell?

3. Inconsistent/superfluous use of the ‘@’ symbol. Not only is the ‘@’ symbol used to denote an Objective-C String, it’s also prefixed to the interface, property, synthesize, etc keywords. And it’s also to denote the object replacement code for strings (“%@”). Now, I totally get the need for it on the strings, since something has to be used to distinguish between C-strings and Objective-C strings. This makes sense. The use as a replacement tag is also not that bad, and if the language designers had stopped there this item wouldn’t be on the list. But why use it on stuff like interface? In C++ you don’t say @class, and in Java there’s not an @class or @interface keyword. And, if sticking a random character on the front of keywords is so important, why not use the hash (#) sign? That at least shows some consistency. The preferred format would be to just get rid of the damn symbols though.

2. The lack of operator overloading. This kinda goes hand in hand with the next one, but this is definitely something I miss and I’m surprised is missing. There might be some language design reasons why this was not included, I don’t know, but it’s bothersome.

1. And lastly, where the hell is the string concatenation operator? This should be part of every language. I’m used to being able to do something like:

“My number is: ” + mSomeNum + ” and my name is: ” + mMyName;

in Java. Programmers stick strings together quite often, so it makes sense to have something short and sweet. Not to mention the fact that the ‘+’ sign universally translates to “add these things together.” However, in Objective-C we get to do this:

 [NSString stringWithFormat:@”%My number is: %i and my name is: %@”,mSomeNum,mMyName];

It makes understanding the block of code much harder, not to mention requires more typing and more linespace. It sucks a lot, and I cannot think of a good reason for forcing it on developers.


A Week With G+

I’ve had a Google+ account for a little over a week now, so I figure I’d share my first impressions about Google’s latest creation. I’m going to try to stay away from Google:Facebook comparisons for now and just stick with my opinions on G+.

Firstly, I should mention that I haven’t been able to give it a proper “social test” since I only have…4 friends on it. Most (read:99.5%) of the people I’ve gone to school with for the last two years have not joined. My invite and friends list came from some older friends. Maybe its time for some Facebook advertising to see who wants invites? But I digress. Here’s a link to a screenshot of my homepage to get thing started, and provide some reference:

Google+ Homepage

What I can say is I like the UI, a lot. The arrangement of the various components feels very intuitive and learning to navigate it took almost no time at all. It’s very easy to quickly access exactly what you want. Photos, profile, feeds from your friends and chat are all clearly labeled and only a single click away from the homepage. This is how it should be.

I’m particularly impressed with the system Google has designed for photos, and how these photos are accessed. With a single click on the G+ navigation bar, the user is presented with the following:

There’s no need to click through people’s profiles to get to photos, they’re just right there. You can, of course, access photos directly from profiles, but I can see the “overview” type photo layout being quite popular. It’s essentially a photo news feed, as it lists the photo albums in order of modification date. I like it.

On to Profiles and Circles. At a first glance the initial layout of the profile page is pretty familiar, in that it has a profile picture, friends, a name and then assorted content relating to that profile. The About page is very clean and minimalistic, which is pleasant. The rest is pretty standard though, of course in the G+ styled theme though. Circles, on the other hand, are a new and potentially very powerful addition to the social networking toolset. Circles are just what you’d think; they let you sort friends into arbitrary circles based on your relationship with them. Different circles can be given different access levels to your profile, see different posts, etc. As you might have noticed on the homepage screenshot, the feeds from various friends can also be sorted based on the circle they’re in. This is definitely one of the defining features of G+.

There are plenty of other features I haven’t tried, like video chat, Hangouts, Sparks, etc. Once I start to build up more friends on the site I’ll be able to go through in more detail on some of those.

All in all, what do I think? I think Google+ has the ability to shake things up a bit at least. It’s hard to say if it’ll take over the social networking scene though. The possibility is there for sure though.


What’s in a [variable] name?

Lots. As a programmer I learned very quickly that I’m one of those types of people that makes strict conventions and adheres to them whenever possible. Variable naming styles play a huge role in this. Before I delve into detail on my own style, how about a few comments on some of the general variable naming conventions that are out there today?

Variable naming conventions actually have two components to them: the “formatting convention”, and then the actual naming convention itself. The formatting convention mainly deals with how the name is presented, such as the case, any additional punctuation like underscores, etc. The naming portion of the equation is how the programmer selects what to call the variable. Pretty simple.

Formatting is definitely the most straightforward to talk about, as there really isn’t a whole lot you can do in that department. The most popular style seems to be camel case, e.g. “myVariable”, “myByteBuffer” and “someUselessObject.” Camel case is easy on the eyes for variables that are constructed from multiple words, allowing for variablesWithLongerNames to still be readable. It also seems to emphasize the parts of the variable with capitals, which are also generally the more important part, i.e “ByteBuffer” in “myByteBuffer.” The other popular alternative involves the use of underscores to separate parts of the variable. Rewriting the previous variables in this underscore style would give “my_variable”, “my_byte_buffer” and “some_useless_object.” Allow I suppose you could do a hybrid, something like “my_ByteBuffer” or “my_Byte_Buffer”, most people seem to go one way or the other. I’ve also seen underscores prefixed on variables, like “_byteBuffer”. I’m not really sure what this accomplishes though. In fact I personally think the underscores look atrocious, but for the sake of variety will continue to use them for one more paragraph.

On to the names themselves. These can’t really be divided up as easily, as there are lots of different ways to go about the task. One convention I’ve seen pretty often is including a letter or two to indicate type for standard type variables, like “fSpeed”,”bRun”, or “ch_initial.” For arrays and lists it’s uncommon to see “scoreList” or “item_array.” It definitely makes it clear what the variable in question is. Another convention is to include the variables scope in the name. A class member might be named “mTimeStamp”, while a variable passed in as a parameter might be  “p_rate”. There are clearly lots of ways to tackle the problem of names, but as long as the name makes sense in the context is really just a matter of preference.

What about me? Well, as I may have hinted before I’m a big proponent of the camel case style formatting convention. All of my code uses it all of the time, local variables included. I’m also equally picky about my var names. All variables are named based on scope/location, as mentioned above. Global variables get the “g” prefix, members get an “m”, parameters a “p”, enums an “e” and so on. As far as the rest of the variable name goes, I always follow three simple rules:

1. Keep it as short as possible. Make sure that the name is only as long as it has to be in the context that its given. “mTextFileArray” can be shortened to “mFileArray” if it’s used in the “TextFileManager” class, for example.

2. Name it after its purpose. This is the most important rule, in my opinion. Lets say we’ve got a “Weapon” class. The name “mCount” as member variables leaves a lot of questions, as it there are a variety of things that could be counted. “mAmmoCount”, “mClipCount”, or “mFireCount” are much better. Of course, as per rule #1, in the case of “void setAmmoCount( int pCount )” pCount works just fine since the context implies ammo.

3. Name the type if it could be ambiguous. For things like floats/doubles, or ints/shorts/longs this isn’t something I do. Its more in the case of something like “mItems”, where the better option would be “mItemsList” if it’s a linked list, “mItemsPtr” if its a pointer to an array, etc. This rule definitely has more flex to it than the others, and is kinda on a per-case basis.

The bottom line is, I do my best to make sure I don’t have “int temp” or “float testvar” in my code. In situations where I’m trying to pound out a big piece of program quickly I will occasionally let the style go, but this just creates more cleanup work later so I’ve found its best to get it right the first time.

And, by no means are these rules the “right” ones to follow. I’m a self-taught programmer so I probably do some quirky thing, naming conventions included. Like I said before it’s really all a matter of personal preference. Unless you’re doing work for someone else and they enforce code conventions, finding something that works for you is just another part of learning to program.


%d bloggers like this: