Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 01:25:13 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsSpooky Pooky
Pages: 1 ... 7 8 [9] 10
Print
Author Topic: Spooky Pooky  (Read 41592 times)
Quicksand-T
Level 4
****


@Quicksand_T


View Profile WWW
« Reply #160 on: March 23, 2016, 08:31:26 PM »

That actually fits really well. The subtle glow you have going on in this game in general is really working.
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #161 on: April 01, 2016, 09:13:57 AM »

That actually fits really well. The subtle glow you have going on in this game in general is really working.

Thanks - I wasn't sure how it would look before I implemented it, but I think it's quite effective and makes the whole thing pop a bit more.

So then. Weapons. Here we go, some explodey bang-bangs. Finally poor Horatio can fight back ...





(The gif encoding has washed out some of the colours so it's all looking a bit grey at the top there instead of the vile green/yellow it should be..)

So here he has a simple laser gun with which he is massacring some defenceless, and harmless, caterpillars. Well, he has been through a lot, so we'll cut him a little slack.

As usual this all took a lot longer to get working than it probably should have, thanks to my usual approach of implementing just enough but no more. My code-that-is-where-an-engine-would-go .. um .. engine .. carried out collision checks between the player and other (suitably flagged) entities, but not between arbitrary entities such as, say, a laser bolt and a caterpillar.

So first change was to pull out this collision stuff into a more generic form, which was reasonably simple. My entities implement flags (such as E_COLLIDES_ENTITY) indicating that they'd like to collide with other things. If they do they can then indicate that they'd like to receive events (i.e. notifications) that they hit something by adding an event to their event mask (e.g. EVT_COLLIDE). This way I only collide things that care together.

The generic code will also apply damage (if the collider has a 'damage' quantity set) and trigger a corresponding EVT_HURT (or EVT_DEAD if things get really bad) in the collidee. That's a word, right?

So things are coming together in the main system to support this stuff. Along the way I've noticed several glitches (such as caterpillars falling through the floor when they crawl into a door), so I'm accumulating a little list of things to fix which I pick off when I've got a spare 10 minutes to kill.

I've also been a good boy and tried to keep adding sound effects as I go. The game has a sound design best described as 'glitchy' and 'atmospheric', to suit it's techno style.

The weapon implemented (laser) is just a test, and really belongs to various enemies, although I may add it as a collectable weapon. So next up is to design and implement the various weapons I really want Horatio to wield, plus their effects on the enemies and environment.
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #162 on: April 11, 2016, 01:47:57 AM »

I've started floundering again. It all began when I started to design (!) the save-game / checkpoint device.

My first attempt was this:



Nice effect (with some more polish) but doesn't exactly scream checkpoint.

Regardless I decided to add some shader effects to make it warp and seem more energetic:



To implement this I've added an extra drawcall type into my render system for full-screen post-processing. This allows me to render the buffer-so-far using an arbitrary shader, and I can insert this at any depth I like.

So, the extra render tech will be useful, but as an effect this sucks a bit and doesn't really fit the asthetic at all.

So abandoning this I went full pixel and made this little beauty:



Now I'm quite proud of the machine in this one - with some glow effects and some electricity when it's on it might be quite effective.

However. It's still not a checkpoint! So now I've got two 'machines' and I don't know what either of them does, and still nothing to save the game with.

Like I said. Floundering.
Logged

MekaSkull
Level 1
*



View Profile
« Reply #163 on: April 13, 2016, 02:24:30 AM »

That new machine and the ground tiles in the room look really nice. You seem to be leveling up in skill as you go Shocked. It feels like it would do something that alters the player, like make him tiny, invert gravity, slow down time. Something fundamental.

The previous glowing thing really looks like a portal  Ninja
Logged

Twitter @MekaSkull
Cyber Shadow Devlog
indieDB
joeyspacerocks
Level 1
*



View Profile WWW
« Reply #164 on: April 13, 2016, 09:20:04 AM »

That new machine and the ground tiles in the room look really nice. You seem to be leveling up in skill as you go Shocked. It feels like it would do something that alters the player, like make him tiny, invert gravity, slow down time. Something fundamental.

The previous glowing thing really looks like a portal  Ninja

Thanks - yes, I do feel that I'm 'growing into' the palette I'm using (DB16) and generally making better progress graphically, although I'm definitely more comfortable with static stuff than characters / creatures. My attempt to add a gun to the main guy, for instance, sucks pretty badly, so I'll need to revisit that at some point.

Great idea for the machine to apply some kind of transformation - quite like the idea of that - especially something that charges up some ability that could maybe be revisited later in the game. Years ago I played Prey (FPS) which had portals and a brilliant area where you went through a portal and appeared miniaturised on a small sphere in a glass case that you ran past earlier. I've always fancied that as an idea ...
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #165 on: May 03, 2016, 03:23:13 AM »

My how time flies.

Despite appearances, work is continuing - here's a little list of minor accomplishments to make myself feel better:

  • Variable-height jumping finally fixed
  • Judder when doing a little jump on moving platforms fixed
  • Buoyancy problems fixed
  • Physics collisions and responses broken by previous two fixes .. um .. fixed
  • Gun removed - skeletons don't hold guns silly, they fire lasers from their EYES!
  • Auto-aiming (within a certain range / angle) implemented
  • Yet another odd machine added - possibly a save point
  • Some idle animations added

Everyone loves lists. Look at all those things I can tick off the list I didn't write them on. Unfortunately I haven't ticked off anything that actually was on the list.

Here's some GIFs.







I'm desperately trying to focus now to give some structure to the game and get some real content built. The fact I'm here writing this shows how easily distracted I am ...
« Last Edit: May 03, 2016, 04:54:26 AM by joeyspacerocks » Logged

MekaSkull
Level 1
*



View Profile
« Reply #166 on: May 04, 2016, 04:38:52 AM »

Getting that platforming to work on a bouncy water platform thing must've been hard. Well worth the effort, since it looks cool. How does your variable jump height work? I'm doing it by giving an impulse when jump is pressed and then killing the vertical momentum by cutting it to 30% or so when the button is released.

Nice to see progress on this so I at least don't mind you getting distracted to update this devlog XD
Logged

Twitter @MekaSkull
Cyber Shadow Devlog
indieDB
joeyspacerocks
Level 1
*



View Profile WWW
« Reply #167 on: May 04, 2016, 01:12:06 PM »

Getting that platforming to work on a bouncy water platform thing must've been hard. Well worth the effort, since it looks cool. How does your variable jump height work? I'm doing it by giving an impulse when jump is pressed and then killing the vertical momentum by cutting it to 30% or so when the button is released.

Nice to see progress on this so I at least don't mind you getting distracted to update this devlog XD

Physics stuff is a funny beast .. I had buoyancy working ages ago, but after fixing a few seemingly innocent bugs I realised that I'd completely broken it ...

I can pop arbitrary chunks of tiles out as distinct entities by drawing a rectangular object around them in the level editor I'm using (Tiled) - I can then give them a few properties, such as density, which means that dropping into water will cause them to float. To do this I use a pretty standard buoyancy equations, but the thing that was really screwing it up was adding drag forces - for very light objects (such as those platforms, which have to be light so they don't sink when the player lands on them) I managed to give it massive drag forces in the reverse direction to velocity causing things to explode out of the water ..

