People really need to stop treating this as a trolling attempt. His posts are underlined by a very recognizable delusional kernel, if you know what to look for.

Comparatively, while bvanevery did have a very defensive and confrontational personality, but at least he did not at any point mention the freemasons or the Illuminati.

It is most certainly not intentional trolling.

Wow.
Awesome pixel art tiled terrains.
Awesome pixel art tiled terrains everywhere.

Hey, sweet, this guy lives somewhere in my city.

Perhaps I should track him down and slap him with a trout or something, while wearing fake mustache and a tophat, and saying "consider this a final warning from the Illuminati/TIGSource coalition" in a husky voice.

Make your AI scripts external, they said.

Write your own interpreter, they said.

spent 30 minutes debugging the audio code ... only to realize that I had ear phones plugged into my iPhone.

Well, you can take solace in the fact that story just made my day.

Got this from my currently unnamed pixel gorefest (click):

Not much going on right now and photobucket's resize feature possibly mangled what few details there are, but at least you can see the lighting system and the persistent bloodstains 

I am very happy right now because I coded a working game prototype from scratch in 10 days.

I somehow managed to produce several fully functional features I've never tried to implement before without encountering major headache-inducing bug hunting sessions. Features like render-onto-terrain for permanent bloodstains, a control system that tracks keyboard input for button combos (doubletaps and the like), some nice item classes, a game action/event manager to bind it all together, and a scripter/parser that makes it all function from .txt files.

And this time, it's not ugly hacks, either! 

[Last Stand of 8-Bit]

"Seeing Red" is the best out of those, I think. But you probably need something to bring images of pixels...
Probably a title involving:
8-bit
Pixel
or anything else related to pixels.
How about Last Stand of 8-Bit?
Or perhaps Pixel Massacre?

I know, the very reason I am having problems with the name is that I want it to be silly and brutal at the same time, so it's kind of schizophrenic trying to come up with a name.

As for your game, personally I think Bitrocket would be a great name for a game of that description - if it weren't for the problem of the already existing program of the exact same name. My first advice would be to change it slightly, such as to "Bit Rocket", or something - but to be honest it might still cause some confusion. "Two Bit Rocket" comes to mind but it might not fit in depending on the atmosphere of your game. Perhaps something with "Boost" in the name?

Seeing #FF0000

Heh. I think I'll name the red pixels' country FFOOOO.

Al right, I have a suitable challenge for you.

An endless survival game where a single (a bit oversized) blue pixel with a sword and a shield takes a last stand against increasingly numerous and powerful waves of various red pixels, massacring throngs of enemies and splattering the battlefield with persistent pixel, erm, blood, which is also red. Don't ask me how that works.


Names I toyed with so far:
Pixel Quest: the Rise of Shnixel
Pixels WERE harmed
Seeing Red

But I draw that line much lower than others--I've never even considered using Boost, and I've even abandoned STL in my current projects.

Oh, dear God, do I know what you mean. STL may be very useful, but also incredibly ugly, which for me at least makes programming a more tiring job. I either roll my own containers or, if I feel like cheating, wrap STL ones into a more readable class. It might be inefficient and to some a wasted effort, but my take on that is when you're going to be staring at your code for hundreds or thousands of hours per year, clarity of code and using the code YOU wrote and know every byte of, tends to makes you a lot more productive.

That said, everyone should write at least one graphics engine. After that, even if you switch to an already existing one, you have invaluable experience.

It's not even computationally expensive, it's just a multiply and a divide:

Code:

radians = degrees * (PI / 180.0f)

Furthermore by precomputing the pi / 180 and 180 / pi values you can do both conversions with a simple single multiplication. Which is an extremely minor price to pay compared to the comfort you get from working exclusively in degrees, and just converting when an external library or a shader needs it.

tried this out a few years ago and the basic game worked pretty well (I just executed it poorly back then).

Once when brainstorming with friends we came up with "Imagine a platformer with a text adventure interface! Super Mario meets Zork!" Then we all laughed and concluded it was too crazy to ever work.

I am glad there are people out there who can challenge such negative nancies as we were and make awesome stuff like this happen.

And junkboy, you have motivated me to become a millionaire, just so I can some day turn up with a wheelbarrow of cash at your doorstep and say "here. funds. now make that damn game."

@TheZorg, sign me up on the drooling bandwagon. 
Have you played the original "Wolf" game by Sanctuary Woods?

Is the blue stuff animated? Because it should.

