Class Wars

After a few days, Simple Game is well underway. I've been tackling some programming challenges and met with some working results.

First off was writing some collision detection to keep a marble inside a given path. This was more tricky than I first thought, with the marble getting stuck and so on - usual collision detection type bugs. It's working in a basic fashion now - following the correct path, not getting stuck etc.

Today, I spent a while on some particle effects. Specifically, creating an explosion effect by dicing up a sprite into a load of pieces. Previously I'd only ever used little square or lines to create the effect of something exploding. As my sprites are mostly simple squares at the moment, you don't get the best result but it does work as intended. Functionality needs expanding to be more flexible and allow for multiple explosions.

Code-wise, I'm still somewhat baffled by how exactly to use classes "on the fly". Right now, I've created everything at the started and am managing classes with "alive" booleans and so on. Maybe that's the best way to do it, maybe not. It certainly works OK.

I don't yet have a sense of how Java's garbage collection works and when exactly my classes are destroyed. I'm not sure if I'm creating classes over and over, taking up more and more memory. This will need to be looked at sooner rather than later else I'll go a long way down the wrong road, writing sketchy code.

This evening, Simple Game is playable, in a sense. You can't really win or lose yet but you have some control over what happens and the game's rudimentary automation seems to work smoothly.

Side Quest

I've decided to take a break from my main project to undertake something simpler.

The goal of this is to gain a good understanding of the Android development process from beginning to end. As things were, it was starting to look like development was stretching further and further into the future - I was continually getting new ideas that needed looking at and adding to the game design.

So now I'm building a very simple game and will work through the process of beta testing, monetising and publishing. Hopefully by the summer I should have a published title under my belt.

The "simple game" after 1 days work

My design approach for "simple game" is to not really have a design and let the game evolve in a more natural way. I'm not one for having good ideas out of the blue and work much better by looking at something and seeing how it could be developed.

The simple game will involve guiding a marble through a series of square by creating a path somehow. The different colours will influence how you're able to create that path.

Right now, all the app does is generate a random grid of squares and the player can create a path by tapping the squares.

It's not anything you could call a game yet but this is part of my process and how I generate ideas in my own mind.

Vive La Resolution

Being back at my 'normal' job this week has left me little time to sit down and do much coding. So, instead I've been experimenting with graphical styles, trying to settle on a suitable format for me game.

Initially I'd decided on retro style graphics with areas constructed from 8x8 blocks - that seemed sensible as drawing is not my greatest talent. Having tried a few things with 8x8, it seemed that 16x16 might be more suitable. 8x8, though quick to produce gives very little detail.

Now though, I'm even considering 32x32.

[...some time passes...]

After a week off from normal job and playing around with a few more graphical ideas, I've settled on the 16x16 format. It seems my own drawing isn't detailed enough to warrant 32x32. I'll be using multiple 16x16 blocks to create larger shapes to reduce the overall feeling of being blocky.

Another thing I've decided is to have the game divided into levels, like floors in a building connected by stairs and/or an elevator. Each floor will be themed so you'll have an maintenance level, medical level, etc. depending on what the story needs. Each level will have it's own items suitable for the theme of that level. Say you might pick up a nail gun in a maintenance bay somewhere.

Example of a 32x32 block level

16x16 blocks

Visual Inspiration

As a lifelong sci-fi fan, it's no surprise I draw much inspiration from that genre. Thinking about it, most of the games I've made in the past have had some sort of sci-fi theme.

Every time before, I've sat down with a single idea and began drawing graphics, sampling sound effects and ploughed into coding the game. And this time has been no exception.

For SG7 I'm taking visual cues from many sources, mostly sci-fi movies and old 8-bit space-based games. Although it's unlikely my finished result will be particularly atmospheric in comparison to some of the stills below, it's helpful to have a direction to go in with visual design.

The set design in Solaris (2002) is pretty close to the atmosphere I'm trying to recreate. Lots of grey panels, blue-tinted lights and screens illuminated with blue displays. It gives a sterile, claustrophobic feel that works well in the movie but may not translate to a low-res two-dimensional scene so well. Nonetheless, it provides useful inspiration for level layout and specific scenery elements.