For variable height jumping I've really been round the houses trying different things - and then the simplest thing worked, straight out of the Sonic handbook .. pretty much what you do I think - give the max impulse on jump and when the key is released then cap the y velocity at about 50% of the max power .. I was dubious but it works very well ..
Logged

clebs
Level 0
*



View Profile
« Reply #168 on: May 05, 2016, 12:47:30 PM »

Hi! I just found this game in the forums a couple of days ago and read all of it thoroughly.
I find it really awesome and I am really impressed that you are doing this the hardcore way in C. I am using Java for the same and can relate to how hard this is  Corny Laugh

I found all your posts explaining how you did things very interesting and I am hoping to see more of those!! Especially on the rendering side (I am not that good with OpenGL yet :/). There I found all the shader effects and the bouncing and blobbiness of enemies and plants very cool.

FInally, congratulations on the hard work and keep it up, I will be following your interesting posts!!

Cheers.
Logged
joeyspacerocks
Level 1
*



View Profile WWW
« Reply #169 on: May 06, 2016, 01:10:35 AM »

Thanks clebs - it means a lot, especially at the moment when I'm in a bit of a rut trying to design the overall world ...

To be honest building this thing in C vs, say, C++ really doesn't make that much of a difference. Or even when compared to using a framework like Unity.

