Episode One - The Phantom Motivation - 29/5/2018

Welcome friends, let me tell you - it has been a day. What kind of day? The kind where I don't want to talk about it, god, don't you know it's rude to pry? I'm writing this as a procrastination method because my scritchy scratch notes are looking at me with their judgy 'write your particle generator you lazy wench' eyes, but this is game related, and so it counts.

Allow me to introduce to you...

Catchy name, right? I know

Yes! It's this thing I've been working on for about 2 months now that has no name!

*hold for applause*

But actually, I am pretty pleased with how it's going sans name. I think what I'm most pleased with is the software architecture, I've been spending time really thinking about how I want things to interact and work together. I love me some efficient code, and for the most part it's looking pretty nice. The goal for me with this game was a pretty simple one -

"Actually finish this one, you flakey bitch"

So the fact it's going strong is nice. Recently I got the world transition looking all nice, and added a basic af particle generator for some pretty sparkly effects. Whats that? Do I know I could just get an open source particle generator and save myself time and effort? Why yes, actually, I had considered that - where's the fun there though? The sad part is I actually think it will be fun. Ha!

me to me 

I also started on some animation stuff. Real talk; I want this game to be fun, feel good to play, be unique in some way, and have a strong art style. Art style is important to me, and is one of the reasons I prefer writing 2D games - I think there is more opportunity for unique art in the 2D world. That's not to say there aren't examples of amazing 3D games, I just like 2D better generally *stares longingly at Skull Girls* ALSO! Less maths. Fuck you, high school maths teacher! Told you I wouldn't need it, you don't know me! (spoilers- I do need it, and use it, and wish I had listened more. Stay in school, kids!)

Here is a home video of my little baby, all grown up

oh man...this is more painful than anticipated...let me find a gif converter...

*84 years later*

You know what, we'll circle back. Anyway, this brings us to today - it's just been kind of a shit day tbh. My car is being a bag of dicks, the repair man is flakier than puff pastry, and I have no milk for coffee. No MILK. For COFFEE. NOMILKFORCOFFEE. I'm dying, is what I'm saying.

Today I had high hopes, I had the whole day off from work and was gonna get a bunch of stuff done. So far I have a page of rough notes and work flows, and this stunning dev log entry - you lucky geese. What was I going to do though? Well, like I said I have the particle generator, or I could do the animation class, or I could do some art. Pretty much everything from the backgrounds to the characters is a placeholder right now, some (like the trees) are pretty nice placeholders, but placeholders none the less. I think the art style is coming along nicely, I opted for a water colour style mixed with clean bold lines. The watercolour is real watercolour!

 except the opposite of this...because it IS watercolour

I still have a long way to go...for a start the animation is a trash fire of awful, but this is my animation virginity we're talking about, I gotta break it gently and it's gonna take time for me to git gud. Which reminds me I should set up a Git repo for this stuff. Also I wonder if there are language and content guidelines on here? Just checked them and I think I'm good. See! We're learning things already. On top of the animation, the game world needs a lot of work, I have 3 monster types but a plan for another 2, and I need world elements like moving platforms and climbable walls...so much to do. I'm pumped though, I like where I'm at and I'm excited about where I'm going.

Anyways, I wanna take you all on my dev adventures and break down my learnings as I come to them. I'm writing this thing in C++ with the SFML framework and Box2D physics engine, so if you're interested in any of those then maybe this thread will be of interest to you. Or maybe it won't. Time will tell. FYI here are some things I want to cover shortly

• Game Concept
• Art Prep and Design
• Animation Framework
• Particle Generator
• Game States
• Transition Sequence

Okay!! That's it from me today - for your dedication here is a clip of where I'm at. The gif thing didn't pan out, I ended up having to upload it to youtube just to embed it so that was fun.

Love you, bye!

The Particle Generator - 30/05/2018

Greetings fronds, and welcome to another episode of "I do things and pretend there are strangers that are interested"

On todays episode I begin my journey into the particle generator.

So the above is actually a little untrue, I have a super basic particle generator class that i threw together the other day to test the concept. That's probably a good place to start, so lets take a look at what we're dealing with before we look at what we're changing.

This is what I started with. It's not bad really, although very basic. I've refined it a bit since then in terms of how the physics are applied and now what I have is this

You're probably all 'thats the same...' but hush! It isn't! In the first gif the particles are heavily impacted by their size, the smaller ones are lighter that the bigger ones, and so are flung further. In the second gif you'll see they are travelling about the same distance no matter what their size - much nicer, much easier to control. I still have a fondness for that first iteration, with it's hectic flinging of digital sparkles across the screen, but i have a penchant for chaos.

Lets pop the hood and take a look at whats happening here. I downloaded snagit for this, appreciate my efforts.

