(Yet to be determined) Platform Game

You might be prone to ask 'What has Lachlan been doing since we saw the release of The (lite) night the Martians Came?' 'What masterful example of gaming is coming next?'

For a while, it looked like it might be soccer. But it's not. I've started programming a platform game of some form. I'm not sure whether this is the start of the codebase of 'The War of the Apocalypse Samurai' or not yet - but it is a platform game. I'm writing the level editor in the same engine as actual game to hopefully make it easier to keep making the game.

So far, it does a grand total of render platforms (ie. plain, red rectangles bordered by a slighter lighter red). The editor also allows you to add platforms by switching into editor mode (e) and placing a platform (p). I've started work on a console as well - which will be fairly important 'cause all scripted events, and most properties of platforms/moving things/actors etc will be changable by the console and the so-called GUI of the editor will mostly be links to the console.

At the moment, everything is going to be simply rendered as boxes until the game is playable and maybe even a little fun. Then I'll start worrying about looks.

I've no idea where or how this will finish. But the goal is set: A platform game - of some kind. Even if I do use it for War, it is likely a more simple game will be made first.

Read More

Prototype Graphics

I've heard it said before that most people who attempt to make indie games are generally either Artists (of some form), or Programmers. When they're people like me - making games by themselves, that generally involves loving one and struggling through the other - Programmers need art for their games to look pretty (unless they're making a Roguelike or Old-School Interactive Fiction), and Artists need programming to bring their pieces to life. Unfortunately, I lean towards being a programmer, and I'm not particularly good at either. Except music - and even then, generally outside the realm of Video Game music.

I've got a few ideas for what I'd like to make next. Unfortunately, they inevitably involve needing artwork of people. So - I've made the first version of my Prototype Dude. He's made in inkscape in a nice, scalable vector format. He is simple to edit, and simple to change, and simple to modify to new purposes. I think I'll use him when programming these learning things, and the prototypes of games to see whether they are fun or not. If I decide to go all the way with one, and try to make it commercial, then I'll either embrace the simplistic style or replace the graphics with more complex art - which may, or may not be done by me.

So far, I've done a Walk-cycle. Its an old-school 3 frame walkcycle - which doesn't look great at higher resolutions but is certainly passable. I might bump it up (particularly the side walking) to 5 or 8 frames later.

This is him so far. He may be updated, but its a start. If anybody would like me to put up the SVG for you to use, let me know.

Read More

The (Lite) Night The Martians Came Released! (v0.1)

My fully playable space invaders... tribute "The (lite) Night The Martians Came" is now playable by you. They get harder, they get faster. Staying alive will be an issue for you :). Feel welcome to post your high scores here - which may be a challenge 'cause each level gets faster too.

To install, just download, and unzip, and run 'The Lite Night The Martians Came'. Mouse or arrows move the ship. Clicking or pretty much every button except escape or f fires. Escape pauses, f goes to full screen.

You can download it from here.

I've seen this more then anybody... obviously

I've implemented almost every feature that I think needs to be implemented for a playable, and remotely enjoyable game. I might still add a few things, or make some changes but that's why I'm calling this the beta. I've learned a lot about C++ but the code itself whilst not buggy, is in a sorry state from having not really designed it. It'll be a pain to long term maintain - though there are distinct chunks of it I'll be able to use again. The code bounces all over the place, and isn't really well split into classes. But the thing works.

The source is an absolute mess - but I may release it too. Just not today.

Again, you can download it from here.

Update: 19/06/11 1:02AM

Something appears to be screwy when on XP. Everything points to a missing DLL but I can't figure out what it is. It should work if you have the VC++ 2010 Runtime installed, but I'm not convinced. If anyone has a clue how to fix it, please let me know.

Update: 19/06/11 12:15PM

I fixed the problem. Something related to manifests etc - and at least one library compiled against Visual Studio 2005 runtimes. I've updated the download - it should work on XP.

Read More