The hard bits for me are always the more creative side like the world design, or audio. The programming is just, well, programming, and I've been doing it long enough to know that you can always find a solution for a pure programming problem, it's just a question of time.

I do enjoy C though - it's nice to strip away some of the over-complication that can arise from using an OO language. Don't get me wrong, OO provides a lot of useful tools, and is invaluable in many circumstances, but for a 2D game it's entirely possible to ditch it to a great extent. It just means that your code is written from a more functional point of view - i.e. functions are more standalone and take parameters and return results, rather than mutating structures directly.

As for OpenGL - yeah, I still really don't know what I'm doing there Smiley Oh, I have an idea, but frankly a lot of it is still a mystery - I have a bad habit of only finding out just enough about things to solve particular problems  without understanding the whole thing ...

There's not actually that much OpenGL in the codebase when it comes down to it - just some generic code that chucks big lists of triangles plus texture coords to a draw call and a handful of shaders. Most of the code that supports it is my own stuff - e.g. sorting stuff by attributes / depths / shaders. Plus I'm not adverse to using a library when I need it - hence the use of SFML for getting an OpenGL context and for audio and input.

I'm not going pure handmadehero on this thing - I've got enough problems Smiley
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #170 on: May 31, 2016, 09:11:40 AM »

Hello devlog, sorry it's been a while.

Since last time I've made a little room generator script. It's really billy-basic - not so much procedural-generation as just ... generation. It's a Python script that just creates Tiled levels at custom screen-sizes (e.g. 1x1, 2x1, etc) with some exits at strategic points and some basic generation. The purpose is to have a quick way of kicking off empty rooms for me to fill with stuff to test. As the build progress I'll extend the script with more options (e.g. tilesets, etc) but it's only ever going to be used for generating the basis for hand-crafted rooms.

As an aside, I'm also going to play around with a script for augmenting room files to add 'stuff' - e.g. foliage, background tech stuff; basically non-colliding decoration.

I've also simplified doors and exits (the GIF below shows some basic generates rooms - with manually added stuff on top). Previously exits were a mixture of tiles, invisible trigger areas and door objects placed into a room. Now an exit is a single Tiled object plonked into a room. In game this becomes an entity backed by an appropriate sprite and a door is automatically added next to it. The direction you exit the room in (i.e. up/down/left/right) is automatically determined by the edge the exit is added to, and the destination room identified from the world map (discussed in a previous entry).



I finally added in floor/ceiling exits too. Pretty simple except that it finally made me address the issue of how to deal with logistics. Vertical exits are simple as you just walk into them. The doors have a range within which they automatically open or close.

Ceiling doors also have this range. When you hit a ceiling exit, you're flagged as 'antigrav' and artificially pulled into them.

Floor doors are fun. Ranges didn't really work here, so to open a floor door you have to stand on it and hit the 'activate' button. You then drop into the exit. I've also added a little tweak to the collision code so that if you're running along and hit the edge of a door (or any lowish solid object) you're automatically bumped up so that you can step over them without having to jump.

When you enter the room through a floor door you're given an upwards boost so that you fly up out of the exit, the door closes, and you gracefully land onto the floor-door. Beautiful.

So much for doors.

This is a supposed to be a game with a touch of the grotesque. So with that in mind, how about a little power-up that enables you to detach the upper part of your head fro your body and then run around the world in a disembodied state. Helpfully it also lets you scuttle through low areas.



It's not terribly well thought through at the moment - bugs galore and it's quite easy to lose your body. Never mind.

The reattachment animation was donated to me by a lovely person on Twitter called @EnchaeC and opend my eyes to the possibilities once you stop obsessing over frame-count and just bump it right up there ...
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #171 on: June 19, 2016, 06:52:39 AM »

