next »

[DrDerekDoctors]

Bog off, bumface.

[happymonster]

Boohoo! 

[DrDerekDoctors]

Progress Update (for Monday, as I've felt like shit ever since):

Added linking/tying of entities.

Linking basically allows very simple logic flow to be put into the game easily. Effectively you link one entity to another (like a switch to a platform) and the link itself contains data which says which settings of the platform it enables/disables as a bitflag and whether they're altered permanently or just while you're in the room. This means to save the state of 95% the game, all I have to do is save a single integer for each entity instead of having differing save functions by entity. Lovely.

Ties are just physical ties. Like if you have a turret-style enemy you can stick it to a platform's underside so it tracks with it.

Next up: Um, ooh, not sure.

[Ishi]

Player entity?

[ptoing]

Player entity is already there, as a pink block.
I am not in my normal workspace atm since there are renovations going on. But once I am back and have proper space I will start to do some concept art for monsters and of course the player as well. For now Mr. Magenta will have to do.

Animation/Enemy editor?

Big Scanline mockup
Tho our scanlines probably wont look as funky as Graham does not feel like shaders :B (can't blame him)

[Thomas Finch]

I want to play this. O_O

[ptoing]

Chances are good you'll be able to, sometime in the future (as Graham said, late 2012 seems possible, perhaps early 2013, or when it's done)

[lasttea999]

This all looks so cool, particularly the editor stuff!

[DrDerekDoctors]

Hullo! Long time, no post, partially due to being extremely busy with my quadruple obligations of having to uncover a world-wide conspiracy around the augmentation industry, ridding an island resort of the undead, my ongoing struggle with ringing the two bells of awakening and going to Fantastic Fest in Austin, Texas (OK, three of those four obligations are *technically* in videogames I'm playing, but bite me) . Anyhoo, I thought I'd post a little update with a couple of tedious editor screens (trust me, the screens should start to get a bit more interesting soon).

First a bit about animations.

Animations in Phantom Island are all of type "Parent" or "Child". Parent animations are assigned an Action ID (which says what the purpose of the animation is - i.e. Player_Walk_Holding_Weapon) and an optional Entity Type (which says what "thing" in the game the animation is associated with, player, enemy, object, etc). Child animations have the Action ID as well, but the Entity Type is not optional as all "Child" animations are for specific wielded equipment. By knowing what the equipment is, this allows us to know where it is equipped on the entity wielding it (not necessarily the player), the reason for this will become obvious.

http://www.drderekdoctors.com/phantomisland/animation_editor.gif

Here's the animation editor itself. With shockingly poor programmer arty bits which will mortify Ptoing.

It's dead simple, really, allowing you to just create layers and either assign sprites to them, or assign an equipment slot to them (for instance "near hand") whereupon it automatically fills in an appropriate graphic for you (by looking through for a suitable Child animation which has a matching Action ID and whose entity is equipped in said slot). I should point out that it's not a full paper-doll rotationey-linked animation thing as that's not the visual style we're going for. It's just like a stack of transparencies stuck on top of each other (even so in most cases this'll be like 1 or 2 sprite layers and then the equipment slot layers), but it should still make testing all the combinations of animations a lot easier.

This is basically to make it as simple as possible to have squillions of weapon types without having to have different player animations set up for all of them. Ugh! And by having all this metadata built into the animations it also makes it really simple to pick suitable animations in the code without having to manually link up all kinds of guff. I'm sure you don't really care about that but I wanted to make it clear why it's taken longer than is reasonable to design and write this crap.

As well as the graphical information, on each animation frame you can place a sound effect, add particles or add attachment points. Particles are exactly what you'd imagine, it simply spawns a particle (either in front or behind the sprite) at that point and then the particle continues autonomously.

Attachment points are used for other stuff such as if the player is carrying an object (not wielding it, mind, carrying, as it remains an autonomous separate entity whereas wielded equipment is essentially a sprite with metadata) it tells the object where its origin should be so it can track with the player's hands, but if there wasn't an attachment point the carried object would automatically be dropped (for instance a walk animation would have an object attachment point in it, but a hit-recoil animation wouldn't). Or an attachment point could be of type "drop money" so on that frame of the animation the sprite would create a coin (for a thief when you hit him, for instance). In fact, all kinds of instructions could be mapped to these points (Put Away Object, Get Out Object, Use Object, Fire Spell, etc).

You can also specify an arbitrary number of collision rectangles for each frame. These are not for colliding with the world - that's in an entity's basic properties - but for dealing damage to other entities. For instance as a sword sweeps down it would have a rectangle that broadly tracked with the sprite which would then hurt enemies it overlapped with (and because animations are linked to entities, it would know what kinda' damage to inflict to them).

http://www.drderekdoctors.com/phantomisland/particle_editor.gif

And here's the particle editor.

I'm just putting the finishing touches to the particle editor (by which I mean it's a bit broken at the moment). Particles are pretty simple sods whose behaviour is determined by that big list of properties over on the right. As you can see a particle can spawn other particles (one type for during its lifetime and another for when it gets to the end of its lifetime). This allows the user to create dangerously recursive particle behaviours which will bring the framerate stuttering to a halt. But it also means they can create quite pretty effects fairly simply. Especially as particles can be set off in a specific order and pattern in an animation to get just the right look, while having slightly randomised properties so it doesn't look like the same effect every time. Like animation frames, particles can also have a collision rectangle in order to inflict damage, again by referencing an entity type for the details.

Next time I'll talk a bit about the various game systems, although it might be a little spoilery so I'll mark bits of it accordingly. The last thing I want to do is ruin the delight of seeing what interactions the game allows you.

[:^)]

Yay! Glad this is still moving.

[Belimoth]

I am in love with your editors

The game thing doesn't look half-bad either.

[happymonster]

Still alive?

[DrDerekDoctors]

Yeah, absolutely. Just getting the basic player movement nice and solid, climbing, wall-jumping, slopes, ice, etc. Been making it so the player can wall-climb on moving platforms for the last few days but tbh, it's been a pain in the arse as it's pushing them through walls and some other crap I need to debug. Blergh. Still, I think it'll be a cool feature once it's done.

[DrDerekDoctors]

Just a post to show that we ain't dead.

Coupla' rather dry looking screens (Ptoing is busy with paid work and other stuff at the moment, which is actually kinda' cool because I get to be the one making progress rather than lagging behind as I usually do).

