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

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