That is my particle class. This tells us a lot about what I'm doing so far - I'll tell you up front it relies heavily on hard coded parameters because I just wanted to get it up and running. We'll change this, eventually. Alright, so we have a circle - cool, so our particles are always circles. We have a sprite - not current used by anything, but the beginnings of a better world. The next three are b2 variables - necessary for the use of box2D physics. Life represents how long the particle sticks around for, shouldBeDead is a flag to indicate the particle needs to be removed from the list, and then some ints for rbg colour and alpha value. Nice. Other than that, the particle class doesn't have much going on. Lets look at the cpp side

Okay, so that abomination is the constructor - told you there was a lot of hard coded junk. Lets break this down real quick:

First I'm setting the colour I want for the particle, it's got mods on it so I can get a random shade within a colour range. I used paint to figure all these out, but as you can see there's no dynamic way to change this. 

Next section is defining the basic details - sf circle shape details, life, basic stuff like size, position, and origin. You'll also notice I set the colour in the wrong order, that's a happy accident I left in because it results in those bright flashes at the creation site before the particles are reset to their proper colours later in the update function, but we'll get to that.

Then we have the box2D stuff, the density is relevant later in the mass calculation, but other than that these are pretty standard. You'll notice the size and position all get divided by SCALE - that's a fun box2D trait where it doesn't use pixels but sfml does so you gotta do some witchcraft to line them up or everything dies.

Lastly we have the actual particle effect - this is arguably the most important part of this entire class. This part, in combination with your box2D settings, give you the particle effects. I'm setting up an x and y value with mods so i get a varied spread. Then we do some maths with the mass to make sure the big ones and the small ones are all treated equally. float t is just there so the cpu can do some extra redundant work, because of course. Then we use the calculations to apply the force multiplied by some magic numbers to increase their strength. Fun times, right?

Sweet. Lets look at the update function then that's this class done.

