@08 - I agree with Dan, though my fav bit is the lower left cause its something new :^)

Agreed. I like that pixel-work, though I find the ground distracting a bit. You could make it get darker as it gets further down, or add black in there or something, perhaps?

Trying out something new. Also, NES palette.

This is quite cool! I think you could add some tiles to present the other side to the tiles (since that's the angle that your character is turned, but I like the simple shading and somewhat desaturated colors.

@skittle - The eye's not bad, but I think the "blur" shouldn't happen until it clamps down. It feels like it's blurring when it opens and closes. The character looks cool!

The grass objects consist of invisible cubes with visible planes that have a grass texture on them. I move the top vertices of the plane using a sin() function to get the feeling of blowing in the wind. That sine wave is offset a bit randomly for each grass object to give that uneven windy feel.

If the grass objects come into contact with a bullet or come near an explosion, then I add a value to a force variable that adds an extra push to that sine wave. That force ramps down over a few frames, which gives it that "strong sudden gust" feel from an external force.



I spent a lot more time than necessary trying to hunt down a bug, but I (hopefully) managed to make the door system work between scenes. This was pretty much necessary to do since I wasn't gonna build the entire game in a single scene. It should be a slight loading process in the transition between scenes if you haven't visited the scene yet (around 4 seconds or so). I think it only takes that long once, though (unless the BGE frees the resources, which it might if it needed to). Anyway, doors still work between each other in the same scene as well, which is good if I wanted to allow characters to move through doors (though I doubt I'll implement that, now that I think about it).

I refactored the way the screen filters were taking effect and am making use of a single scene for it now rather than trying to cram them in with the object, which makes it easier to see and deal with. I was using an entire render to texture method to render out the game scene to a texture to blur on the pause screen, when someone at the BlenderArtists forums reminded me that Blender's screen filter system works on the current scene and every scene below that. So I just push the shader onto a camera (doesn't really matter what object it is) that's above the game scene (but below the GUI). It's working quite well so far. A nice, modular solution to offset the horrible non-modular rest of my code where the player and other stuff can be accessed globally but it's a different player reference between each scene and aaaaahhh

I've gotta find a better way to "encapsulate" things...

Gotta be careful of my FPS now that I'm getting into shader work and stuff, but I have a couple of ideas of how I could speed things up a bit as necessary. I hopefully will be able to maintain a nice high FPS value.

Anyway, progress continues.

The run cycle's a lot better. Those are some really slick tiles, too, though I think they're too bright. I like the BG, too.

This is pretty cool! I like the character mechanics - moving the wheels around seems pretty slick. Are you alternating between them, or controlling them at the same time via dual analogs?

Also, are you going to add spikes to the room in the end of that video, or is there falling damage? Because it seems like you could easily just fall down to the "cage"...?

Heh, thanks, you guys.

I tweaked the Bloom filter to only affect brighter areas. I've tried this before, but I think I did it correctly this time. I used to use a luminance calculating function to compute overall brightness, but this would fail on certain colors that actually would be pretty bright (like red). Now I'm just getting the maximum value between the three channels, which is enough to tell what should be "Bloom"-ed and what shouldn't. There used to be a noise function tied in to make the bloom more interesting to look at, but I can't really get it to work with the shader since it's selectively blooming stuff, so whatever.

This makes it more even overall for certain bright things to bloom (i.e. not the trees), but I think I'll have to recolor some things (i.e. the backgrounds are now pretty dark).

Added an ability to set the pitch of the played back "beep-beep-beep" noise when you're talking to an NPC, so small characters can sound all ^beepbeepbeep and big characters can sound all beepbeepbeep. Also added the corresponding function to my event system.

It's smooth and well-drawn, but it's kinda weird.

Her feet feel like they're traveling completely side-ways rather than at this 3/4-ish forward perspective that she's drawn at.

Also the complete lack of body movement up and down kinda makes it look weird.

Getting embarrassingly late to party here, but this didn't yet work when I was leaving to sleep yesterday.
Experimenting with polygon-based directional lighting for a particular collab game:
"Polygon-based" part here means that light and shadow areas are calculated programmatically before drawing them, as opposed to more common methods with drawing stretching shadows from objects to surfaces.
This allows doing some very interesting things, such as detecting precise light levels at points or having lights bounce off the surfaces realistically.
Also works amusingly fast on Flash, HTML5, and native.

I was totally seeing this as a polygonal cutout that looked like a few buildings and wondering what's so special about it. Now I see the light's coming from the top and casting shadows toward the bottom. That looks pretty cool, and the applications sound great, too.

@TBE - LOL What.

@Jad - That's really cool pixel art! His pants are super wrinkly, which is a bit odd, but otherwise, really nice work. I think you could have enough room to add actual eyes as well, but I'm not sure if that's what you wanted or not.

Not a huge fan of the Superbrothers' propotions and pixel art style, but it worked well for the game, I think.

Spent a lot of the weekend learning about Godot. It's an interesting engine for sure!

I'm working on making the village actually look nice. It's funny; now I have more ideas for how I want this to look.



Anyway, I'd like to implement some mechanics and get some important stuff done soon.

^ That is a good deal, especially since you only have to pay once to have and use it without any updates.

I've been taking a look at Godot. I really like what I am seeing so far, and the biggest thing is that the issues that I see are potentially easily fixed with a little work. I'll be exploring it further.

I've been working with it, too, and it's pretty nice. Kinda awkward in some respects, but it's lightweight and has a nice amount of features built-in. Cross-platform, too. The scripting's a bit weird as it attaches to Nodes and can extend from other scripts), but it's an interesting approach.

