next »

[MekaSkull]

Are you doing it all yourself? Sounds really good. Most importantly, it has a fitting mood.
I have a suggestion for the dying sounds for enemies. The door/you shooting/turret shooting sounds all have good impact to them. The enemies dying could use just a bit of the same impact in the beginning of the sound too to punctuate the exact moment they cease to exist.

[joeyspacerocks]

Yeah all by me lonesome ... with the help of some great free packs of sounds of course ...

Yes you're spot on with the enemy sounds - kind of threw them in there so they need some work, plus they visually need a bit more oomph (e.g. the blobby thing should explode slime everywhere to emphasis the squishiness).

It's fun though, matching sounds to things and hearing it bring the game to life.

[joeyspacerocks]

I'm still here! I think this is the longest I've gone without posting, but I'm still here and working on the game.

I took a break over the summer and messed about with Pico-8 to try and regain some perspective and sanity.

It may not have worked, but let's give it a go anyway.

So, here's some bats. Apparently all games need to have bats nowadays.





I'm in the process of trying to bring some organisation to this mess and, dare I say it, plan the rest of the development.

[joeyspacerocks]

Still here. I have entered that phase of development known as "losing focus". I say entered, I may have been here all the time.

Anyway, let's get cracking shall we.

This game will need some exposition. Everybody loves it when games stop letting you play them and start laboriously displaying witty text, one character at a time. Bonus points if accompanied by an annoying beeping noise. So I don't see why my game should be any different.

Given that I don't understand what's going on most of the time I figure that the player won't either, and will need a bit of help. Plus it gives me an outlet for my razor-sharp wit and powerfully emotional storytelling.

Dialogue then!

Here's a nonsense mockup.



Trying to decide how best to do conversations. Some people will probably say "not at all", but hey ho. Might be clearer to close a box and open another one when the participant changes .. not sure yet so will have to play around with it.

To achieve this I've fleshed out my font stuff to provide for multiple fonts (obviously robots and the like would "talk" in a square font), and also to render using proportional spacing between letters. This was fairly trivial - when I init the fonts I scan the glyphs to detect their width and use that when rendering.

So now I'm busy setting up the script and dialogue containers in the code plus the rendering stuff to make it look more interesting.

Once all that is done I'll figure out how to make it all skippable. The last thing I want to do is make anyone read this stuff ..

[SolS]

The game looks great, I love the pixel art! Specifically the orange reflections and the overall design of the machines

[joeyspacerocks]

The game looks great, I love the pixel art! Specifically the orange reflections and the overall design of the machines

Thank you!

The dialogue system is in the game at last. It didn't take too much time really in and of itself, just took a while to find the time to do it.

Here's an example:



So there are few things going on here. First I extended the custom UI code I had that handles the menus and option panels to handle more general situations.

Internally I can give the UI elements target display settings and it will tween between its current state and the desired one. This makes having things slide up and fade in, etc, simple to implement.

The dialogue itself is broken into scenes, where each scene can have a number of lines spoken by participants. This is encoded in an XML file (probably should be JSON, but I already had an XML parser coded up) - here's an example for the above scene:

Code:

<dialogue>
    <scene id="start">
        <line avatar="horatio">
            {Ahoratio-talk1}Ooh. Floaty. {P1000}{Ahoratio-talk2}Hello? {P1000}{Ahoratio-talk1}Anybody there? {P1000}{Ahoratio-talk2}Anyone?
        </line>
        <line avatar="mech" align="right" font="robot" colour="11">
            {Amech-talk1}Registering unusual activity in container {C14}#424f4e4553{C11}. Possible malfunction.
        </line>
        <line avatar="mech" align="right" font="robot" colour="11">
            {Amech-talk2}Checking. {P1000}{Amech-talk3}Container error confirmed. {P1000}{Amech-talk2}Filing report {C14}#504f4f4b59{C11}.
        </line>
    </scene>
    ..

You can include directives in the dialogue text, denoted by the curly braces. Currently I can indicate a pause (in ms), a colour change or a request to play some audio.

Text is revealed a letter at a time, with a little read-ahead to ensure that words that will wrap when revealed are pre-wrapped as they appear.

So nothing to special, but it works reasonably well. I need to get a skip mechanism in there to 'abort' the dialogue.

