next »

[wilbefast]

Hi there!

I'm making a Free game in C++ for Linux, Mac and Windows It is a dramatisation of the debugging process, in the vein of CyberDogs. So basically you just blow sh*t up: here is a video. I've been posting logs for a while on my homepage, but one needs to be more formal and professional on blogs and you don't tend to get so much feedback  



Here I'm going to be posting any half-baked ideas I have, and hopefully there are some people around I can bounce concepts off In case you're curious, here is a list of previous dev-logs: the most recent is more in line with the sort of stuff I'm going to be posting here  

Subject:	Date:
The main loop (homepage)	03/08/10
Using views (homepage)	24/08/10
Network programming (homepage)	07/09/10
Collision-checking (homepage)	14/09/10
Object management (homepage)	21/09/10
Draw (Z) order (homepage)	11/10/10
"Bugger!" is announced (homepage) (tigsource)	28/10/10
Special effects (homepage)	11/11/10
The concept (homepage)	18/11/10
Mice vs. keyboards (homepage)	25/11/10
Generalised AI (homepage)	14/12/10
Auto-tiling 1 (homepage)	06/02/11
Soft-coding with TinyXML (homepage)	11/02/11
Auto-tiling 2 (homepage)	16/02/11
Enemy/Weapon brainstorm (tigsource)	16/02/11
Concept art by Toom (tigsource)	02/03/11
We need Compiler-monkeys! (tigsource)	05/03/11
Alpha4 download, screenshots, videos (indieDB)	06/03/11
Shadow progress montage (tigsource)	14/03/11
Implementing shadows (homepage)	16/03/11
NEW April Fools: "I've learnt so much!" (homepage)	01/04/11
NEW Going on hold (temporarily!) (homepage)	08/04/11
NEW Recursive shadow-casting (youtube)	10/04/11

I'll keep this table updated as an index of things we talk about. Please post any comments, ideas and pictures of your genitals feedback that you happen to have   Seriously: now is a good time to subtly manipulate the design of my game  

Cheerio,

William

[eclectocrat]

Nice! I read through the auto-tiling part 1, good analysis. I was previously looking for an algorithm that would process the images for me and generate the right tiles without me doing any work (Torvalds quote, hehe).

You address a whole lot of stuff that I'm interested in, so I'll be back to your blog.

I like the look of Bugger, I think that C++ is a really appropriate language to use for making the game
Good luck, and may your bugs be easily reproducible.

Here are my genitals:

[wilbefast]

Thanks for the reply  But you should really get that looked at 

The last couple of days I've been thinking about weapons: most shooter games tend to follow the standard pistol/shotgun/machine-gun/rocket-launcher/plasma-gun pattern. I really wanted to do something a bit more weird and wacky, but I've somehow ended up with a weapon that's basically a pistol and another that's essentially a machine gun 

I've been thinking of ways to correct this  For instance:
PRINTF = splits into multiple projectiles ('%' symbols) in flight?
PERROR = bounces off walls?

I'm also looking into shadows/fog of war using this tutorial.

[AndrewFM]

Try looking at a game like Liero X... with the sheer number of user-created weapon packs, there's a lot of opportunities to take note of how to make unique weapons that don't follow typical trends.

[wilbefast]

Ah, Liero... fond memories  And there's a Linux version too - sweet 

The hardest comprimise will be for the basic weapon, since it needs to be easy to use and versatile without being boring   

[Toom]

That's not such a problem if weapon drops are frequent enough - it just needs to get you to the next upgrade, it doesn't need to be a staple weapon.

Sorry I've been so late getting any artwork done, that commission has graduated from kicking my arse to kneeling on my throat. Here's a quickish player concept I came up with.



If it's not clear, that platform jobbie's meant to have three legs, not, as I seem to have accidentally drawn there, two legs and a pointy dong.

Edit: here is a photograph of my genitals, in action.

[wilbefast]

I love it the concept art I mean, not your genitals... not that there's anything wrong with them