Well everything is blue...ish. If you're asking about the buttons or the stuff on the letters, then yes. In fact, everything is animated (cheap particle effects) except for the mountains and the citadel in the background. It's supposed to be a snowstorm.

That, to say the absolute least, looks ridiculously awesome.

Many thanks! I was worried that it would be too obvious I shopped together several Earth-based landscapes. The mountains need to be flipped due to shadowing, at the very least, but I'm pretty happy with my newly acquired GIMP-fu myself.

[should]

Decided to spruce up the title screen of my current timewaster:


I should have spent the time fixing bugs in the actual gameplay, but I've always been a sucker for a good title screen.

Whoa, this was a long read. With unexpected amounts of vivid pornographic imagery in the latter half.  

There is one very important thing that needs to be determined here. Does bvanevery's presence disrupt the community? It doesn't matter if it is a small population of threads, if he severely sidetracks discussions in those threads to the point of muscling other posters out of them - posters, I'd like to emphasize, who usually take time and effort to participate in a discussion in a civil manner - then there is really no reason for the community to tolerate it.

If the argument against banning him is that he provokes interesting thoughts, then we should take into account all those thoughts that will remain forever unprovoked because people did not have the mental stamina to keep up with his aggressive and disruptive posting style and just bailed the threads.

I am not here to wave a virtual pitchfork. It is of little consequence whether or not one bvanevery gets a formal ban. What matters is whether or not he has the capacity to harm the community if he is allowed to keep posting - if his posting privileges, if you will, are not removed. And in my book, thread derailment - nonconstructive, confrontational thread derailment - harms the community. Therefore I voted yes.

People act as if the ability to post on tigsource is a constitutional right. Well, it is not. It's a privilege. And it's very easy to earn - all you need to do is fill in a registration form, not be a spambot, have some vague connection to or interest in indie games, not post child pornography, and try not to turn random threads into flame wars too frequently.

That said, if a ban seems like too radical a measure for any reason (let's say, because the offender might yet learn to integrate into the community), then a suspension or a probation period or a similar temporary measure might be better suited.

I am happy because hexes are awesome and easier to work with than previously advertised, programming-wise.

Also because an ounce of code can save you a pound of bitmap work.

There really is no "right" and "wrong" way to do this. Just make it so it's clean, easy to use code and do what ever works for you.

I found it is good practice to always preload all your assets (except music, which is probably better off being streamed real-time) on game init or level load. There is really no reason not to do it, if you're not making an AAA title texture memory space is virtually a non-issue.

However, I'm trying to determine how to manage all the sprites in the game's engine. For instance, when an enemy is spawned, how will I define what sprites it should use? Is it a good idea to have a manager of some kind that stores all the sprites by name, so I can call on it from there?

I can't tell what would suit you the most, but, it would probably make your life a lot easier if you had some kind of "manager" if that's what you want to call it, which would handle textures, texture loading, unloading, and access for you. I personally do it by having a "graphics manager" class which loads and stores all textures internally. This manager is part of a framework I use in all my games.

In game code proper I usually define "entity blueprints" which among other things define stuff like, for example, maximum hit points, max movement speed, and which textures are used for sprites. A single blueprint can have multiple sprite layers, and for each layer I define every tidbit I need, such as texture ID, blit regions (if multiple sprites are tiled on the texture), alpha, colors, blend modes, animations, etc.

When rendering an entity it looks up its parent blueprint and gets all the info about sprites it needs to render and how. All the entity itself provides is where to draw it, rotation offset, opacity override, and animation sequence (if any).

As well, on a different topic, should enemies with different behaviours have different classes, or is there a neater technique for dealing with all of that?

What ever floats your boat. If "different behavior" means slightly different pathfinding or something like that, then most likely the answer is no. If it makes you feel any better, I have looked through the code of Source Engine games such as Half-Life 2 and Alien Swarm, and in them, every single enemy type or weapon is a separate class.

The most reasonable solution, one I implement, is to have separate classes if you really need them, but all of them derived from a single "entity" base class. That way you get the best of both worlds - you can make each class do its own stuff internally, but you can store, reference, and pass the objects around like they are all of a single "entity" type.

I mean, if you're going to use c++, it makes sense to make use of its more powerful concepts such as inheritance.

This.

Thanks for the feedback, guys.

Yes, there are other ways, this is just how I do my glow because since it doesn't affect the main sprite the glow can be pulsating and scalable. I understand making a whole different sprite for the sake of glow can be a bit too much hassle for some who just want to get to the down and dirty.

If anyone has any more tips, please, do share them.