Archive for the Projects Category

This is the second article in a series on Game Project Management. In the last article, First Project – 2D Map Editor In Cocoa for Mac OS X, I went over the steps that will be required to complete my first game development project for the site. In this post, I’ll be talking about the design of my Map Editor.

I’m pretty old school when it comes to design and I tend to use pen/pencil and paper to get my ideas down. I find that this is much more effective than me staring a blank computer screen. There is something about the handwritten aspect of journaling my ideas that I enjoy. It also allows me to do lots of drawing, which you’ll see in the design documents in this post. The first step was coming up with a bullet point list of the must haves for my projects:

Map Editor Design Requirements

These are the initial design requirements from my brainstorming session on the Map Editor.

In this initial session, I quickly determined that I wanted to use a Hex Map in the design of my tile based game engine. Hex maps have been around since the 1950s and provide the advantage of being able to move in six directions instead of four, with each direction being equal distance from each other. It also allows artists to more easily give the illusion of 3D and perspective using a 3/4 overhead view. I was very interested in how I would be able to create tile groups to allow me to connect together objects on a map. I did some initial drawings to confirm that this was the map scheme I wanted to use:

Testing Hex Map Design

These are the initial tests for a hex map design structure.

My trial design looked good, so now I needed to get a better idea of how many sides would be connected for each size. This is difficult because the size doesn’t necessarily determine the number of sides, the shape does. I decided to make a comprehensive list of the small size tile groups that I would be using in my project:

Small Size Hex Map Tile Groups

A list of some example hex map tile groups that can be generated.

This was an excellent visual representation for me and showed me some of the numerical aspects (size and sides) for each tile group. Now that I had a visual list, I wanted to get a graphical representation of the small size tile groups for sizes one through four:

Comprehensive Tile Group List - Small Size

A comprehensive list of all tile groups of size one through four.

At this point, I was happy with my tile group designs and figured I’d be able to extend the design to any additional required functionality that I might need. The next step was determining the size of the map, as well as the resolution. I didn’t know much about the resolutions for mobile devices, but this article on iPhone screen resolutions and dpi was a great resource. I learned that I’m going to need to build my app to be 320×480 (or in my case 480×320 since I plan on running in a fixed horizontal mode). The problem is that the iPhone 4/4S run at 640×960 and Android runs at 480×720. The solution seems to be the API I plan on using to develop the game – Corona. This API lets you create games in Lua and port them to iPhone, Android, Kindle Fire, and Nook. Exactly what I’m looking for! Not only that, they already have built in support for running games at multiple resolutions using custom higher resolution image filenames.

Now that I knew what resolution I was working with, I needed to determine the size of a single tile. For this, I started drawing up some designs:

Screen Resolution Requirements

These are the requirements for the screen resolution designs.

I came up with a decent design that would tile together at 14×11 pixels, but I wasn’t happy with the overall size. I wanted to have a smaller base tile, ideally as small as I could possibly get. I kept iterating on the basic tile pixel design:

Pixel Based Hex Map Design

These are the designs for the size of the basic tile in pixels for our hex map.

I came across a page with 33×27 pixel hex map design that looked promising, however it looked a little jagged and was too big. In the end, it seemed like just two of my design prototypes were viable: 4×4 and 8×8 crosses that stitched together nicely but gave me the hex map design I wanted. I opted to use the 4×4 tile map because it was the smallest size that would work (3×3 cross overlaps).

Now that I had the size of the basic tile, I had to determine the size of the map. In this case, I wanted to use 2/3 of the screen for the map – creating a square 320×320 presentation area. This can easily be broken down into 80 tiles; however, because of the cross structure, the corners need an additional two tiles to cover them, leaving an 82×82 tile map. This will be my proof of concept – 82×82 one screen. From there, I’d like to create sizes up to 10×10 screens or 820×820 tiles. Making the map size rectangular will allow for narrow vertical or long horizontal maps. My designs for the map sizes are below:

Map Editor Design Specification