What's good is that he's recognizable as a programmer edit: One thing though: where do the projectiles come from? There's nothing wrong with having when materialise in front of the keyboard if that's the intention - I'm just curious.

Don't worry about delays by the way: I live in Italy atm, where "at least a week" means "more than a month". Besides, the new alpha (with all the artist-helpification -read softcoding- features) hasn't even been uploaded yet!

I have a vague idea for the story: probably better to get it out sooner rather than later. Anyone who doesn't want it spoiled can just not look at the black area  

The code you're debugging is actually a project that's been abandoned on the internet by another programmer who went mad writing it. As you go along you'll find logs ("comments") illustrating this gradually descent into madness. You proceed through the code clearing "files" of "bugs". Eventually you kill the Flying Spaghetti-code monster, at which point you discover that "the Kludge", which was originally helping you, has turned against you (as kludges do). After destroying the Kludge you proceed to the very heart of the bugginess of the code. Here you discover that the programmer is still there, and is actually actively adding bugs to the code so that nobody else can get credit for his work. I was thinking he could be a two-part boss, first as a bug-summoning doppelgänger, and second (having falling into some kind of radioactive bug goo or "unallocated memory") as a weird mutated bug-man. Hence "Bugger" = somebody who puts bugs into the code rather than taking them out! The point of all this being: when designing the main character, consider what his evil-twin might be as well. Or we could go with a different final boss (three is usually a good number - don't ask me why). Just a vague brainstorm - let me know what you think!

[Toom]

Well, there's nothing stopping me jimmying up the two forms you just mentioned, and then adding or changing stuff as the game goes along.

I was thinking yeah, materialise the projectiles in front of him, but it seems kind of lazy on my part...maybe have something like a floating text cursor that spawns the code-nuggets for attacks or something.

Have you had any thoughts on how you'd like this thing to look? I can run with the flat-colour-simple-shapes aesthetic in the player concept if you like it; I'm a little rustier at pixel art but I'm game to have a go.

[Toom]

Concept for the Floating Point / Divide By Zero error.



I'm seeing this dude as a charger, using that big ol' blade deal to ram you all up in the stuff.

[wilbefast]

I'm seeing this dude as a charger, using that big ol' blade deal to ram you all up in the stuff.

I like the concept - it fits well with the name of the character too. What needs to be considered though, when it comes to function, is what all the other enemies will be doing. For instance, I had the FPE shooting fireballs in the Alpha so that it would have a function distinct from the Syntax Rounding Error which is a close-combat swarmer.
All this can change of course, but it needs to be considered in context:

Type	Name	Ranged?	Flies?	Wanders?	Flees?	Chases?	Notes
Fodder	"Rounding Error"	No	No	No	No	Yes	Could be ranged+combat (Doom imp) instead?
Fodder	"Floating Point"	Yes No	Yes	Yes	Yes No	Yes	Charge attack (Doom lost soul)
Mid-range	"Overflow"	No	No	Yes	No	Yes	Attacks/death create lava, can hide in lava
Mid-range	"Infinite Loop"	Yes	No	Yes	Yes	No	Continues firing until interrupted
Dangerous	"Segmentation Fault"	No	Yes	No	No	Yes	Could be a sniper instead?

So functions will need to be shifted around to ensure that there's a good mixture of different enemy types  

Have you had any thoughts on how you'd like this thing to look? I can run with the flat-colour-simple-shapes aesthetic in the player concept if you like it; I'm a little rustier at pixel art but I'm game to have a go.

I've often drawn sprites larger than required and shrunk them down, which to pixel-artists is like kicking a cute puppy Certainly drawing at 128x128 directly is probably a better idea than shrinking a 256x256 image, if only because nobody will get to see the original, only the algorithmically shrunk version   But I'm not very good at drawing stuff that small - so it really depends on how you are.

