I'm making a (mobile) game - Part 3!

Well, it's been a while since my last entry. Almost 2 weeks ( wow, time flies ).. but I've gotten a lot of work done!

Let's continue from the last post: After creating the rooms, I added in road creation. I ended up writing a algorithm that always seeks the center of a room. Additionally, every room except the first and the last try to connect twice. The result is a map that, in my opinion looks pretty good and still maintains that every room is accessible.

After that came the big - nay, the HUGE thing: Graphics. Now, it being a roguelike, it certainly doesn't require much graphical prowess, but still, I don't think a text-only roguelike would find much audience in a mobile store.

Now, implementing the graphics was rather challenging. For one, I'm not too experienced with Flex, for two, performance is a big concern: Displaying the whole map ( sized at 80 x 24 ) would mean that it needs to display a whole 1920 pictures at once. This shot the memory usage through the roof and simply was not feasible.

So - cropping it to the viewport was the next step. But there were problems with that as well: the images that get dynamically loaded in would flicker. Not a pretty sight.

I ended up doing several things:

1) I embedded all images into the SWF file, greatly reducing access time and memory usage when displaying the images

2) I am loading a few more cells than can be fit on the screen: 2 extra rows and 2 extra columns.

3) I am using a mask that hides the extra rows and columns.

What this means is that as the character moves, the preloaded row or column is pushed into view, and a new row / column is being loaded off-screen - while on the opposite site a column is discarded. This is essentially a buffer and makes it so that all loading simply happens out of the player's view.

The result is a nice and low memory usage, no flickering or hiccuping - I am quite pleased.

The tileset I am using for my game ( for now ) are from Danc's Miraculously Flexible Game Prototyping Tiles