I tried a few different mechanisms to get dialogue to play in a room via different trigger events. For instance, the example above needs to automatically start playing after a short delay. Other dialogue will be shown when other events are triggered - e.g. a collision event with something.

So I've added trigger objects (I'm using Tiled for the room build) that can have an auto-play delay specified, and dialogue objects that keep a handle to the scene id and can be set as a trigger target for a trigger entity.

This way I can slot it into my existing trigger system and it plays fairly nicely.

One last bit of nonsense is to get something to happen when a dialogue scene has finished playing. Here I can give a dialogue object in a room a target object which is then sent a trigger event on completion of the scene. In the example above this is used to break the jar.

So there we have it. I want to add in some polish for the actual display - things like special effects for the dialogue pane (like static / glitches for the mech stuff), and rendering avatar portraits using full game entities so I can animate them and code up special effects like steam, etc.

It'll do for the moment.

Next I'm adding explanation panels for things like powerup collection - got to be careful not to overdo it though.

[Ishi]

Text is revealed a letter at a time, with a little read-ahead to ensure that words that will wrap when revealed are pre-wrapped as they appear.

Extra super bonus points for this, it bugs me so much when this isn't handled properly!

[joeyspacerocks]

Poor neglected devlog. The sparsity of updates suggests that progress on Spooky Pooky has stagnated.

However, the opposite is in fact true. I've actually been making pretty consistent and real progress for the last few months. In fact so much so that I've been skipping devlog updates.

I've a fairly well defined sense of the opening chunk of the game, so I've knuckled down to attempt to get a first pass of that done.

This has required two main pieces of work. The first was the creation of the 'flashback' sequence.

Spooky Pooky opens with our protagonist floating in a jar, memory-wiped (in the best tradition of the genre). Once freed there's a little bit of basic platforming to warm the player up and then the first 'power-up' - the brain.

This is really just a device to trigger a flood of memories, which take the form of a playable section of the game set back when the hero was still a bumbling lab assistant and culminating in the transformation by The Machine.

So, a bit of scene-setting then. I didn't want to open with this as it seemed more fun to play around with the narrative sequence a little.

First up, here's the finished-ish result ... (you can also see the result of the next main piece of work, namely adding some lighting in - I'll discuss that next)



From a technical point of view I've made quite a few changes here. The actual wibbly stuff is all implemented in a single post-processor shader. This combines some radial blurring, some fake bloom and a simple noise function to permutate the edge.

From a structural point of view though I've addressed a few things to get this scene working. This game is being written in C with no scripting language in play, so all in-game events need to be wired up somehow. The maps are built in Tiled with the judicious use of Tiled objects for things like invisible event triggers.

The main tidy up was around entity instantiation during the Tiled map loading. Each entity type now has a pointer to a 'builder' function registered against a type name that's matched with the incoming Tiled data. Additionally I can give any Tiled object an 'event handler' property which is used to match against similarly registered event handle functions.

This is quite flexible and means that I can use builders for common repeated entities (such as platforms, monsters, containers, etc) but just one-off event handlers for things that are only used once, such as in this case for 'scripting' the lift (when you reach the top it plummets and then jerks to a halt at the bottom).

Nice to finally clean that up.

Also seen in the above monster GIF is some lighting.

So the game is called Spooky Pooky. I'm going for a sci-fi horror vibe, all be it with a chibi character approach. I've never been entirely happy with the atmosphere in the game (or lack of it), and have been toying with the idea of adding some form of lighting for a while now.

Turns out that it wasn't too hard to add in, and it does give me some new tools to play with when setting up rooms.

Here's another example of an existing room with some hastily added lighting.



From a design point of view I can now add lights to a room in a few ways. I have a basic 'light' entity which ends up rendering a beam of light within whatever rectangular object boundaries are defined. So I can use those for light shafts.

I also have 'light-source' entities which typically render a visible, glowing, sprite (e.g. an actual light) and a custom render method that renders out a light beam in the appropriate direction. Light can optionally be coloured, or have a few basic effects added to it, such as 'flicker'.

I'll add more as I need, but you get the idea.

From a rendering point of view I ended up making some conceptually biggish changes, although they were relatively simple to add.

The main change is to start using multiple-render targets in the shaders. Previously all fragment shaders just set colours to a single output target.