Space Invaders - Progress Report

Shooting and...

Destroyed!

I've made progress in my space invaders clone. I now have invaders. They don't move, they don't regenerate, they don't shoot, and they can't add to your score, but they can die. They can be destroyed, with a satisfying explosion. There is some light at the end of the tunnel.

The Codebase itself is an absolute mess and is probably best described as an example of how not to force old-style procedural programming upon classes, which in themselves are poorly split, highly interdependent and full of data and gameplay - not always related.

But, I'm still learning C++, and that is the goal. I need to learn more patterns, and be stricter with how I apply it. I'm finding that one of the hardest things to grasp in C++ has been the STL, but really, its a fantastic resource - particularly having object oriented lists, arrays and (as I'm loving) maps directly available. Whilst this is simultaneously over-engineered and under-engineered, I'm beginning to get a better idea of the types, classes and features available to me - as opposed to simply programming in ObjectPascal with C++ syntax. Whatever comes next may have to be more planned then this was, but I've got a better idea of the language now for when I do the planning. However, this code may be properly considered a casualty in my lessons. If I want to expand the feature set, there is a genuine chance I'll need to refactor the code considerably. I'll make a playable game (rather then a shooting gallery, without a score and stationary targets), and then see how much I care about extending its rather pitiful life. But a useful learning exercise nonetheless.

Read More

Martians Update

OK - Progress Update:

I've got a nice, generic chunk of code for making menus. It works, it plays sound, you can see it above and

I've finally started actual game programming (between studying for exams). This is the ship, shooting bullets (with sounds), that is controllable by the mouse. Next is to add enemies, and we'll start having something playable!

Read More

Lachlan's Adventures into C++

So far, I've really finished only two basic things in the Space Invaders clone. Firstly, I can display an arbitrarily long series of images, each for a certain time, each skippable or not. This provides the way to show logos etc. This will be reusable, and is reasonably general so if more complex then it needed to be. Secondly, the menu screen completely works, and plays sounds as you select items with Keyboard or Mouse. Like the first thing, it can show an arbitrary amount of menu items, put anywhere on the screen. This also involved writing a basic sound manager which associates sounds with a string, and can play them using SDL_Mixer. So - it can work thusly:

1. //Load the sound
2. Sound::Instance()->AddSound("Shoot", "\\data\\sounds\\shoot.wav");
3. //Play the sound
4. Sound::Instance()->PlaySound("Shoot");

Each subsequent reference only needs the PlaySound command. The Sound class manages the WAV files, and deallocates them at the end of the program.

These have, whilst sounding trivial in the scheme of making a playable game, taught me some things I will need to know, and provided code and classes that I will use in the game proper. So far, I have learned to use:

• Sound in SDL
• std::map
• std::vector
• The singleton pattern
• Putting types in classes

Now, I'm up to programming some actual gameplay. I sense that the std::map and std::vector containers are going to prove helpful

Read More

Martians Update

I'm not a fan of OpenGL. At least not for what I need it for. And I'm finding it rather discouraging to have very little clue what the example code I'm using does. And I don't seem to be getting anywhere. I'd rather program gameplay then wrestle OpenGL into submission.

So, I'm giving up delaying the ambitious initial design to make 'The (lite) Night The Martians Came'. My less ambitious, less lofty goals to achieve in the short term:
- Basic space invaders gameplay (with only one weapon, but with a slightly different layout of Martians - as you can see in the mockup)
- Locked 640x480 resolution screen (with a toggle for full screen)
- Maybe include bunkers, maybe not
- SDL for Graphics 'cause I've used it before

Mockup only

I've made a mockup for the purposes of working out my sprite scalings that I thought I might as well share.

My goal to make it the slightly-less light version would be to use OpenGL Frame Buffers so I could still make a fixed resolution SDL game, and then scale it to the monitors native resolution, and make it handle different aspect ratio screens.

Finally, my goal to make it the full fat version would be to ascend to my lofty goals prescribed earlier.

Read More

My wrestles with OpenGL

I've spent the last week in Tasmania, so haven't done massive amounts.

What I was doing before I left, and have been doing since, is slowly wrestling OpenGL into submission. This is what I've managed to do so far:

Hmmm... How Exciting. I should probably clarify, they don't move. In fact, all they are is 50 textured polygons (quads) that don't do anything. The extent that you can do in the program is push ESC to exit, or F12 for a not quite correct screenshot.

What I've primarily discovered, is that I don't like OpenGL.  On my first day with it, I find myself with slowdown problems. For rendering a single textured polygon on the screen. Because, unlike DirectX, the general rule is that OpenGL cards 'fake it till they make it' - anything the graphics card can't do, simply means the OS will do in response. Which still didn't explain my slowdown.

Which got queerer. It seemingly disappeared again and went back to the kind of frame rates it should have. Then, slowed down again. The only actual fix I've found is to run the program in full screen.

You can follow my struggle with the speed at http://gamedev.stackexchange.com/questions/11533/opengl-insanely-slow.

But you may ask why I'm bothering with OpenGL? My answer is simple: I want Hardware Rotation and Scaling. SDL is fantastic for what it is, but its graphics side struggles. Specifically, to rotate or scale sprites are very costly CPU operations. I wanted to learn OpenGL so I can have a retro looking game, without eating a modern processor to bits. It also works really well with SDL. Instead of learning DirectX, I can apply the SDL I already know for events (Key, Mouse, Joystick etc), sounds, windowing* and timing. Finally, SDL+OpenGL is platform agnostic, and I should be able to go to Mac or Linux with almost no, if any changes. Except in the first case, having to purchase a Mac.
*OpenGL doesn't make its own window by default. You either do it yourself with ugly windows code, use the very outdated GLUT or (as I did), SDL.

The other issue I'm finding in learning OpenGL is the sheer lack of resources as to what modern OpenGL is. And what is seeming to be the phasing out of older features - when I ran my program through a profiler to try to figure out what was holding it up, it told me 90% of my calls were depreciated. Instead of doing anything the way I was, I was supposed to do it in 'Fragment Programs' (DirectX calls them 'Shaders'). I'm trying to do basic things in the API, and I need to separately program the GPU? And, not to mention, require people have a relatively modern (Post 2005) video card to play a 2D space-invaders style game? It seems a wee bit ridiculous. Even the industry standard 'The OpenGL Programming Guide' (The Redbook) starts by teaching you how to program in a way that is completely out of date, and depreciated. Gah!

Work is slow, but steadily moving forward. Watch this space!


Lachlan

Read More

Studio Name Chosen

I think I've settled on what I want to call my little games making 'studio' (as it were). I'm still open to suggestion, and this logo isn't finalised yet... but

I feel it has something along the lines of Vintage, as well as Retro, as well as Faux Class - like a suit made of fake velvet. As well as being just a little bit silly.

If its your kind of thing, you can download the wallpaper below. Its massive 'cause its for my rather large screen, however if you use 'Center on Screen', the logo itself will fit on any reasonable sized screen.

1920x1200

In other news, work has been particularly slow in 'The Night The Martians Came' owing to a really rather large Human Rights Law essay due tomorrow. Which I must get back to. Goodnight!

Read More

Space Invaders - Progress Report, and OpenGL

I'm slowly continuing along my path to make Space Invaders - or, as my game is called, The Night The Martians Came. Actual progress thus far falls along having made most of the graphical assets. Coding has barely started.

What instead I've been doing is starting to learn some basic OpenGL. I don't know if I want to use OpenGL for all my blits (Blitting: Putting a picture or piece of gfx on a surface (like the screen)), or whether I want to stick to SDL. The prime reason I'm learning OpenGL is so I can get the graphics card to handle scaling and resizing, without me having to quite so much. This means I'll be able to make bigger screens and smaller screens work, and maintain a reasonable speed to play. SDL_GFX on the other hand, provides scaling functionality, but is really too slow to use in realtime.

The actual thing I'm debating is whether I make up the image in SDL, and punch it into OpenGL or just stick OpenGL all the way. I think I'll figure it out better as I progress with OpenGL. It natively provides a lot of things like scaling and rotation that SDL doesn't.

I'm not a fan of OpenGL so far. It took me ages to get a tri to the speed - but, that is probably more due to my lack of 3D coding experience then  OpenGL itself. But I'll get there. Hopefully, still within a month. Really - there shouldn't be too much coding to do - though substantially more then pong.


Lachlan

Read More

Giga Wing

Continuing on the Arcade theme started with Metal Slug X, I played through Giga Wing this evening. Giga Wing is a 1999 Arcade Shoot 'Em Up game. It is notable for cool graphics, but primarily for ridiculously high scores. It comes from a school of Shoot 'Em Ups generally referred to as Bullet Hell.

This is why...

And this...

And I really don't have a clue how humans can live through Bullet Hell sections like this. I didn't. I died. Repeatedly.

The gameplay is fairly generic for a game like this. You either shoot by tapping the shoot button, raise a protective shield (works for about 2 seconds, and requires about 5 tear jerking seconds to reload) or shoot one of a limited number of bombs. In between times, you dodge enemies, insane amounts of lasers and collect power ups and medals.

To be bluntly honest, a while since I've played, and not a great score. But the fact that after the first level it reached more then 32 Billion, it'll do

This is where Giga Wing begins to differ from many other games. Its scoring went very much along the pinball lines that bigger is, by and large, better. Scores in the trillians are not unheard of. Unlike most games which a medal might be worth 10, 20, 50 or even 1000 points, in Giga Wing a medal is worth 10 more then the previous one, 50 more then the previous one or in extreme cases 200 more points then the previous one. So when (as pictured below) you find massive amounts of low scoring medals, each is worth the cumulative sum since last time you died.

Those gold shields are medals and good for scoring. If you can actually dodge the bullets that is.

The game is (as arcade games are) fairly short. What this does mean is that whilst it is a very sweet and detailed experience, the difficulty bumps are noticeable. If you're even half competent (like I am), you should be able to make it up to the second level without any continues. However, by the last level, you're requiring 3+ on occasion. At least if you suck as badly as I do.
Unlike most Sh'mups, there is an attempt at some story. I have really no idea what it is, other then something do do with destroying some medallion. The medallion is lodged within each boss, and serves as the final boss itself. The game also uses static cut scenes drawn in an anime fashion which tell the story... Kind of. I think I was missing something about it.... But the genre isn't one particularly known for its storytelling.

The medallion is the thing in the middle of the boss

Typical anime cutscene

In general, the game is a lot of fun. It does tend to suffer from minor slow downs when there are large amounts of coins on the screen - but I only noticed once or twice. Its about 20m long - maybe  - but it feels about the right length. Without change, the style of game can only go so long without going stale. I played it on Mame, but it (and a sequel) was available on Sega Saturn.

Personally - I think it is a genre that hasn't been adequately explored for the last decade. It may not be in vogue, but considering the current rise in casual games - Sh'mups seem a natural extension. They're easy to pick up, particularly difficult in some cases to master. They seem to me to be a natural choice of casual games for hardcore gamers. That - and who doesn't like having scores in the trillians? I also think they're a really natural choice for indies to develop. In Japan particularly, there is somewhat of a cottage industry producing new sh'mup's but it surprises me that we see none of it in the west. The style of game can handle somewhat simpler programming then most games, and being limited to 2D graphics by design. Unfortunately, I fear that their renaissance is not coming any time soon.

Read More

Lachlan's Continued Adventures into C++ #2 - Space Invaders

I've started continuing my adventures into C++. Working on the few assets to make a Space Invaders derivative game: 'The Night The Martians Came'.

Space Invaders will teach me more about class design in C++. The use of different levels will increase my knowledge of State Machines. The invaders will teach me about some basic interacting AIs. The whole thing will simply help my C++.

Goal to finish: 1 Month, hopefully less.

Features to implement:
- A few different weapons
- Space invaders style game play
- A few different levels
- Some chinglish style cutscenes (Meaning probably a picture with a caption)
- Sound

We'll see how it develops soon. I'm working my way to make the games I actually want to - but I'm in a new language, and I've got bad programming habits. So walking, and then jogging before I sprint sounds like a pretty good plan.

Read More

Metal Slug X

A little justification: I admit that the chances of me keeping this blog interesting and fulfilled with my developer oriented content alone are fairly slim. So I'm going to branch out a little, and do some game discussions and reviews, and essays, and what I think about games. So - perhaps use this as my soapbox, as it were, at some level.

Are your manly senses tingling? They oughta be!

I spent the last hour or so playing the 1999 arcade game Metal Slug X for the first time in many years. Metal Slug X is a (slightly) updated version of Metal Slug 2. It is a fiendishly difficult run-and-gun game, full of very light humour and gorgeous pixel art.

Consider this - 59 Continues = 59 Quarters = $14.75 spent on the game, and 177 lives lost

I would love to fill you in in the story, but I struggled significantly to actually understand it. I'm not really sure what it was, other then running through a series of wonderfully drawn stages with guns and heavy machinery.  

Something to do with Saddam Hussein perhaps - this is from the last level after he has been sucked up by aliens

The first stage puts you through a generic middle eastern area. With lots, and lots of guns.

And an armoured donkey

And the eponymous Metal Slug 

The game continues to fight through Mummies in a cave, aliens in New York (?) and an Arctic military base - finishing in the epic duel out against the alien ships. If you play like I do, then you'll spend most of your time shooting at them with the crappy pea shooter. Mostly because that's what you get if you die. You'll spend significant amounts of time with the heavy machine gun, but more awesomely Laser Beams, Guided Rockets and Bouncy Bombs all make significant appearances. Particularly fun are the vehicle sequences - providing you can actually keep them in one piece. The Metal Slug is a large, laser shooting personal tank with the ability to jump, and some other pretty cool vehicles.

Get used to seeing this a LOT!

Whilst you may not be used to 2D in this 3D spoiled age, the graphics warrant a special mention. The pixel art demonstrates the absolute pinnacle of its style. Little details are painted right throughout the levels, and the level of detail on the sprites is just fantastic. I only hope that my pixel art for War of the Apocalypse Samurai can come somewhere even close.

The Bad: This game is rather difficult. Good luck ever finishing it on one continue. Also, the slowdowns that plagued Metal Slug 2 still rear their ugly heads - though less so, but still noticeably when there are lots of explosions etc. on the screen.

Note that the game is rather short, however its cinematic quality and game style ensure that it is a very, very full short. It is well worth your time.

I played it using MAME, but I'm informed that it can be purchased on the Wii virtual console, or part of 'Metal Slug Anthology' for PSP, PS2 and Wii.

Read More

Lachlan's Adventures into C++ #1 - Pong

I've begun my adventure into learning the heinous language called C++. I like the IDE I'm using (Visual Studio 2010) as compared to JEdit/Command Line, but I'm not really impressed by the itself language thus far. I'll detail that later, when its a bit later in the day and I'm a bit more awake.

Pong is mostly finished. A little of the logic is a little dodgy, and I want to make it zoom in closer. At the moment, you'll be playing it with your mouse on a 128x96 pixel display. But I'm still pleased with it as the first thing I've written in C++.

You can download the crappy version here
If you're interested, the source is here

Update: (5/04/11 8:03AM:) - I didn't realise I had to distribute DLLs too. Fixed.
Update: (5/04/11 8:27AM:) - Fixed logic too

Read More