As for shading: when I do "real" pixel-art I tend to stick to just line-art, colouring and highlighting (wish I'd had this to look at when I started). I don't bother with dithering or anti-aliasing by hand since it's really time-consuming. This gives everything a rather jagged, cell-shaded look, but I actually quite like the high-contrast, high-saturation colour-blocks aesthetic (rather like a comic-book).

So yeah, I do really like the style you went with for the main character, it's just a matter of how it'll look at about 128x128 pixels. That's the tricky part. Wherever shrunk-down or pixel-arted doesn't matter in itself: whatever works better for you is probably a good option, even if it's not the most "orthodox" way.
Inoltre, personally I'd prefer more simple frames rather than less high quality ones. But, as always, that's your call  

[Toom]

I really like the idea of the Segfault as a sniper class.

Stack/Buffer/Arithmetic Overflow



Still a ways to go with this guy, I think...something's missing. I had an idea about how his attack could work that I'll try to diagram for you.

The other thing I was thinking was that, although I gather that the three overflow types are for all purposes identical, would there be any merit in having them as three classes of the same monster, maybe with similar, but slightly different attacks? I mean it'd be pretty straightforward to do a couple of palette swaps with different "eye" gauge configurations or something.

[wilbefast]

  Epic win!!! Love the little pressure-gauge eye   edit: missing something? Exhaust-pipe horns maybe? 

Make sure you save all these concepts somewhere: it would be a shame to waste them, and I was thinking we could perhaps have a little in-game "Buggerpedia": sort of like the "Pokedex", with a humorous description of each bug/weapon/character you've encountered. Not wanting to get too ahead of ourselves or anything...

Variations might well be a good idea - they mean more types of enemies with almost the same number of assets used: same AI and logic, slightly different attributes, maybe a recoloured sprite - it's win-win really Course everyone would rather more distinct enemies than variations of a given class, but more enemies in the absolute is better, whether they're similar or not.

---

Okay, so the segfault because a Sniper (they do rather tend to kill programs without warning...). We still have a slight lack of low-level ranged enemies. Maybe the overflow(s)' "memory vomit" could be, well, projectile-vomit

What was your idea for the rounding-error by the way?

[Toom]

Basically a boiling, seething, puddle-like mass of mouths and stuff - sort of like miniature Shoggoths, but not very threatening-looking. Could be an incredible hassle to animate, but it'd look so boss if I could pull it off, and as small chittery gribblers they don't need to be particularly large or complex.

I'll concentrate on getting the designs and sprites done first, but I like the idea of an entity directory; I'll do some more polished and dynamic versions of all these when the actual game graphics are finished. It'd be far too easy for me to get distracted doing these and end up rushing the important bit.

[wilbefast]

Good one - that works "numeric instability"  I actually did a basic first pass of the Overflow a while back:



Your concept is way cooler IMO, but the point is you'd be surprised how easy it is to animate an amorphous blob 

[Toom]

I've got some more ideas for the Overflow but I'm keener to get these designs out the door before I start refining anything. On which note, here's what I got for SegFault:



Rendering quality is all over the place (which is to say, "complete shit on the arms and tail"), but I'm pretty goddamn pleased with that design, I have to say. The railgun arm thing needs work, though.

[wilbefast]

edit: New video this is me talking about some of the new stuff that's been added. There should be a download up on indieDB some time this weekend!

---

Coolness   I ran into a lot of segfaults while setting up the memory management architecture, and your personification is right on the money - bravo
So: I'm thinking this guy could spawn a little red laser-targeter which would follow you around: stay still till long and he'll get you in his sights and fire. I have this guy down as a flyer, which should help him keep out of range. He could also stab you if you came too close.

Type	Name	Ranged?	Combat?	Flies?	Wanders?	Flees?	Chases?	Notes
Fodder	"Rounding Error"	No	Yes	No	No	No	Yes	Shoggoths
Fodder	"Floating Point"	No	Yes	Yes	Yes	No	Yes	Charge attack (Doom lost soul)
Mid-range	"Overflow"	Yes	No	No	Yes	Yes	Yes	Attacks/death create lava
Mid-range	"Infinite Loop"	Yes	No	No	Yes	No	No	Continues firing until interrupted
Dangerous	"Segmentation Fault"	Yes	Yes	Yes	No	Yes	Yes	Sniper sight

The pattern here is for high-level enemies to be ranged and low-level ones to be combat, but then I suppose that makes sense because projectiles are harder to avoid combat attacks.  Still, if the Loop was combat we'd have something more balanced, and one archetype that we don't have on the board yet is a combat attacker that moves towards you while firing projectiles.

Don't worry about the image quality. Since these concepts are just first-passes they don't need to be perfect. Quite the opposite: they should be fairly quick and dirty since all they need to do is to give us some idea of what the final take might look like.
Even so, they might be a cool sort of thing to post on various blogs/pages to show people that there's progress in the art department   let me know if/what you'd be happy to have displayed.

[Toom]

A fast, high-damage melee enemy can be exceptionally dangerous, though - they're larger than projectiles, which makes them harder to dodge in tight spaces, and they can track the player, which I'm assuming most projectile attacks won't.

Looking through that list of exotic bugs you linked me, I was struck be an idea for a high-level enemy, but I don't know how easy it'd be to code its behaviour. How would you feel about including a Heisenbug, possibly - due to how much of a pain in the arse it'd likely to be for the player - as a miniboss? It'd keep a consistent graphical appearance, but would switch between other enemies' behaviours as you attacked it.

[wilbefast]

It's true that, thanks to its charge attack, the FPE become a sort of pseudo changed enemy. I could have it have them keep their distance till ready to swoop and then dart away when they're finished 

The full list of possible bugs started off looking like this:

Level	Name	Ranged?	Combat?	Flies?	Wanders?	Flees?	Chases?	Special
Fodder	"Rounding Error"	No	Yes	No	No	No	Yes	NONE
Fodder	"Floating Point Exception"	No	Yes	Yes	Yes	No	Yes	Charge attack
Medium	"Overflow"	Yes	No	No	Yes	Yes	Yes	Attacks/death create lava
Medium	"Infinite Loop"	?	?	?	?	?	?	?
High	"Segmentation Fault"	Yes	Yes	Yes	No	Yes	Yes	Sniper sight
High	"Dead Lock"	?	?	?	?	?	?	Paralysing attack
High	"Race Condition/Starvation"	?	?	?	?	?	?	?
High	"Desynchronisation"	?	?	?	?	?	?	Freeze (become invulnerable) and/or teleport
Rare	"Bohrbug"	?	?	?	?	?	?	?
Rare	"Mandelbug"	?	?	?	?	?	?	?
Rare	"Heisenbug"	?	?	?	?	?	?	?
Rare	"Schrodinbug"	?	?	?	?	?	?	Friendly unless attacked
Boss	"Flying Spaghetti-code Monster"	Yes	No	Yes	Yes	?	?	?
Boss	"Kludge"	No	No	Yes	No	No	Yes	?
Boss	"Bugger"	No	No	No	Yes	Yes	Yes	Summons enemies
?	"Millenium Bug"	?	?	?	?	?	?	?

NB - Bohrbug's and Mandelbugs aren't well defined: they're basically just "complicated bugs". I had them down as generic, tough enemies, probably one ranged and one combat.

I cut it down mostly because of the amount of art assets that each one needs: the code is fairly reusable and can be generalised for as many enemies as necessary. Indeed, the only thing that needs to be specifically coded is whatever is in the last column 
So I'd be more than prepared to encode special behaviours for as many bugs as you want to make sprites for

Speaking of which I had a thought: if we want 4 directions, better to do NE and SE and then mirror them to get NW and SW. N and S can't be mirrored so aren't as worthwhile when you think about it 

[Toom]

The Millennium Bug should look fucking terrifying but not actually do anything.

[Toom]

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).