First of all this screen shows various types of blocks as I've been implementing some of the simple tilemap and gameplay elements. One thing to note that each of these block types isn't a special case, they're all generated by boolean properties so a tile can have many different combinations of properties.



1. This is a ladder. I know! AMAZING! Actually, it's an omni-directional climb surface, true vertical climb surfaces are a bit later.

2. The blocks with arrows on are 1-way blocks, as in the classic jump-through or drop-through tiles. We also have horizontal ones of these, however they crash the game at the moment. I haven't told Ptoing that yet.

3. The player. Honestly.

4. This is the same as the ladder except it looks a bit more trellisey. As it stands when you're climbing on these surfaces you are "stuck" to them, which is to say when you attempt to move off the edge of them, the game stops you. You can press jump (or down+jump) to detach, but I'm toying with the idea of making it so if you HOLD down a direction at the edge, you'll fall off after half a second. In case you're wandering how you get off the top of ladders automatically if they're sticky, the top of the ladder has a boolean property which overrides this safety net on the vertical axis.

5. An icy slope. This combines two things. Firstly these tiles have an accelleration value on them, reduced friction and reduced traction. Secondly they have an icy boolean property on them which causes the player to "fall over" if they're going too fast.

6. Crumbly platforms. Stand on 'em and they dissolve.

7. The edge of the room. I finally added movement between rooms today, see.

8. Slimy platforms. You can't wall-climb these. You can ledge-hang on them, though, although only for a second.

9. Smashy glass. When you land on it, it breaks with the shatter spreading to any touching glass tiles.

10. Sticky tiles. These have a stickiness value of greater than 0%, meaning they stymie your speed. All tiles have friction, traction and stickiness.

11. Smashy wood. Just like the glass except the spreading is instantaneous when it smashes.

