Posts Tagged ‘programming’

Wave hello…

Tuesday, February 23rd, 2010

Y’know what’s daft? Part of the idea behind this site was that the games would be simpler and more about experimenting with the languages; despite that, I seem to be spending a lot of time building systems that then need populating with large blocks of attack wave data! Stuff that for a game of soldiers, I reckon the next project is going to be an arena shooter with randomly-generated placements!

Anyway, I finally sat down with Dark Cavalier to populate it today and have about a minute or thereabouts of enemies now – the “plan” is to have four or five minutes in total and some of the nasties only spawning if the game is set to “hard” (so the best scores will be gained by using that mode) which initially had a suicide bullet system as well which rather ironically felt too damned difficult so they’ve been disabled. I might add a third “very hard” setting that brings them into play perhaps…

Now I know DarkBasic hates me!

Sunday, January 31st, 2010

Yes I’m afraid its official now, DarkBasic Pro and I had something of a… tiff yesterday and as a result it spent last night sleeping in the spare room whist I spent the evening crying down the phone to my mother.

All I was wanting was to put a still image behind the 3D objects and the texture backdrop command appeared perfect for that job… except it wasn’t being highlighted as a keyword in the IDE and seemed to have no effect whatsoever. The reason (which I found squirreled away on the DBPro forums after about four hours of web searches, trying variations, swearing and re-reading the help files) is that the “texture backdrop” command is now classed as obsolete and, rather than throwing back an error or anything sensible like that, the compiler just goes ahead and ignores it entirely! I’m really not sure how “professional” any programming language can claim to be when the on-board documentation hasn’t been updated to remove depreciated commands like this, especially when the compiler itself has been told to paint over the cracks.

On the plus side, project 5 now has an “official” name – it’s going to be called Dark Cavalier because it sounded fairly cool when i did the “science fiction voiceover test” (essentially just saying the name as though you’re voicing a trailer for a new sci-fi blockbuster) and, after spending another two hours building the titles logo in Imagine and then finding a way to convert it to Direct3D for DBPro to work with, I’m knackered if it’ll get changed now!

I think DarkBasic hates me!

Sunday, January 24th, 2010

Or perhaps “hates” is a little strong but I’ve broken it a couple of times since picking Project 5 back up after my deadline; two of the nastiest crashes were just trying to do a find and replace on my source but there was half an hour of head scratching when the damned thing refused utterly to explain where the syntax errors it found were located in the bloody code – turned out the “issue” was some comments added to the end of a line where a constant was defined… if there’s one thing that bugs me it’s bad error reporting.

Un-named DBPro Project

But despite the tribulations there’s now a workprint of the still unnamed project. Apart from actually strapping a title page into the thing and performing the usual surgery so that the game can run as part of a larger loop rather than relying on the variables being nulled when they’re created, it’s pretty much done – the actual populating of the level will take a bit of time and i need to “fudge” a soundtrack as well…

Project 5 is alive

Sunday, January 17th, 2010

In fact, the as yet un-named Project 5 (hey, maybe I should just call it that…?) is already up and partially running. I’m playing with the ad-driven release of DarkBasic Pro and have a small-ish game engine running, essentially a common or garden vertical blast but with the camera looking through the scene at an angle so that objects get larger as they move down and the entire thing has a little depth to it.

Getting used to “thinking” in 3D (even if the game itself only moves in two dimensions) has been quite uncomfortable, at one point I had quite a bit working and decided to add some particles to make things go “boom”, only to find out that the built-in particle engine is designed to run at a particular orientation and i’d designed my entire game at a ninety degree angle to how it’d look best – cue moving the camera, followed by head scratching and trying to work out which axis to rotate the objects on to get them the right way up!

I’ll probably have a screenshot in the next day or two (got a writing deadline next week so development’ll be slowing to a crawl until that’s safely out of the way).

Happy Ball postmortem

Wednesday, December 16th, 2009

i’m pretty bad at these, aren’t i… okay, so Happy Ball Is Happy has been in the wild for a while now, so time for a quick postmortem.

What went right?
This was my first attempt at an arena-based shoot ‘em up and literally the first piece of C++ code i’ve ever written, in that respect it went quite well! i’m not sure i’ll be using C++ for any further projects to be honest, but it was a learning experience and should i decide to try XNA or perhaps Java development at some point it should be a good grounding. As a game, it played pretty well and although it doesn’t appear to have even registered as a blip on most people’s radars, i quite like it so [ppphhhpppt!]

What went wrong?
The final result was rushed because i was getting annoyed with it not being out the door. There was an issue with Vista Home reported that i simply couldn’t trace (since i don’t have any Vista boxes myself and the only ones available to use for testing were running Vista Business or Ultimate) and issues with how Allegro doesn’t protect the contents of video RAM, meaning that it’s easily possible to trash all of the graphics by tabbing away and then back to the game.

What was learnt along the way?
Well, apart from a smattering of C++ the most important lesson is “yes, having spawning points works” and that was the biggie; one of the problems i’ve noted with most arena-based shoot ‘em ups has always been the enemies spawn into the play area, that means there are moment when they’ll be trying to materialise directly under the player’s sprite. The “boss” nasty in Happy Ball Is Happy means that it’s obvious where each spawned attacker is going to come from even if the player hasn’t learnt the release patterns to know what’ll be along next.

Final thoughts
It’s a hideously simple game really and has that forced cuteness that comes from not quite being able to pull off true cuteness due to a high level of cynicism, but Happy Ball Is Happy did what it was meant to and is still a giggle to play. Perhaps a sequel, redone in BlitzMax with more options, joypad controls and so forth should be on the cards…