next »

[eclectocrat]

I suggest that segfaults blink in and out and are really hard to pin down. They should also have a nasty boss level big brother, multithreaded segfault or "access violation in thread 2".

Multithreaded bugs like Priority Inversion and Deadlock need to be killer hard and elusive. If your just about to defeat one, they should like teleport away or turn into a kitten just to mess with your head.

*shivers* Oh god, the horror, THE HORROR!

[_Tommo_]

To me the "scientist-named" bugs are a bit too generic, you just need to use C++ to stumble on much uglier beasts  

-miscast: when you C/static-cast something to the wrong type. Half of the object is good, half of the object is evil. What about some coin-flipping mechanic here!

-nullpointer: how can it be missing! It could be a simple fodder, maybe.

-garbage pointer: uninitialised pointers that contain garbage but do not crash your program. It spawns segmentation faults?

-library inconsistency: some third party library has a bug in it, and it's closed source. Don't know what monster this should be.

And, overflow has just too little space here, it could use a split between
-numeric overflow: a fodder that becomes really big or really small at will

-stack overflow: if not killed in a certain amount of time, it grows until explodes

-buffer overflow: the one with the lava.

[wilbefast]

Right, my friend Sam has offered his services as a Windows compiler-monkey - or to at least have a little look - so if you send me the stuff you want compiling I'll forward it to him (e-mail's in my profile).

Coolness  I've been having some problems with Windows 7, which annoys me because everything works fine on Ubuntu  Still, this new alpha has been successfully compiled for Linux and Windows (still need a Mac compiler-monkey).
Hope your friends mine is not blown by how... um... awesome my coding is 

*shivers* Oh god, the horror, THE HORROR!

This game emerged from and has fed my need for a way of releasing my programming frustrations - eg: "DIE SEFAULTS!! DIE!!!"
Needless to say each enemy should mirror the behaviour of the bug it's based on (=> segfaults come from nowhere and kick your ass in a microsecond). But this means I'm hesitant to include many concurrent programming bugs because I haven't done that much concurrent programming 
Still, multi-threaded bugs will certainly be of the high-tiers if they're added, and a pain in the ass to kill 

To me the "scientist-named" bugs are a bit too generic, you just need to use C++ to stumble on much uglier beasts 

For the record Lava is actually "uninitialised memory" and Bottomless Pits are "unallocated memory / NULL" I was also considering adding Mallocs as NPCs that you must rescue from cages (geddit?)

It's true that segfaults can have a huge number of causes (array out of bounds, following/deleting a NULL/uninitialised pointer, etc). Whatever the case it comes down to an illegal memory access, and "Segfault" sounds more... sexy  Still, maybe it should be broken down a little: certainly I agree that there's little difference between the "theoretical in-joke bugs"...

I totally agree for the buffer overflow, but I was thinking "arithmetic/numeric overflows" could spew up "rounding/numeric instability" errors  (our current fodder enemy) rather than actually shooting at you. As for the stack overflow - it's always hard to make things grow in 2D I was thinking it could just be the "normal" version of the three, dealing damage rather than doing weird shit 

[Toom]

Remember, if you want more complex high-level bugs as enemies, you're going to have to explain them in layman's terms before I can design them.

I've been mega busy these last few days, but I'm aiming to have the first round of monsters completely designed by Thursday, after which I'm going to dive straight into in-game graphics for awhile.

[Toom]

Um, when I said the above, I miiiight have forgotten about my evening classes, so don't hold me to it :/. Meanwhile, here's something!



Ladies and gentlemen: The Kludge.

The idea I've had for this dude is for him to go through a few different transitions; the form above is either his starting or second form, after he's taken a bit of a kicking. The idea is that he starts out looking a bit rough, but still sturdy. Then as you progress, it becomes more obvious that he's cobbled together from a bunch of bits that don't really work together; his final form, after

the fight with the Flying Spaghetti-Code Monster when he double-crosses the player, has his armour disintegrate almost completely, leaving something akin to a smaller, faster, more mobile FSCM that's been incubating inside the Kludge and is now using the remnants of his armour as a crude exoskeleton/throne/whatever.