12. A thin passage to wall-jump up. At the moment we have three forms of wall-jumping (which the player will get at various points in the game in order to change the areas they can get to). Firstly, slidey which means you continually slide down when attached to a wall, requiring you to keep jumping between walls to maintain or gain height. This still allows you to get down otherwise perilous drops. Secondly grippy, where you don't slide down so you can take your time a bit, allowing you to drop down passages which might have timing hazards or enemies in them unscathed. Finally climby, where you can actually ascend the walls, allowing you to climb up vertical faces which don't have opposing walls which you'd otherwise need to gain height by jumping between them.

13. A horizontal climb bar. Just like the trellis, except it clamps you to a vertical offset within the tile.

14. A vertical climb bar. Duh! (no, it's not a swingy rope, but we'll prolly have some of those kinda' shenanigans in there, too).

15. Another crumbly platform. This one combines a few elements, though, in that you can jump up through it, it also chain-reacts meaning that the whole length of it crumbles as a single unit.

There's still a few features to add to the tiles, mind, such as flammability and bounciness. And whatever else I think of.



And here's a shot of a very boring room with some large moving platforms in it. As you can see, the player is holding onto the side of one of them, which will allow us to make some jolly thrilling platforming action, you mark my words! He's able to do this as the game considers moving platforms and the static tilemap as largely the same thing.

In fact each moving platform gets its basic properties from a specific tileset. That means a moving platform can have almost all the abilities of a tile in the static map (with notable exceptions being non-rectangular shapes, jump-through-ability and chain-reaction damage).

I built this room to just test whether platforms could push you out of wall climbing and trellis climbing states if they pushed you off of the surfaces cleanly, which they do. Thankfully.

[stef1a]

This is beautiful. I adore the cave ambiance. 

[DrDerekDoctors]

This is beautiful. I adore the cave ambiance. 

You're looking at the same shitty screenshots I am, right?

Cheers, but this is all horrible placeholder. Once Sven works his magic it's gonna' look "reet gradely" as they say in Yorkshire.

[happymonster]

So you're remaking Manic Miner? 

[Ben_Hurr]

The orange tiles are a big improvement over the orange + blue, even though I liked those originally.

I'm not a big fan of the dithered lighting, it just makes the crisp graphics look rather messy. I wondered how it'd look with some subtractive blending:



It has the effect of removing a lot of the detail of the environment, the same as the dithering does, unlike a standard blend which would just make stuff darker but no less clear. It works quite nicely with the strong highlights on the blocks. Thought I'd show it as people don't tend to consider different blend modes, although it doesn't really fit the pure pixels style you've shown so far.

A bit off topic, but I'd sure like to learn how to do that effect. 

[Ishi]

A bit off topic, but I'd sure like to learn how to do that effect. 

I used subtractive blending, which is: FinalRed = OriginalRed - BlendRed * BlendAlpha (and the same for the other channels). The result is clamped between 0 and 255, so dark original colours will turn pure black easily, compared to standard alpha blending where all original colours only turn black (or whatever the blend colour is) when alpha is full.

So to darken something using subtractive blending, you actually use white as the blend colour, as it subtracts the largest value. Notice that the hue of a colour can change as well, for example the tiles in the example pic become red when they're at half brightness, because the green and blue channels have already bottomed out at 0.

Google should provide the actual implementation info (that example was just a layer blend mode in GIMP).

Back on topic..

In fact each moving platform gets its basic properties from a specific tileset. That means a moving platform can have almost all the abilities of a tile in the static map (with notable exceptions being non-rectangular shapes, jump-through-ability and chain-reaction damage).

The platforming in this sounds great; very fully featured. Out of interest, why doesn't jump-through work on moving platforms?

[DrDerekDoctors]

In fact each moving platform gets its basic properties from a specific tileset. That means a moving platform can have almost all the abilities of a tile in the static map (with notable exceptions being non-rectangular shapes, jump-through-ability and chain-reaction damage).

The platforming in this sounds great; very fully featured. Out of interest, why doesn't jump-through work on moving platforms?

It's simply because at the lowest level platforms and tiles work a bit differently. Platforms are considered solid from all sides, whereas tiles are selectively solid on each side and, effectively, heightmaps.

Tbh, I could probably easily add jump-through functionality to the platforms. Just need to tweak the criteria by which it pushes things so that it doesn't push anything which is overlapping with it already. Sod it, I may as well.

Although that'll be after I add the water to the game, which is what I'm doing at the moment.