Alright, so you can see we reduce life to count down to the particles death, we reset the desired velocity off the current velocity (not actually sure this is needed, we'll try it later), then update the sf circles position to match the b2 body position. That step is really important; the sf shape is how you see your particle, the b2 body is invisible but it has physics acting upon it so you have to make sure your sf shape tracks to it or you cant see anything happening. I'll show you, hold on

I only changed two lines to get that, one to turn debug draw on for box2D and one to stop the particles from setting their position. You can see the box2D bodies keep going, but the shapes don't follow them. It also looks slower because debug draw is rough on processing. The interesting (and arguably bad) thing about box2D is that I have no input into the calculations and movement - it self manages it's assets from the Step function call run from the main game loop 'update' function. That means I can't really pause any of my physics on certain objects, only on the game as a whole. That's a story for another time though.

Okay! So that's my particle class - lets look at what's calling the shots for them.

Mkay, so it should be immediately apparent to you that this class is made to handle one instance of a particle source. It has a single list of particles, this is used to update and draw, it has a position and time - position for new particles to draw at and time limit that runs the fuel of new particles. Enough of this, lets take a look at the cpp

So draw is looking alright, good job draw. Update is pretty straight forward - a position is passed through (in case the spawn point is moving), the time depletes, the particles are updated and during this they return a bool to let the generator know if they're past their time limit. If they are their index gets added to a second list so I can remove them later, then I loop through the second list backwards to remove them. Why backwards? Well, say i have indexes of 1 and 5 to remove - I remove 1 easily enough, the vector is shortened, then I try and remove 5 - exception is thrown because 5 isnt a valid index anymore. And if that 5 were a 3 I would end up removing the object that used to be 4. Backwards means the highest indexes are removed first, so the lower numbers are still accurate.

If the timer mods 5 nicely then I add some fuel to the generator - seen in Fuel() I just add 20 new particles, 20 is a number I felt like using at the time.  a timer of 80 is also a random number I decided would be good.

SOOOOO

That's where we're at. All these magic numbers mean I can't customise my particles without code changes, I can't use textures, I can't animate the particles, I'm stuck with circles, I'm stuck with pinks and purples, I can't run more than one at once. So many issues.

What's the plan then?

This will evolve as I think of new stuff and restructure things, but as a starting point the goal is as follows:

A client will have a single Particle Generator - this is the class that creates particle effects and manages all particle effects currently active.

A Particle Generator will have many Particle Handlers - these are specific types of particle effects. I will have an abstract handler that all other specific handler types will inherit from, and this will allow me to keep pointers of all the handlers in a single list. It also means I can write templates for specific effects if I want to, or I can customise one through the code. As much functionality currently in the particles will move to these handlers so that the particles themselves are very basic objects.

A Particle Handler will have many Particles - similar to the existing version, but more generic and with a lot of the work moved into the handler. There will be an abstract Particle class that has basic details, but then 3 different implementations of that class to represent the different types of graphics that may be needed. There's no need for a particle that is a simple sf shape to have animation functionality, so that will be in it's own implementation.

The goal here is to make this usable in other projects - modularity is great, and lets you build mock ups very very quickly.

Okay, I'm going to go and set up those classes, and in the mean time I'll post this because I'd hate for it to get lost. I'll update it when I'm up to the next part!

The Next Part - 01/06/2018

I am back! Alright so my classes are (mostly) set up, and I'm in the process of using the Smoke generator to iron things out and figure out what may need to change before I implement the others.

Here's a clip of what's currently happening - heads up, it's pretty underwhelming

Looks pretty similar to what I had before, but grey - right? I know. Lets take a look at how the structure has changed though.

So these are my files. Smoke inherits from ParticleHandler and is set up with presets that will create a smoke effect (eventually). Then we have our 3 different kinds of Particles which all inherit from Particle.

Below is the new Particle Generator. You'll see it's now dealing with Handlers rather than with particles directly. The client gets one Particle Generator that will keep track of all the active handlers - handlers are responsible for the particles associated with them. This means one of our goals is complete - we can have more than one particle effect in play at a time! You'll also notice it also controls the creation of effects - like the CreateSmoke function at the bottom. This way you can simply ask the generator for a particular effect and pass it some simple details and it takes care of the rest.

Handlers act as templates for particular types of effects. They do all the heavy lifting and need to be configured correctly or they won't work at all. I've started with Smoke with inherits from a generic particle generator -

Smoke uses the generic draw provided by this function, but implements it's own update then calls back to the generic update to do the universal clean up steps. As you'll see below; smoke adds a lot of it's own variables. I could group them all to one line, but I've grouped them in a way that's logical to me. moving, greyscale, and the colour mods arent actually being used yet but I'm preparing them for the future when I might want to change the smoke colour, or get it to move in the wind.

You can see below that most if not all of the variables are set to default values - these will change while I'm developing the effect but by the time it's done they will be standard settings for a nice smoke effect.

Prep Particle has taken all the hard work from the particle and ensures that the particle is given all the details it needs ready to go. Eventually I will move the box2D work out of here into a base handler class to neaten things up.

And lastly we have our particle base class

And the shape implementation

As you can see - these are a lot less busy than they used to be. By moving the complexity into the handler I allow the particles to be used by many different effects.

Okay! You're all caught up class wise - so where are things going wrong? Well, I don't love how fast the particles move at all. They're meant to be smoke, and to me smoke is lazy and drifting not a crazy explosion. In terms of slowing them down, it's kind of tricky because they're attached to the box2D world that everything else lives in. Fast responsive physics is great for my player and the enemies, less great for smoke. Changing the variables like friction, density, and the forces can only do so much because they're all kind of interlinked. I can boost the density, but that impacts how far they move, I can increase the friction, but that only matters if they're in contact with other objects. I have two things I'm going to try - the first is to see if I can redeem box2D. If that doesn't work I think I'm going to remove the physics part and just program the particles to act like I want them to. 

Option 1

So as I mentioned; the particle physics exist in the same box2D world as everything else. I can change the frequency of the world step, but not without also slowing down my player and enemies and all that stuff I actually need to have good and responsive physics. What I'm wondering though (and I have no idea if I can do it) is whether or not it will be okay for particle handlers to get their own world. That way I can speed them up or slow them down and not worry about impacting anything else.

I'll give it a shot and we can review the outcome. brb

Okay, for you it's been 0 seconds but for me it's been like half an hour and here's the update

Just a little bit different :P

So what did I change to get that? Well as planned I gave the smoke handler it's own b2 world to live in. The only way that could cause complications for me is if I wanted my particles to interact with the other world objects. Pretty sure all my particles will just be visual nothingness though so thats all good. A separate world meant I could set it's own gravity, too, which is why they don't fall down anymore. I could have intervened and reset the y linear velocity value every time which would have done something similar, but this is easier and far more customisable.

I realised that the smoke was looking strange because it was always moving at full speed so I created two new variables in the Smoke class, one for currentStep that starts at 600 and one called desiredStep which is at 200. You can see the update function below, and you'll see that the currentStep value moves closer to the desiredStep every update, starting the smoke slower and moving it to full speed.

I also moved some things around to support the handler staying alive even when it's  life span timer is 0, this is to allow the particles to fade out naturally rather than suddenly stop when the handler is dead. I also have that super long line that adds a little bit of variation to the smokes path. It will definitely need to be tweeked more later but I like it for now. That line is also why I moved some particle looping into the smoke class from the base class.

To support smoke fading out I also added a variable to the Particle_Shape class so if you pass life in as 0 it will set a boolean value that triggers the alpha value to be reduced on each update and will let the particle live until the alpha value gets to 0 (no longer visible).

And that's it! the Smoke handler is primarily done now, all that's left is to improve customisation options and get the colours in place. I also want to modify how dark the smoke is based off the intensity (which also controls how often fuel is added) and add fuel more smoothly as it sometimes looks a little jumpy. I'm also considering setting up the ParticleGenerator class with some threading so that the rest of the game is unaffected by the particles being drawn. I'll update again when I've got the texture particle ready to show you!

<3 bye!

Update Before Bed - 02/06/2018

It's 12:15 in the morning but I wanted to share with you the texture particle progress :P

Texture Particle - 02/06/2018

It is done! So much easier than expected too, I actually ended up removing the Particle_Texture class because an sfml shape can take a texture. Instead I added a variable to the Smoke constructor that takes a fine name and adds that to the particles shape. I also made a second CreateSmoke function in the particle generator that allows you to pass in a file name

So if you want simple shapes you can do that and it will default to a plain white texture so the colour will show through, or you can use a texture! The next step will be changing which parts of the texture it uses in case you want the images to be different . Colour and texture position are first up on todays agenda. Thennnn who knows. We'll figure it out.

2am Before Bed - 03/06/2018

Fuck threads.

03/06/2018

Okay. A bunch of changes later and here's where we're at.

Alright so that's the smoke and the glitter done. As far as code changes it's been kind of an incremental process of determining what can live in the base class, what is specific to a certain effect, and just trying to improve performance as much as possible. So as you can see with the smoke I can create different colours, including a rainbow style one, and with different intensities - The rainbow one is twice as thick as the pink and grey ones, and the blue/green one is much less. To do that I call them like this

You can probably see what happens there already so I won't explain it. I'm pretty happy with it, although I might move the "smoke.png" part to be defaulted as I doubt anyone would want the plain non textured smoke.

As for the glitter - there were some interesting colour requirements here to set the secondary colour and altering the alpha values 

That's from the update function and its essentially checking the particle for a timer, if it's done it switches between the main set of colours and the alternate colours then resetting the timer and details so it knows what to use next time. If the interval isnt up it will generate a random number and if it mods 50 perfectly then it will change the particle white for a round - this is just to make sure there is an appropriate amount of sparkle. I actually think 50 is too low but it's fine for now. Then we check whether we want to alter the alpha - unlike the smoke the glitter won't die if it has an alpha of 0 so we're setting that to whatever so they look blinky. Then we update the colour with what we've configured.

There was also a change to the force applied to make it explode from a central place. I'll likely change that so it can be directional too.

Other than the effects I've spent a lot of time trying to improve performance which has included threading. The particle generator used to have a single list that held all the handlers, now it has 4 lists and the handlers are assigned to them in a round robin fashion. Then each list gets it's own thread for running the update function - which is the most taxing. That means the load is split over 4 threads which is nice. I also added these two lines

To the body creation which tell box2D that they can't collide with anything. That REALLY REALLY helped with processing.

I also had this weird little issue when I first split my threads and I'll show you in case anyone else is facing it. So my smoke was working nicely, and this was back when I just had the one thread, and as soon as I added it in the smoke started doing this

Now, I already knew I needed to reseed the random generator on the threads, and I was using the time to do it which usually works wonders. It turns out though that the threads were so fast that they we're seeding uniquely off the time. Instead I started passing a random number from the main program thread into the function that would create the threads, then using that to seed the random generator in the new thread. The reason for this is that a seed will always result in the same set of numbers, thats why some games let you generate maps off numbers, then if you like that seed you can use the same number in the future and you'll get the same map. I believe my threads were getting the same system time and therefore creating the same exact particle over and over (thus the lines) so by passing a random number from the main thread I avoid this because the main game thread is only seeded once when the game starts, it maintains it's unique sequence throughout the whole game so it will always be a different seed for the threads to use.

I'm now working on animated particles, so hopefully I'll have an update sooooonnnn!

kbye

It's Been A While - 12/06/2018

Hey everyone, it's been a busy week! I've mostly been playing with the particle generator and studying so nothing super exciting, however I thought I'd give you a last update on  the particle generator. So the first thing of note is that I pulled all the box2D out of it - particles are now just sfml shapes/sprites with movement programmed into each update. That seems to have improved things. I alssoooo split up the ambient stuff from the normal particles and gave them their own update functions and stuff. That's pretty much it really, I'll probably keep playing with it over time but for now I'm happy. Today I'm going to do some art stuff I think - something easy and chill