I'll get concepts of these later forms done...um, at least when it isn't 2:30am anymore.

[wilbefast]

Great idea, and great concept
How about a ground version that tries to escape when its armour is destroyed, and which you have to corner?

I've been trying to... euh clean up my code a little before showing it to your friend. Not that I expect him to go through the whole thing but still - it's worth doing either way. I'll send you the link now 

I'm also thinking very hard about the fog of war / line of sight effect I want to do. I've seen a lot of 2D games that do "realistic" light and shadows but I may just go for a "tile by tile" approach  Any recommendations would be most welcome!

[wilbefast]

Shadows are more or less done now - all they need is a little optimisation and we'll be finished Get ready for an awesome Youtube
Shadows iteration montage!

How's the artwork coming Toomie old chap?

[Noyb]

Have you ever run across the triple fault? It's what happens when an error occurs that's so bad, it throws an error not only in the error handler for that error, but also in the error handler for the error thrown by the error handler. It normally only shows up when coding operating systems, and halts the entire system. I dare not imagine what kind of foul beast this could be.

[wilbefast]

Have you ever run across the triple fault? It's what happens when an error occurs that's so bad, it throws an error not only in the error handler for that error, but also in the error handler for the error thrown by the error handler. It normally only shows up when coding operating systems, and halts the entire system. I dare not imagine what kind of foul beast this could be.

Could find  A three-headed monster no doubt. Such titans can only be found in the Kernel though, where feeble programmers dare not tread...

When I first started thinking about the story I read this blog post:
http://blog.wolfire.com/2010/04/Saving-the-world-one-plot-twist-at-a-time

I was thinking it could go something like: "you're looking for a bug in a program, you realise that the cause of it is not the program but the library, then you realise that the bug is actually in the operating system, and eventually end up in the kernel itself for a climactic battle".

You and I should go on a bug-safari some time Noyb: try and bring down some big game. Yeehaa   

[Halcyon]

Cool idea, with all the time I spend debugging my code I should be an expert at this game.

[Toom]