Next I worked on a option screen, and permanently storing information. For this purpose I am using a SQLite wrapper. ( I can't help it! I love databases for storing and accessing data!! )

The process was fairly easy in general and the implementation is working like a charm. Currently, you can (independently) select animation speeds for map & unit movement, as well as whether you'd like to view the game in tile or in ascii view by default.

I've also made the active game data more persistent - you can open up the options screen mid-game without it loosing anything when going back to the game.

Then I worked on coming up with a way to dynamically load data. If you recall, one of the goals I set forth was "Load most game data via XML files, for easy editing & modding.", so that's exactly what I did.

It took me surprisingly long to come up with a smooth way of loading data via XML, but I managed to do it ( can't help it - I'm awesome )

I have preset models for each loader ( currently I have a terrain loader and a monster loader ), and am using the Parsley framework to create objects out of the XML files.

One thing I'm a bit "meh" about is that, for obvious reasons, it's impossible to dynamically embed images, so the images in use will always have to be hardcoded. But oh well, performance is important for mobile devices so that's the way it has to be.

Now.. today I've been working on adding monsters. Setting up the basic xml data loader was easy as I could largely copy & paste the terrain implementation, populating the map and displaying it in ASCII was also rather easy.. but displaying it on the tileset, now that was a challenge.

You see, I only have a single group for all images - background tiles, the hero's sprite and all monsters. Due to how often these images are used, I can't afford to add too much information to the custom image class I am using. In short: Dynamically loading monsters in and out as they come into the player's view was a challenge involving around 10 hours of non-stop coding, trial and error, and oh god so much debugging. But I finally got it to work ( I hope... :P but so far all tests succeeded ).

Obligatory screenshot ( this time, comparison! )

Same scene - once with the tiles, once in ASCII !

Starting to look like a game, eh ?

Goal for tomorrow is to get a basic combat engine going ( walking into enemy = attack it ), followed by getting a basic enemy AI going ( enemies walk when player moves ).

40 days left on my Flash Builder trial.


I'm making a (mobile) game - Part 2!

Progress! That is probably one of my favorite words, along with optimize and auspicious.

Today I have worked on a number of things:

The map size is now variable and when drawing the map on the screen, it is cropped to the size of a iPhone 3 screen. It also follows the hero around, so that you are always in the center of the screen. When you get close to the edge of the map, the view will stop moving with your hero, so that you always see as much as possible of the map. ( Screen space is very important on a mobile device, so making the most out of it = good ).

Later on, I will have to dynamically determine what resolution the user's device is running and scaling the view based on that, but for now the iPhone 3 size is working fine for testing!

The other big thing is - as mentioned in my previous blog, the procedural map generation. It prooved to be pretty challenging, but since I managed to get it done in a day I probably can't complain too much.

Now, I know there are a bunch of premade algorithms for this out there, and they may be more effective or efficient than mine, but for the sake of learning and growing chest hairs ( which naturally is the most important aspect about making your own game ), I wrote my own. It's not entirely finished in that for now, it does not connect the rooms it creates with tunnels, but I'm very pleased with my progress as arguably the room generation aspect is more challenging and important.

What I actually did was split up the whole map into sectors / quadrants. The map size I settled on for now is 80 wide, 24 tall. Each sector has a size of 3x3.

There is a fixed number of rooms it tries to create ( 8 , currently ), with randomly generated width and height ( smallest is 3x3, largest is 8x8 ). It will pick a random sector, try to fit the room in there ( it moves the room around if it would leave the map's boundaries ), and then audits all sectors that it would need to occupy whether something else is already occupying the sector. If everything checks out, it marks the sectors as occupied and places the room.

Obligatory picture:

So that's another important part of the game half-working. Again, my focus is to get to a playable state ASAP and work from there.

Also, thanks for the suggestion, Murdouken. I have bookmarked the links!

I probably won't use it in this project, but once I am done with this I will definitely look into it and see if I like it better.

Well, that's all for today. Next up is creating roads between the rooms. Once that's done, I can add some basic monsters and get started on the fun stuff.

Once it becomes more of a game, would anyone be willing to help test if I were to upload it on my webserver?


I'm making a (mobile) game!

Well, here it is. My first blog post in what will hopefully become a series, describing both my pains and my joys as I work on my game.

I have programmed for over 5 years, mostly a mix between Web ( PHP, MySQL, HTML, CSS, javascript, jQuery ) and C ( with some C# thrown in here and there ) and I would say that I'm a good programmer. I do however lack experience when it comes to Object-Oriented Programming - but I'm sure that will change as this series progresses.

Now then - the game! It is of yet untitled, though I named my project SmartRPG for no particular reason.

I have decided to make my first game a roguelike. In the vein of Dungeons of Dredmore, nethack and - especially - ADOM. ADOM has a wonderful thing called the infinity dungeon, and that is the general idea that I want to bring onto a mobile device.

It is a dungeon in which every level is randomly generated when you enter it - including levels that you have been to previously. And it honestly is my favorite part about ADOM.

My goals for this game:

- Randomly generate each level of the dungeon, and populate it with loot, monsters, traps etc. Levels get progressively harder.

- Create and maintain online leaderboards. Data is submitted upon death and can be filtered by lifetime, weekly & daily.

- Load most game data via XML files, for easy editing & modding.

- Compatible with iPhone, iPad, Android

For the development platform, I chose Adobe Flash Builder 4.6 Premium. I do not have the license, nor do I have the money to buy it, so I will have to finish this game within 54 days.

Flash Builder fills the goal of cross-platform compatibily. It can release to both iOS and Android, and provides me with the ability to preview my game on all sorts of different devices as I work on it. Nifty!

But enough of that, Here is where I stand:

I've taught myself the basics of using ActionScript and Spark, and I have successfully created the Main Menu ( currently only with a "Start" button ), the prestigious "Name Thyself" screen, in which you enter your hero's name. I will later expand this with class selection, and may add another page for perks and such. And, the most important part, the main game screen.

The main game screen is where Flex became... problematic. All forms of data output that I tried had a lot of issues attached to it. DataGrid would insist on spacing each text element like, 14 pixels apart, even after attempting to use a custom renderer and skin. Attempts to set it lower than 14 pixels would cause it to not display anything. I tried TileSet, but again, weird spacing. I tried just using a label, but then it becomes impossible to color individual characters...

I ended up using a RichTextField that has selecting and editing turned off. It blends in fairly nicely, spacing is ideal and I can color elements ! Wooo !

I then, after finally getting the mapdisplay right, added some basic movement controls. It checks whether the target cell is walkable, and if yes, moves the hero, who is a part of the unit class to the desired cell. I'm really beginning to like classes. I have a class called unit, of which the hero is a instance of, a class called Cell, which holds information about a single cell in the grid (x, y, walkable) and a class called map, which has basic map information ( level ) as well as holds the 2d array of Cells which make up the map.

Finally, a screenshot to show the work in progress (testing on a iPhone):

# Denotes a solid rock wall

. Donates a empty section of floor that can be walked over

@ Denotes our Hero

Tomorrow, I am hoping to work on a map generator. I am planning on defining a few pre-made rooms, and then having the program generate hallways that lead to the generated rooms.

Feedback and comments are very welcome. Let me know if you are interested in any actual code samples, or have any questions.