Like the sunshine in an English summertime, progress on Spooky Pooky has been patchy in the month of June.

There has been an amount of cleanup in the code-base, such as removing the last references to 'levels' and replacing with 'rooms', finally cementing the game's status as a non-level based metroidvania. I've also been busy indulging in my favourite programming past-time - deleting code.

On a more constructive note I've given the slime blobs the ground-breaking ability to follow the walls to their left. Hence the test blob-cave below.



Something that's been on the list for a while is importing rotated and flipped tiles from Tiled. When I render the tile-map I use a static VBA with enough tiles to cover the screen that I offset according to the scroll-offset. I dynamically remap the texture coords for the array and resend that every frame, so to support flips and rotations (which are covered by flips about the diagonal) I simply had to fiddle with the UVs when building the per-frame texture coords.

The current plan is to chain a series of rooms together that contain all the weapons and power-ups available in the game, so that I can test them singularly and then in combinations. First step was to revisit the gain-a-powerup-organ sequence, which currently consists of finding an 'organ container' and busting it open using a button, etc.



I'm not finished with this yet as the effect underwhelms me a little, but it'll do for the moment.

Speaking of effects, I've expanded the post-processing stuff a little. I can add a post-processing effect into my drawcall at any depth - in the GIF above the red tint is added above everything except the white explosion effect - but I've only allowed for a single control parameter. So I've expanded this so that a post-processing shader can take an arbitrary 3 vec4 parameters. This finally enables me to pass in things like a colour, and/or a focal point, etc. Using this I plan to add some wibble effects focused around the player, possibly with a depth-of-field thingy too. We'll see how it goes.