The Triple Fault I can see as an almost miniboss-level enemy encountered occasionally in the final stages, like how that big blue spider-rider guy who serves as an early ED boss shows up as a regular enemy towards the end of the game (when they player's sufficiently powered-up to deal with that sort of noise).

Sorry I've been so slow with getting more artwork out, but my evening class finishes tonight so I can devote much more time to getting this done. I've started working on some preliminary player sprites, but nothing I'm happy with just yet - I'm still trying to strike a balance between the simple forms of the initial concept (which is not only visually appealing, but potentially a huge time-saver when it comes to animation) and a more classical pixel-art aesthetic (which might fit the theme of the game, as well as its roots in stuff like C-Dogs, a little better).

I do have some potentially helpful news, though! For starters, Sam's got the alpha you sent me and will be able to confirm whether he's up for compiling the Windows version in the next day or two, so that's one thing potentially taken care of.

There's another thing, too. Obviously I have no desire to tread on your toes as far as creative content goes - this is your baby, after all - but I have received a couple of additional help offers if you wanted it. One is from an extremely enthusiastic and inventive level designer, and the other from a startlingly good chiptunes musician; if this is stuff you'd rather do yourself, excellent, but I thought you should know there's folks who'd love to help out if you wanted some of the heavy lifting taken off your hands .

Anyway, I'll get some player sprite stuff posted as soon as I've got the niggles worked out, and crack on with concepting while I'm at it.

[wilbefast]

Music is one thing I can't do at all and I only dabble with sound-editing, so a musician/foley-guy would be extremely welcome 
As for level-design I think a second pair of eyes/hands might well be very useful. After all from the beginning, I've been trying to make the tools easy to use in the hope that people will create their own extra levels I'd still like to have some reign over level design, but it would be good to have someone to collaborate with and bounce ideas off.
Speaking of which, I definitely want to include "jump-to" statements in the levels: they'll work like teleports

All told this project is supposed to be a learning experience above all, and one of the things I really need to learn is how to work in better in a group. At school I had a number of bad experiences, either not be allowed to do anything or being forced to do everything. It left a bit of a bad-taste in my mouth but this needs to change!

Here's to giving teamwork a second chance 

[Toom]

OK, cool. I'll probably see the music dude tonight so I'll have a chat with him, see if he can't come out with something. He'll need to know stuff like how long you want the loops to be etc., but I suspect the bulk of this is best left until the game is mostly done.

I'm having a hell of a time finding any of his stuff online, except for this, which will at least give you an idea of what he's capable of.

[wilbefast]

For music you can't go past

 

In essence I'm trying to make a game that has some of this same mindless cathartic violence, so you can taking out your debugging frustrations in a safe, social-acceptable manner  So the music needs to be something equally... "pumpin'". Though one of Doom's strength was that different levels had different pacing: music and level-design need to be in close communication!

As for length - I had one loop that was 16s and this was definitely to short. Around 30s would be about the minimum, and for a game track you probably don't need anything more than 1-2 minutes maximum because it's not your primary focus. 1 minute is a pretty good length in my opinion.

Thinking about this I just went back over a few tracks from previous projects, made by this awesome guy called Henrik Roslund:
Abomination
Zombie Run
Just in case you were curious 

New post about the shadows by the way 

[wilbefast]

This weekend I want to implement the non-aesthetic side of fog of war as well as the map, which I think will be overlayed onto the screen, toggled on and off using TAB. Extra information will be added to the pathing matrix: each cell will now be either in view, in fog or undiscovered.

I've also been thinking about non-enemy gameplay objects that is, objects in the levels which serve some purpose for gameplay aside from being shot. First a quick explanation of how I was thinking the game could work:

• The "world map" of the game is the game's own UML diagram: you travel between source files (levels) along dependencies (include, extend, etc).
• The main idea of gameplay is to clear each level of bugs. Doing so allows you to move on to any other level it is attached to.
• You can "step out" of a level mid-way to return to the world map and choose any unlocked level, or you can go by foot to the exit.
• For simplicity, only the locked/unlocked state of a level is saved. So if you leave a level before clearing it, all the bugs will be back again, otherwise they'll all be gone (as in DROD).

I briefly considered using some sort of key-card but the idea there is really to add a degree of linearity to a non-linear level by forcing the player to hunt for a key before moving on. Since the game by its very nature is about hunting around, this shouldn't be an issue.

SECRET (OPTIONAL) AREAS
I was thinking of adding some sort of optional bonus though, for the hard-core player. So I thought maybe there could be an extra, optional enemy called a "Memory Leak". Such things won't kill the program so aren't bugs... as such. That said you REALLY don't want them in your program. I was thinking some sort of floating, weeping brain with eye-balls but that's up to Toom. They could either be a sort of "catch me if you can" creature or an optional mini-boss. Needless to say the number of remaining memory-leaks (and which) would be saved when you exit the level, even if it's not cleared.

EXTRA LEVEL-EDITOR FUNCTIONALITY
I think it's a bit of a non-brainer using "goto" statements as teleports and "switch" statements as, well, switches. I'll have to add some new functionalities to the level-editor to let you connection teleports to specific areas and switches to... well, what do we want to switch on? Doors? This might be tricky from the point of view of shadows...

HEALTH AND AMMUNITION
An interesting point to consider here is: how do you get your health and ammunition back? There could be pick-ups placed around the level and/or dropped by enemies, or either or both could regenerate. There's also the question of whether to use a single ammunition resource or a different one for each weapon. And is health and ammo restored when you leave a level? If so how do we stop players from "farming" ammo by going back in the lower levels? These are all things to consider over the coming weeks...

[wilbefast]

I've added a few new entries to the initial post, including a couple of videos: I've now finished all the view-based code, both the (complex) visual and (simplified) functional side of things. Now the project needs to go on hold for a little while while I pass my exams.
I've made sure to leave it on a high (that is, having just solved a major problem: recursive shadow-casting). This way it'll be much easier to come back to it a couple of month's time.
Toom also has his evening class to finish up (I think) so maybe it's a good time to take a pause.