Now I have three texture targets, namely the main one for texture, a 'glow' (or self-illuminating) texture for sprites that glow, and a 'light' target for the actual shafts of light.

I've also split the source spritesheet texture into two textures. The first is the normal sprite texture; the second contains just pixels that should glow.

So now when I render a sprite the standard blit shader I use outputs to all three targets. Normal sprites output black to the light shader so that I can layer the lights - i.e. have lights that shine behind tiles, or in front.

At the end of the main render pass I then call a light mix shader that takes the main output and the light output and combines them to dim and light accordingly.

After that I mix the output of that with the glow output so that self-illuminating stuff is blurred and artificially brightened.

These things are all achieved by chucking them into my draw-call system with appropriate depths, so it's fairly flexible.

So there we go. Lights. Of course having a technical solution is only part of the problem - now I have to dress the rooms with lights ...

[oahda]

All looks good! Really cool shader.

It never hurts to tell you how impressed I am overall not just with this project also but with your fairly regular updates! c:

Not sure I like the green in the flashback effect, but all the green in the rest of the game looks just fine to me, so I can't put my finger on it! Maybe it's because there's a lot more of it in the flashback, but it feels kind of clashy with all the blue tones. There are so many green things in the world and the UI in the rest of the game, so it feels more balanced there, maybe?

 

[joeyspacerocks]

Thanks I have to admit that I've not been updating as much as I should.

Like you say the green is a bit .. green .. I have had a play with other colours but I just end up coming back to it - might revisit it again at a later stage.

[qMopey]

Posting 4 follow! Been checking out your devlog for a while now. Loving the progress! <3

[eigenbom]

Hey cool

[joeyspacerocks]

Welcome to my weekly bi-annual devlog update. It's only been 7 months since the last update,
so apologies for spamming.

I've actually got quite a bit done on Spooky Pooky. Not as much as I should have and clearly not in
the devlogging department. Hopefully these things will get a little more regular now, as will the progress
on the game as I'll have a little more time to get things done.

There's been a lot of behind-the-scenes work, otherwise known as this-is-why-people-don't-write-their-own-stuff-and-use-Unity.
The good news though is that the game builds and runs nicely under both Windows and OSX (on the small pool
of test machines available to me), so I'm going to try and be better at regularly testing under both from here on.

Here's a selection of stuff done ...

Let there be (nicer) light!

I added basic lighting a little way back which definitely improved the atmosphere. The downside was that
unlit areas felt too dark and trying to up the ambient level washed it all out too much.

I've done a lot of tweaking on this and arrived at a couple of changes that helped quite a bit.

The first was to make the lighting look more stylised. Previously I was rendering the light using a simple
smooth fall-off calculation based on the distance from the source. I've changed this to render in discrete bands
with big intensity steps which feels more in-keeping with the low-resolution / limited colour palette look of the
rest of the game. To make this more interesting I've also added some time-based noise perturbation to give things
a dynamic smokey look. You can see the result below where a light shaft is slanting down into the water.



The second change was more subtle and I could see it maybe splitting opion. Personally I like it and I'm the
developer so it's in. When I compose the contents of the final lighting buffer with the scene I take high-intensity
areas and render them additionally into the glow texture that's used for light-emitting sprites (I'm using
multi-texture rendering so this is trivial and can be accomplished in the same shader that's doing the
composition).

The resulting glow texture is already being composited after the lighting into the main scene using some blur, so
pretty much for free I get some nice subtle glowing for bright pixels that are in direct light. You can (maybe) see
this below:



The combination of these effects feel like they've lifted the look into something much more polished. I'm fully
aware that some people may not like this sort of thing, especially in a game with a pixelly look, but you can't please
everybody.

Workflow

When it comes to content generation having a fast workflow is pretty important.
I'm using Tiled to build my rooms which helpfully lets you add arbitrary commands to it.

I've hooked up one such command to launch the game passing in the current room file and any
selected object id. The game spots these and launches with the player located in the room being
currently edited. If the selected object is an exit then the player enters the room through that
point; otherwise the exit located is used.

There's the caveat that the room has to exist on the world map (another Tiled file), but that's
not to much of a burden.

I may add some hot-reloading of map files so that I can keep the game running and it'll spot if the file changes,
but since the game is pretty much instantaneous to load and run it'll do for the moment.