I think I've got enough pieces in play now so that I can get on with implementing all of the powerups. To plan these out I've sketched out a list of progression barriers (e.g. can't reach a platform, or get past an enemy) along with potential solutions (e.g. double-jump / fly / wind-tunnel) to help me get at least the main movement powerups sorted.

That's the plan anyway. And we all know how long those last ..

Finally, when I'm tired I doodle stuff. I've been very tired recently ..


Logged

Ishi
Pixelhead
Level 10
******


coffee&coding


View Profile WWW
« Reply #172 on: June 19, 2016, 08:44:31 AM »

Can't remember if I posted to follow this thread yet, but either way I've been keeping an eye on the game for a while. Progress is looking great, I like the way you've approached certain things like moving platforms!

Out of interest have you thought about adding slopes or are you sticking to square blocks? (Nothing wrong with square blocks)
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #173 on: June 19, 2016, 09:20:48 AM »

There are several times I've been really tempted to add some nice slopes ...

Visually those excessively-metroid tiles are mainly placeholders for knocking together my test levels quickly, but proper slopes are the kind of thing that I'll no doubt waste some time getting in there when I should be getting a game together instead ...

So, I'm resisting the urge, but will likely give in at some point and then spend a solid afternoon swearing about physics and collision code again.
Logged

kcbanner
Level 0
***


View Profile
« Reply #174 on: June 20, 2016, 04:43:12 PM »

Loving the art style and the effects in this. Especially nice particle effects. Any tips for someone about to implement their own particles?
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #175 on: June 21, 2016, 03:25:46 AM »

Loving the art style and the effects in this. Especially nice particle effects. Any tips for someone about to implement their own particles?

I jotted some stuff down about the particles in an early post.

To add to that I have a per-room pool of particles. Each particle is currently self-container - I don't bother with linking them to emitters or anything, but instead just generate them per- frame by things that want to (technically there is an Emitter structure that's used to parameterise the creation, but it doesn't hang around between frames).
Logged

ogat
Level 0
**



View Profile
« Reply #176 on: June 21, 2016, 04:41:38 AM »

Wow, these are the pixels that make me happy.
Really like how much movement you have going on, even the skeleton is springy.
Logged

joeyspacerocks
Level 1
*



View Profile WWW
« Reply #177 on: July 06, 2016, 01:51:39 AM »

My dedication to doing-a-little-bit-every-day is helping to push me through the molasses-like barrier of a creativity slump. At least, I think it's helping.

The code has evolved to match the game that is emerging and whilst generally a good thing that helps keep things mean and lean, there are some aspects that eventually need to be taken to task.

One such area has been collision detection. The main area I tackled at the start of the project was collision detection and response with solid areas. Specifically tiles.

Entities were flagged as 'colliding with the world' and such things were shoved through a weaselly named function called 'apply_physics'. This handled applying generic forces (like gravity, springs, shifting things along predefined paths, buoyancy) as well as checking for collisions against solid tiles and other entities that were made of solid tiles (such as moving platforms).

I then added in 'solid' entities - i.e. non-tile based things like doors that were still solid to the player.

When I added some bad guys and triggers I created a separate function to detect collisions between non-solid things. This had a separate entity loop in it and evolved into using simple collision groups and masks so that I could indicate which things collide with which other things.

A tad inefficient to have duplicate loops running, plus I'd managed to end up with two different collision events that I would send to entities - EVT_COLLISION and EVT_COLLISION_TILE. Messy.

So over the past week or so I've teased the dysfunctional function 'apply_physics' apart and merged the collision loops. Solid things, and things that care about solid things, now use the generic collision masks and groups like the rest of the system which is much cleaner plus there's less loops per entity per frame.

The events have been reduced to a single one indicating a collision occurred.

An interesting simplification I also made was to wrap up the main foreground tile layer into a tile-chunk entity itself. This means that collision against it is just the same as other entities in the system.

During this I noticed that seed pods weren't exploding against arbitrary non-tile solid entities correctly and so started obsessing over it until I had it working properly. Even though I don't know what they're for or why I'm adding it. Brilliant.



As a consequence of getting this working I found a great little bug - I have a simple little structure that I wrap around fixed sized C arrays so I can pass them into functions and have them maintain a 'next' pointer for those things to easily push stuff into them. And of course I'd buggered up the code that shunts the pointer on. This was used for the collision stuff so it meant that if something collided with more than one thing during a frame it lost all but the last one, which luckily broke the seed stuff in some circumstances.

Anyhoo, I now have some nice and clean (mostly) collision stuff that all works off a simple loop. Great.

Some other low-hanging fruit that I tackled was my use of Tiled maps. Another evolutionary dead-end that was hanging about was my lazy hardcoding of which tiles were to be treated as solid (and solid-from-the-top-but-not-if-jumping-up). Basically I had some hard coded tile id ranges. Yeuch. Bad programmer.

So I've finally promoted the foreground layer in the tile map to be treated as all-solid tiles, and additionally enabled flagging of individual tiles in the external tileset as jump-through via Tiled properties. Lovely.

Running out of low-hanging fruit so looks like I'm gonna be climbing trees soon.
Logged

MekaSkull
Level 1
*



View Profile
« Reply #178 on: July 06, 2016, 05:22:59 AM »

And all that technical stuff translates to very good looking physics in that gif. The interaction looks like a lot of fun and gives many game design opportunities for sure.

I tackle slumps in a similar fashion with the thought "what is the smallest bit I can accomplish" and with that I usually get carried away into completing bigger hurdles.

Keep it up  Ninja Hand Thumbs Up Right
Logged

Twitter @MekaSkull
Cyber Shadow Devlog
indieDB
joeyspacerocks
Level 1
*



View Profile WWW
« Reply #179 on: July 12, 2016, 02:15:18 AM »

Thanks @huZba .. working through it Smiley

Here's a little update - been fleshing out some of the audio recently as can be seen/heard in the vid below.





It's all very WIP - helped show up a silly issue where I just pile in more sounds as needed until I run out of 'bandwidth' and more important sounds get ignored. So I need to keep track of what's playing and ensure that I impose simultaneous limits on the same sounds plus give others precedence. Hopefully it won't really need to get that complicated but I'll plan for it just in case.

The overall sound design can be summed up as 'weird' and 'glitchy', rather than overtly retro or 'realistic'.
Logged

Pages: 1 ... 7 8 [9] 10
Print
Jump to:  

Theme orange-lt created by panic