The set design for the USCSS Prometheus has similar elements to that in Solaris, but with more displays and lights. Even with that, the atmosphere is gloomy and foreboding - something that I may want to incorporate to a degree in SG7. However, the game needs to be accessible. Players will be pulling out there phones to play on the train, on a break, down the pub.. anywhere, so it needs to work in the short as well as long term.

Fog of War

Getting a bit ahead of myself today but wanted to try out a few graphical ideas. A lot of adventure and Roguelike games use some sort of fog of war, that is, you can only see what your character would be able to see, rather than the whole game map.

Simple fog-of-war implementation

At first I was against this idea. Playing Lords of Chaos back in the 80s, I found the feature claustrophobic and restricting. Over the years, it has become more appealing as game makers have learned to better implement the idea.

There are a few ways you can apply fog of war to a game; here, I've used by far the simplest method by overlaying a static vignette on the whole screen. This is not particularly realistic and I don't believe adds very much to the game.

Later on, I'll be getting into line-of-sight code and ways of shadowing off areas not visible to the player. Some games have scenery in three stages: unseen, seen, and currently being seen. I like that model and will likely implement it myself, again, later on. There are more fundamental things to wrestle with before then.

I'm Your Density

It's nice when a hunch turns out to be right. Yesterday, I was baffled by my bitmaps being cropped to one corner and suspected something to do with pixel densities.

After reading much stuff on Stack Overflow and finding a very helpful video on YouTube, I discovered some useful information about how to properly support Android displays. As there are thousands of different devices with many screen sizes and resolutions, Android simplifies this by categorizing devices into 'buckets' labelled medium, high, extra-high definition etc.

Life's a medium density maze

I'd been using actual pixel sizes on an extra-high def. (XHDPI) screen which doesn't work correctly. The baseline is medium density where a physical pixel equates to a device independent pixel, or 'dip'. A dip on my XHDPI Nexus 4 is 2x2 pixels which explains why all my graphics were being chopped into quarters yesterday.

This evening, I've got part of my test map (yes, Pacman) displaying correctly, without any artifacts and learned that I'll need to make multiple copies of all my graphics in order to support the various buckets. This is frankly a bit of a bind but it's handy to know early on that I'll need to be doing this.

For now I can just work at XHDPI, produce my graphics for that level and make resized versions later when testing on different devices.

Cropped

So it's been a few weeks since I sat down to seriously do some Android programming. I'd never done Java before but have a previous life as a 'C' programmer. Upon first looking at Java, the code seemed pretty familiar and I optimistically felt making the change would be relatively trouble-free.

That's not quite been the case but with some perseverance, I've started making some progress. It's been an awfully long time since I did some coding, longer still since I had to learn anything new.

In the mid 90s, I taught myself 68000 assembler for the Amiga and learned how to use the various custom chips on that system. Being young and at college at the time, it took a couple of years before I produced anything decent. Two years seems an awfully long time now so I'm more focused in order to produce something useful sooner.

Back then I had two books - Amiga Machine Language and the Amiga Hardware Reference Manual. Now I've got, it seems, the entirety of human knowledge available to me via the internet. And that's been quite a problem - there's much dross, opinion and discussion about every possible topic so it's hard to weed out useful information and answers to my questions.

Still, I'm happy to report modest progress in the few short hours I've been developing for Android.

The world doesn't need another block game

Doesn't look like much, I know. Java on Android is a bit fiddly to set up so just getting a blank screen to draw on was a faff.

So far, all my test app does is load some resources - a couple of PNG images and a WAV sound file. The squares are the beginnings of a 2D level and the man is, well, just a man at the moment. He responds to touch input and moves to wherever you touch the screen.

Tonight, I have two outstanding issues, both with the map drawing. The squares are being cropped to the top left quartile and for some reason the map is being displayed sideways. I've had to set the tile size to 200% the actual size to get them to display correctly. More fiddling is needed - I suspect something to do with pixel density at this point but to be honest, I have only the smallest idea what I'm doing.