I've also finally sorted out the logging. Since I'm a lazy and poorly disciplined developer (at home - at
work I'm a consumate professional), I've been chucking in random <code>printf</code> calls at various points.

This kind of nonsense always has a limited shelf-life, so I've knocked together some very basic logging with the
usual info, warn, error, fatal type of logging calls. Currently stuff goes to stdout and a file; I still need to
take a pass through the code to improve the actual content of what's logged.

It's obviously important to get this right - not specifically for debugging stuff during development, but more for
the hypothetical time that'll come when other people start playing this - when it comes to bug reports you can never
have enough information.

And the rest ...

Anyone still reading is obviously a game developer and so will already have trouble maintaining focus for longer
than 5 minutes. Out of solidarity for you I'll break this rambling recap into two or three posts, with the next to
arrive in a day or so.

To entice you, the next exciting installments will cover such topics as changing the state system to use mutating
function pointers instead of enums, switching from SFML to SDL, and changes in development environment and build systems
to ease cross-platform development.

Gripping stuff ...

[Ishi]

Great to see you post again! The stylised banding on that light shaft is brilliant, it looks way better than a simple smooth gradient. Good work!

[joeyspacerocks]

Thanks Ishi!

Here's another little entry to catch up on some more changes.

Let's talk state. Specifically, state referring to how things in the game know what to do next.

I'm a simple soul and this is reflected in the simplicity of my code. Things in the game are mostly
represented by an instance of a structure containing a bunch of disperate data. One of those items of
data was the entity state, where the state was a simple <code>int</code> accompanied by an expiry time.

(NB. The game is written in C; there are no 'objects' in the OO sense of the word, but I do copiously
use function pointers stored in structures, so I'm happy for you to argue with me.)

State-as-an-int works ok up to a point - you end up with functions that have ever-expanding switch
statements, but there's nothing inherently wrong with that. It's straightforward and you can see
exactly what's going on.

However. You do start to feel a bit silly when your switch statements simply start calling
other functions, with names like 'handle_being_electrocuted' and 'keep_dying', or 'do_normal_stuff'.

So, given that one of my function pointers is to a 'think' function, it quickly becomes obvious that
maybe a nicer way to handle this is to just change the think when previously some state needed to change.

This cleans up a lot of code and works nicely. I still need timers just to keep a handle on when stuff might
need to change, but generally speaking the behaviour is simple enough for this to be perfectly adequate.

The other nice thing about being freed from the shackles of OO is that you stop thinking in terms about
what something is. In other words my entities do not have a 'type' as such. The player isn't a player type,
it's just got some behaviour defined via the function pointers. Yes, yes, yes, I know that's one chunk of
the varying definition of OO, but it gives you the opportunity to completely abuse the behaviour at runtime.

For example, when an enemy is dispatched and you might want to spawn a power-up I can instead just mutate the struct
representing the enemy into a power-up. I.e. change the sprites, change the think functions, etc, thus saving a little messing
with the object pooling and saving a little time.

Of course you can achieve all this in 'proper' OO too by using a proper ECS system, or a bunch of interfaces, etc,
but there's something nice about having almost zero architecture getting in the way and just having some nice clean
code where you can see exactly what it's doing and where.

It's also blatently obvious that I'm not even using a proper state machine. I haven't got a stack of states. Maybe
I'll need one later, or maybe I won't - it probably depends how complex the behaviour gets.

The most obvious downside of all of this is that I have a monolithic 'entity' structure. There are fields in there
that are only relavent to certaing types of entity, and not others. For instance, I'm pretty sure that a tile chunk
doesn't need a jump power (although on the other hand ...). It's not strictly necessary, but it is very, very simple,
especially when it comes to object pooling and memory management. There's an overhead there but let's face it, I'm
making a 2D room-based game where the number of entities per room, or even per sector is going to be limited. Some judicious
use of the beautiful (and hated) C 'union' feature may be used later once everything's pinned down to carve up the
fields into chunks that make sense, but at the moment it's just not necessary.

If I had a point to make it would probably be that things can be nice and simple and still work. You don't
always need a complicated (or clever) architecture, and in many cases doing so just gets in the way and obscures
what you're really trying to accomplish.

I expect the next blog post will be titled "Why I moved from C to C++ to Unity in 3 months".

But for the moment it's all just sorta working.