I don't quite get what you mean. Why not have a dividing line for ranged attacks on cells further than one cell away, and no dividing line for attacks between neighboring cells?

Nice animations, also.

I was sort of wanting to emulate the advance war's way of dealing with combat:



In the context of the screenshot, both units are right next to each other but are on differing terrain types. The same applies in my hypothetical game, both units wouldn't necessarily be on the same terrain type, and i liked the way they dealt with it. Mine's more pronounced however.

Hopefully that makes sense.

Ah, yeah, I was thinking about the different terrain and thought that it might be possible to draw them both on the same screen with blending between the two terrains, though that'd be a bit of work to do. Maybe melee units could automatically be displayed on the same terrain as the defending unites, since they're attacking.

The break works fine for ranged stuff, but it seems a bit unnecessary and odd for melee weaponry.

@noumenus - Every dang time Delicious posts we get that joke. It's so stale and bland, it's ridiculous. Please post more tasteful jokes in the future.

I don't quite get what you mean. Why not have a dividing line for ranged attacks on cells further than one cell away, and no dividing line for attacks between neighboring cells?

Nice animations, also.

@Ingenoire - Those are pretty cool sprites, though the girl's hairstyles are pretty similar. Maybe you could push them a bit more to make them more different?

@Delicious - Really nice pixel-work, as always!

i bought rpg maker

You bought it from Humble Bundle? It's a really good deal there.

Didn't do much today either, but brainstormed some cool ideas for parts. I have a pretty good variety so far, and some have both combat as well as puzzle uses. So, I should be able to have multiple sources to get parts from (like purchasing some non-essential ones vs. finding others in the field), which is nice.

I sprited up a couple of bodies for mock-ups, and I like the general feel of them so far, which is cool.

I'm working a bit on the village, which is a bit hard to visualize, as it's all supposed to be contained in this large facility. So, I need to do some thinking on that to make it look different as well as structurally interesting.

Things are looking pretty cool! The missile looks pretty intense to avoid - will you be able to shoot any yourself as players?

I like that you're putting a lot of thought into the multiplayer facet of the gameplay. Is this going to be purely multiplayer, or singleplayer as well?

I've no experience with large numbers of joysticks on a single computer, but I'd think it would handle okay.

The companionship thing is pretty cool. I think you would do well to rotate the character sprites depending on their facing or movement direction to help them be more dynamic, but I'm sure it's still a WIP.

I like the original blue chip as a player sprite more as it had a bit more character and interest about it (because of the eyes and simple, identifiable shape). The current sprite's okay, but it doesn't really look like a player.

Anyway, it's nice to see you've got stuff turning out so well so far!

Wow, that's really impressive, and that engine page is super slick! Nice work on both. This makes me feel like getting into Love2D and Lua, haha.

The visualization of the barrel's effects on the blocks is great, too. Really helpful from a design perspective, I'm sure.

Anyway, nice work. Keep it up!

gif of the first room of this snow level. I also noticed two bugs with it 
[really minor bugs but]

Hard to tell what can hurt you and what can't there.

Really? I don't see any issues with it - all of the white characters are enemies in the foreground, and the dark gray characters are in the background, right?

@ANtY - Really nice animation. Is that energy shield an animation too, or is it a shader or something?

@romain - That sprite reminds me of a devlog that was on these forums awhile back - it had a very similar style. Are you the same developer / is this the same game?

P.S. The animation's awesome, though the scarf seems to really be going crazy.

@Mono - Hello

@pnch - Thanks for the tips - I'm pretty sure I also want to maintain the pixel scale between elements in the menu. I'll try to remember!

I didn't do much in the past few days, but I did implement a little scripting language for events.

Basically, I have a dictionary (associative array) in Python that will contain all of my events in the game. I also have them indexed by language (like I'm gonna add translation support to this, haha). I doubt I will have translation support as a first priority, but building it in is a good idea, I suppose. I might end up moving all dialogue to another file to make it easier to translate.

Anyway, the event is represented by a raw Python string. I use the shlex module's split function to parse the individual "instructions", or lines in the event. The shlex.split function kicks out the blank lines, creates lists for each non-blank line, and separates the line into elements of a list for every separate word that isn't in quotes. The function does all of this for me, which is really convenient, turning this:

r"""

setfacepic 0 1

dialog "HALT! Or slow down, or whatever.\nWho are you?"

"""

into this:

[

['setfacepic', '0', '1'],

['dialog', '"HALT! Or slow down, or whatever.\nWho are you?"'],

]

Once that's done, I add the instructions to a list. From this point, I just grab the current instruction to be completed, and when finished, increment that counter.

My Parse() function actually executes the code (guess I should have named it "Execute", haha) with just a series of if statements to find out what function was called (what first word the instruction has), and what arguments it was called with (what other words the instruction has).

For example, the dialog function displays a message; the only argument is the message to display.

I also have optional arguments for certain functions (like the wait function, which will wait a specific number of seconds if you specify; otherwise, it will wait for 1 second).

It shouldn't be too difficult to add new functions, which is great.

Nice fire effects! Seems like it might do some spreading already, huh?

I was wondering, were you going to have the ability to change Moonman's color?