This is the final set of design specifications for the Map Editor: including screen, map, and tile sizes.

The last component of the Map Editor design to be worked out is the actual app itself. The layout of the app is important because I need to be able to achieve a variety of tasks from the same basic user interface design. I came up with the following:

Map Editor Layout Specification

This is the screen layout specification for the Map Editor app.

The content pane is where you will be able to see a visual representation of whatever tab is currently selected. The info panel is where you can adjust settings for the selected tab and view your results in the content page. Pretty simple design since I’m a beginner with Cocoa.

There you have it – the complete Map Editor design documents and process. I hope this was helpful and you’ll continue to track my progress in the next article for the Game Project Management Series: Part Two – Research the Cocoa API.

This is the first article in a series on Game Project Management.  I’ve been working on the design concepts for a strategy/simulation game and finally decided on the goals for my first project for the site:

  1. Design a Map Editor – I’ve always been interested in procedurally generated maps – they allow for limitless content and can work well if they don’t seem formula or break because of the game mechanics.  To that end, I’d like to develop a Map Editor that I can use to create map packages that describe how a map should be generated and what resources to use to represent it in a game world.  The first step in any type of coding project is creating a solid design so that I understand the full specifications ahead of doing any actual programming.
  2. Research the Cocoa API – I’m no pro when it comes to Cocoa programming.  In fact, the only experience I have with it is some prototypes that I created for a travel app I was building for the iPhone.  I have a general idea of what types of objects I’ll need to use, but once I finish the design I’ll be able to fully research the libraries that I need to use to create my app.
  3. Brush up on Objective-C – the whole messaging component seemed to be the core way to control things from what I remember; however, I’ll definintely need to re-read Learning Objective-C: A Primer to brush up on my knowledge of how the basic functionality of the language works.
  4. Create a Roadmap with Milestones – it’s important to be able to track your progress and make consistent steady steps to your goal functionality.  I plan on creating a roadmap to detail what features will be added to the Map Editor and a set of milestones with due dates to track my progress.
  5. Program the App and Implement Core Features – once I’ve set up my milestones for the project, it’s time to get down to the business of actually coding the features.  It’s important to focus on core functionality first – hopefully I’ve set up my roadmap properly to focus on the important functions first so that I can get to the next, very important step in the development chain.
  6. QA to Test for Bugs and Design Issues – when I say QA here, I’m referring to Quality Assurance.  That is the department in a company that is responsible for making sure that the product you put out meets all customer expectations and works as it is intended.  This is a crucially important part of the process and is often underemphasized by programmers who tend to enjoy designing cool things and coding them – but can’t be bothered with actually testing their own products to see whether they work and more importantly actually are cool.  It’s easy to fall into this pit and I do myself often.  Thankfully I have an A+ QA team that I work with at my full-time job.  Unfortunately, that means I’m going to have to step up my game on this step a lot.
  7. Iterate on the App Until it is Feature Complete – steps four and five get repeated again and again until the app finally reaches the point where it has all of the functionality required for a release.  At this point, I will have reached my goal of creating a Mac OS X Cocoa App tool to assist in my game development.
I mentioned before that the reason I’m trying to create a Map Editor is because I’d like to use if to a strategy/simulation game that I’m working on.  This tool could actually be adapted and used for another game that I’m working on the concept for as well.  Because of that, I’m going to make sure to make the code as extensible as possible – the reason I’m going to make the code extensible rather than try to create one app to handle both games is that it’s better design.  Why better you ask?  Well, by keeping each app as lightweight as possible, I can focus on making each Map Editor work well for each specific project.  At the same time, by making the code components modular, I can extend as much of the functionality as I want across the different apps.  At least that is the plan.
The next article I will be writing will be to go over the design of the Map Editor.  I’m going to try and post as much content that is pertinent to it as possible, including: design drawings and related documents.  I’m not exactly sure what the timeframe for the next article is, but I’d like to have it up in the next week or so.  Until next time.