Indie Game Development |OT 2018| Come, help, learn, show and tell!

sabrina · Jun 14, 2018

Weltall Zero said:
This is simply lovely. The only thing that would make it better would be the bubbles moving in the direction of the mouth, but I'm 100% certain the different wouldn't be noticeable at the normal game's zoom level with how fast the chug is. Being able to visible chug parts of it is great, reminds me of VanillaWare games.

Out of curiosity, I know you have a ton of herbs and I assume they'll make a lot of different potions; how do they look? Do the change colors, textures, the bottle shape...?

Thank you! You're right about the particulate matter... it's too hard to see at scale to worry about animating it. The medicinal plants you find change the color from green to something else depending on the color of the other plants. There aren't any set recipes, just minor additional perks granted with each plant you add to a given brew.

jbr373 said:
which tools are you using for your animation work? I've mostly used Spriter so far but i keep running into issues using it, so I started looking around for other options

Also, does anyone have some resources on platformer physics implementations? I got tired of constantly fighting with Box2D and decided to cut it out and implement the (basic) physics myself
That seems easier than trying to bend a realistic physics engine :/

I'm using Spine. I've never tried Spriter so I'm not quite sure if the issues you're running into would be shared in Spine or not.

Which game engine are you using? Unity's 2D physics engine has a few improvements over Box2D but I think most people just use one of those if they're not doing AABB tiles.

Weltall Zero · Jun 14, 2018

sabrina said:
Thank you! You're right about the particulate matter... it's too hard to see at scale to worry about animating it. The medicinal plants you find change the color from green to something else depending on the color of the other plants. There aren't any set recipes, just minor additional perks granted with each plant you add to a given brew.

Oooh, it's rule-based like Breath of the Wild. Awesome!

sabrina · Jun 14, 2018

Weltall Zero said:
Oooh, it's rule-based like Breath of the Wild. Awesome!

Very similar, yeah. That's not what I modeled it after but I've since realized the similarity. The main difference is that BotW tries to come up with bespoke names for the recipe you've made, and I'll just literally list the ingredients of the potion you've brewed.

jbr373 · Jun 14, 2018

Weltall Zero said:
Aseprite is just fantastic and gives me exactly what I need. It was used to make Starbound's sprites which is quite the strong endorsement. It has a free version and the paid version is only 15$; you can buy it on Steam.

sabrina said:
I'm using Spine. I've never tried Spriter so I'm not quite sure if the issues you're running into would be shared in Spine or not.

Which game engine are you using? Unity's 2D physics engine has a few improvements over Box2D but I think most people just use one of those if they're not doing AABB tiles.

I'll have a look at Aseprite and Spine, thanks!
The main issue with Spriter is that the UI itself doesn't really "click" with me, gestures on my laptop also mess with it a bit.

I wrote my own engine, thats why I went with Box2D. I rewrote everything in terms of movement, the issue is more the rules of "gamey" physics like in Metroid, Sonic, etc.
I had a look at the sonic physics writeup, but that seemed to rely on framerate timing instead of a delta time approach.

KNTomg · Jun 14, 2018

Oh hi guys, fellow dev here.

I have been out of the game development scene for a while but i'm thinking to get back to it, so I'm making a few little games to spice up my portfolio. The only problem is that I haven't worked in the industry for a good while (more than 2 years). Should that be a problem? Has anyone been through a similar siuation?

sabrina · Jun 14, 2018

jbr373 said:
I'll have a look at Aseprite and Spine, thanks!
The main issue with Spriter is that the UI itself doesn't really "click" with me, gestures on my laptop also mess with it a bit.

I wrote my own engine, thats why I went with Box2D. I rewrote everything in terms of movement, the issue is more the rules of "gamey" physics like in Metroid, Sonic, etc.
I had a look at the sonic physics writeup, but that seemed to rely on framerate timing instead of a delta time approach.

Yeah the common approach to making a deterministic physics model is to have a consistent internal frame rate and then just interpolate or extrapolate on superfluous frames to make it seem smoother. Unity's default physics tick is 50 fps, which of course can be changed to something else (I changed it to 60 fps for my game). The reason for this is that it makes all of the math significantly more consistent, floating point errors being the only discrepancies. Plus, historically, games like Metroid and Sonic didn't have the luxury of delta time calculations because the hardware support for floating point numbers was so poor. That's why games used to literally slow down instead of just getting choppier.

Brushguy Woodthreep · Jun 14, 2018

I got a bit bored of pixel art, so I decided to go back to coding and make a start on my palette generation routine. (Weltall Zero I will go back to your last reply at some point, but I know you'll find this interesting too!)

To recap, the idea is that:
a) each run should have a unique colour scheme that feels different from other runs
b) within each run, the dungeons all have clearly different yet coherent colour schemes
c) across the entirety of one run, the colour scheme should feel cohesive (i.e. reuse the same shades as much as possible)

So far the results are mixed, with a view to being pretty decent if I make a bunch of tweaks.

Here's a cherry-picked example of it making something fairly nice:

Here is the full palette for that run:

Each row shows the ramps for one dungeon. From left to right it's Walls, Floor, Doors.
At the bottom is the full palette, which consists of 32 colours.

Here you can see what all the dungeons in this run would look like.

------

The steps it goes through to get here are as follows:

1. It sets a saturation and value to use for all of the base colours (this sets the overall brightness/pastelness of the palette).

2. For each dungeon, it semi-randomly picks a hue to use for the walls. It actually starts at a random place on the hue spectrum, then goes across the all/most of the spectrum at pre-determined intervals. This ensures there is the biggest possible range of colours.

(Side note: I tried using the golden ratio in that step, as discussed previously, but this turned out to give really predictable results that I had little control over. In the end, it's not so suited to my use case.)

3. It sorts the dungeon hues semi-randomly. (It's random except that neighbouring hues aren't placed next to each other.)

4. It picks coordinating hues for the floor and doors.

5. It adjusts the saturation and value to create all of the ramps.

At this point each dungeon's ramps are all entirely independent, so the total palette size is very large (every shade on every ramp is different).

6. It reduces the palette to the specified number (currently 32) by repeatedly comparing all the colours, finding the most similar ones, and merging them together. (It never merges two colours that are within the same dungeon - so it won't, for example, turn a ramp into all one colour, or turn a dungeon's walls and floor into the same colour.)

------

There are a lot of things I need to tweak to make it work better, but here are some examples of the current state:

The decent one I linked to above. The colours are muted and the dark shades are fairly dark, so it works well.

A brighter palette which is kind of eye-gouging. I should adjust the valid range so things like this aren't possible.

One that's kind of OK, but suffers from the darkest wall shade not being dark enough. This is due to how it calculates the ramps - this needs adjustment to make sure it goes dark enough. It's also probably due to not having yet included hue shifting for the lighter and darker shades.

------

All the examples so far are with 5 dungeons. The number of dungeons can actually be set to anything, which gives interesting results. I tried a bunch with 9 dungeons.

See a full example with 9 dungeons here.

With 9 dungeons, it has a tendency to get confused when merging the darker colours (leading to ramps in the wrong order...) or end up combining colours so much that different dungeons are almost identical:

A bunch more 9-dungeon palettes can be found here.

To a certain degree I guess it's not that likely that a palette with 32 colours can cover 9 dungeons with visibly different colour schemes across 11 shades per dungeon... I can change the maximum palette size to anything I want, but I also think there are probably rules I can apply that mitigate the worst of those problems.

Anyway, the biggest things I need to do are:
- implement hue shifting
- adjust the range of starting saturation and value to be less eye-gouging
- find a better way to adjust the saturation and value of the darkest shades, so they definitely end up dark enough.

Weltall Zero · Jun 14, 2018

Brushguy Woodthreep said:
I got a bit bored of pixel art, so I decided to go back to coding and make a start on my palette generation routine. (Weltall Zero I will go back to your last reply at some point, but I know you'll find this interesting too!)

To recap, the idea is that:
a) each run should have a unique colour scheme that feels different from other runs
b) within each run, the dungeons all have clearly different yet coherent colour schemes
c) across the entirety of one run, the colour scheme should feel cohesive (i.e. reuse the same shades as much as possible)

So far the results are mixed, with a view to being pretty decent if I make a bunch of tweaks.

Here's a cherry-picked example of it making something fairly nice:

Here is the full palette for that run:

Each row shows the ramps for one dungeon. From left to right it's Walls, Floor, Doors.
At the bottom is the full palette, which consists of 32 colours.

Here you can see what all the dungeons in this run would look like.

------

The steps it goes through to get here are as follows:

1. It sets a saturation and value to use for all of the base colours (this sets the overall brightness/pastelness of the palette).

2. For each dungeon, it semi-randomly picks a hue to use for the walls. It actually starts at a random place on the hue spectrum, then goes across the all/most of the spectrum at pre-determined intervals. This ensures there is the biggest possible range of colours.

(Side note: I tried using the golden ratio in that step, as discussed previously, but this turned out to give really predictable results that I had little control over. In the end, it's not so suited to my use case.)

3. It sorts the dungeon hues semi-randomly. (It's random except that neighbouring hues aren't placed next to each other.)

4. It picks coordinating hues for the floor and doors.

5. It adjusts the saturation and value to create all of the ramps.

At this point each dungeon's ramps are all entirely independent, so the total palette size is very large (every shade on every ramp is different).

6. It reduces the palette to the specified number (currently 32) by repeatedly comparing all the colours, finding the most similar ones, and merging them together. (It never merges two colours that are within the same dungeon - so it won't, for example, turn a ramp into all one colour, or turn a dungeon's walls and floor into the same colour.)

------

There are a lot of things I need to tweak to make it work better, but here are some examples of the current state:

The decent one I linked to above. The colours are muted and the dark shades are fairly dark, so it works well.

A brighter palette which is kind of eye-gouging. I should adjust the valid range so things like this aren't possible.

One that's kind of OK, but suffers from the darkest wall shade not being dark enough. This is due to how it calculates the ramps - this needs adjustment to make sure it goes dark enough. It's also probably due to not having yet included hue shifting for the lighter and darker shades.

------

All the examples so far are with 5 dungeons. The number of dungeons can actually be set to anything, which gives interesting results. I tried a bunch with 9 dungeons.

See a full example with 9 dungeons here.

With 9 dungeons, it has a tendency to get confused when merging the darker colours (leading to ramps in the wrong order...) or end up combining colours so much that different dungeons are almost identical:

A bunch more 9-dungeon palettes can be found here.

To a certain degree I guess it's not that likely that a palette with 32 colours can cover 9 dungeons with visibly different colour schemes across 11 shades per dungeon... I can change the maximum palette size to anything I want, but I also think there are probably rules I can apply that mitigate the worst of those problems.

Anyway, the biggest things I need to do are:
- implement hue shifting
- adjust the range of starting saturation and value to be less eye-gouging
- find a better way to adjust the saturation and value of the darkest shades, so they definitely end up dark enough.

This is absolutely great! So rewarding to see it all coming together like this. :)

A few suggestions:

- When looking at the combinations of colors, I tried to deduce some common rules to the ones I find more pleasant. I ended up with something that on retrospect I could have perhaps guessed, but hindsight is 20/20, so it's probably valuable still: the most pleasing combos followed one of these two cases:
a) Cases where the wall and the floor are complimentary / opposite in the color wheel (blue and orange, green and red, yellow and purple).
b) Cases where the wall and floor are very close in the color wheel (e.g. blue and teal).
I would try to restrict the choices for colors following the above rules. If you think of the color wheel, prevent picks for the floor and walls that are close to 90º degrees with each other.

- The color ramps are missing a crucial element that makes them far richer: hue-shift. To quote this article, "The darker it gets, the more blue your hue becomes - The lighter it gets, the more yellow your hue becomes". For example, in this tree from the amazingly beautiful Seiken Densetsu 3, the green of the leaves becomes yellow at the highlights and blue at the shadows.

- I personally would either make the doors a fixed, muted color, or make them the same color as the floor (making them the same as the walls might make them hard to see at a glance). The reason for this is that generating two (semi-)random colors already strains the aesthetic sense; three different random colors is going to make the clash so much bigger.

- The palette conflation step seems somewhat superfluous. I understand as the creator you like the sense of authenticity that a single run uses the same 32 color palette, but for the player I think this would be entirely unnoticeable.

Brushguy Woodthreep · Jun 14, 2018

Weltall Zero said:
This is absolutely great! So rewarding to see it all coming together like this. :)

A few suggestions:

- When looking at the combinations of colors, I tried to deduce some common rules to the ones I find more pleasant. I ended up with something that on retrospect I could have perhaps guessed, but hindsight is 20/20, so it's probably valuable still: the most pleasing combos followed one of these two cases:
a) Cases where the wall and the floor are complimentary / opposite in the color wheel (blue and orange, green and red, yellow and purple).
b) Cases where the wall and floor are very close in the color wheel (e.g. blue and teal).
I would try to restrict the choices for colors following the above rules. If you think of the color wheel, prevent picks for the floor and walls that are close to 90º degrees with each other.

I can definitely make it avoid 90 degree colours. At the moment, it's a bit too permissive (it allows almost the whole range between the base colour and the opposite colour), but I could restrict that without too much extra work. Thanks for the detailed look, as this is something I'd been wondering about.

(Like, whether I can really get away with how randomly it picks the coordinating colours right now. I guess I can't!)

Weltall Zero said:
- The color ramps are missing a crucial element that makes them far richer: hue-shift.

Yes, I mentioned this too. Don't worry, it's very much on the to-do list. I was just excited about showing something already, since the hue shift mechanic is going to take me a bit of time.

Weltall Zero said:
- I personally would either make the doors a fixed, muted color, or make them the same color as the floor (making them the same as the walls might make them hard to see at a glance). The reason for this is that generating two (semi-)random colors already strains the aesthetic sense; three different random colors is going to make the clash so much bigger.

The floor and door colours are both exactly the same distance around the colour wheel from the base colour, just in opposite directions. Something along these lines:

So in theory, both the floor and doors should coordinate equally with the walls, and all three should be quite cohesive with each other... at least if I exclude the relative hues that are clearly not working (the ones close to 90 degrees around).

Now that I look, the examples in the picture are basically 30 degrees, 120 degrees or 150 degrees. I guess I should stick to regions around there.

I'm reluctant to make the doors the same colour as the floor, because when I tried this before it made them kind of muddy and invisible... but the palette routine is pretty flexible, so I can play around some more and see how I feel. At a glance, using the same colour for both can definitely work for some colour pairings. The key is that even though the base colour is the same, the doors have a lighter ramp so they don't totally blend into the floor:

So I'll experiment a bit more. Though I do have to say, for the examples where 3 different colours works, I think it really works. I'd rather not completely throw that out if it can be salvaged into beauty with some rule tweaks.

Weltall Zero said:
- The palette conflation step seems somewhat superfluous. I understand as the creator you like the sense of authenticity that a single run uses the same 32 color palette, but for the player I think this would be entirely unnoticeable.

What's this? Mr Definitely-pick-a-palette-and-stick-to-it is saying I shouldn't worry about my game's overall palette coherency???

=P

I do think it adds a bit of subtle flavour if the colours are unified, but overall, I would agree with you... if the generation was only for the dungeon palettes. The plan is to add in extra ramps for all kinds of things: the overworld, the player character, the enemies, the NPCs, etc. If none of those cross-pollinate their colours at all, the game will be an uncoordinated mess.

So the idea is that it generates all of those, then reduces the palette down by looking at all of them together. How it works in practice remains to be seen, but that's the theory I have in mind right now!

werezompire · Jun 14, 2018

Weltall Zero said:
This has never come up as a problem for myself (my UI is pretty "generic"), but since the devs of Cosmic Star Heroine are here on Era you might want to ask them directly if they mind. :)

As long as people aren't outright copy/pasting our assets, I don't mind if their UI looks similar to ours.

Weltall Zero · Jun 14, 2018

Brushguy Woodthreep said:
I can definitely make it avoid 90 degree colours. At the moment, it's a bit too permissive (it allows almost the whole range between the base colour and the opposite colour), but I could restrict that without too much extra work. Thanks for the detailed look, as this is something I'd been wondering about.

(Like, whether I can really get away with how randomly it picks the coordinating colours right now. I guess I can't!)

Since you go into more detail below I'll reply there. :)

Brushguy Woodthreep said:
Yes, I mentioned this too. Don't worry, it's very much on the to-do list. I was just excited about showing something already, since the hue shift mechanic is going to take me a bit of time.

Oh, sorry about that, I completely missed that.
In any case, a simple, quick and dirty way to implement hue shifting would be, for each color in the ramp, add R = G = c1*(i/t), B = c2*(1-i/t), where i is the index in the ramp, t the total number of colors in the ramp, c1 a constant governing how strong the yellowing effect is, and c2 the same for blue-ing.

Brushguy Woodthreep said:
The floor and door colours are both exactly the same distance around the colour wheel from the base colour, just in opposite directions. Something along these lines:

So in theory, both the floor and doors should coordinate equally with the walls, and all three should be quite cohesive with each other... at least if I exclude the relative hues that are clearly not working (the ones close to 90 degrees around).

Wait, I'm lost. If you're using triadic colors, then you're using colors that are 120 degrees from each other. No wonder many of your examples look clashing! Do not use triadic colors for doors, walls and floors, they're meant to be used for compositions where all three colors cover a similar percentage. Doors are far too small to balance the other two.

Instead use something closer to analogous or split complementary for the floor and walls. I would worry about doors last of all, and frankly for the time being you could get away with leaving them gray until you nail the other two.

Brushguy Woodthreep said:
Now that I look, the examples in the picture are basically 30 degrees, 120 degrees or 150 degrees. I guess I should stick to regions around there.

If you really want to treat door color as a same-order citizen than the others, I think analogous or split complementary would work far better than triadic indeed. This is because in these, removing one color leaves you with a duo that still works (analogous and complementary respectively, corresponding precisely with the two options I mentioned in my previous post).

Brushguy Woodthreep said:
I'm reluctant to make the doors the same colour as the floor, because when I tried this before it made them kind of muddy and invisible... but the palette routine is pretty flexible, so I can play around some more and see how I feel. At a glance, using the same colour for both can definitely work for some colour pairings. The key is that even though the base colour is the same, the doors have a lighter ramp so they don't totally blend into the floor:

This was exactly what I was going to suggest for doors indeed, use a different ramp. However, using either analogous or split complementary would probably work even better.

Brushguy Woodthreep said:
So I'll experiment a bit more. Though I do have to say, for the examples where 3 different colours works, I think it really works. I'd rather not completely throw that out if it can be salvaged into beauty with some rule tweaks.

Actually, it's counterintuitive, but any of the techniques discussed above would get more variety than triadic. The reason for this is degrees of freedom: triadic only has one, because once you pick one color, the other two are the same relative to them. But:
- If you pick colors for floors and walls using complementary and analogous you get an additional choice (whether to use one or the other) which would drastically change the look of the dungeon.
- If you pick colors for floors, walls and doors using complementary split and analogous you get potentially two additional degrees of freedom: 1) whether to use one or the other, and 2) in the case of split, whether the door color is the "far" one (so you'd get a dungeon with similar but still distinct wall and floor colors, and very visible doors), or one of the closer ones (you'd get a dungeon with very distinct wall and floor colors, and doors with colors analogous to one of them).
Edit: I just realized that the only difference between [picking by analogous] and [picking by opposing split where the "far" color is the door] is just the color of the door; and in such cases it's almost certainly the opposing split version will look better (it will add some color to the dungeon by having distinct doors), so I would say that [always use opposing split] is the best choice overall (even better than [alternate between analogous and opposing split]).

Brushguy Woodthreep said:
What's this? Mr Definitely-pick-a-palette-and-stick-to-it is saying I shouldn't worry about my game's overall palette coherency???

I think you may have misunderstood what the point of having a palette is. :)

The reason to pick a palette such as Endesga or DB32 is that its authors have dedicated a lot of time handcrafting a palette that is optimal in its distribution of colors. If you're going to generate a palette procedurally, especially a palette that already has defined color ramps, collapsing it further seems entirely pointless. The only reason you could have for that is giving some consistency to the run, but the odds that a player will recognize that a shade of green from dungeon 1 as being the exact same one used in dungeon 5 is, well... unrealistic. It would be a different matter if your palette had, say, four colors: then obviously the player would recognize them as being used over and over.

Brushguy Woodthreep said:
=P

I do think it adds a bit of subtle flavour if the colours are unified, but overall, I would agree with you... if the generation was only for the dungeon palettes. The plan is to add in extra ramps for all kinds of things: the overworld, the player character, the enemies, the NPCs, etc. If none of those cross-pollinate their colours at all, the game will be an uncoordinated mess.

There's several reasons why I disagree:
1 - A game with 256 colors at once doesn't look intrinsically worse than one with 16. Hell, quite the opposite; that's why jumping from EGA to VGA was so awesome (I think I just dated myself with this comment. :D).
2 - The point of having a limited palette in retro games is so that sprites can have those well-defined jumps between pixel groups. But your color ramps already serve that function; I don't think there's any need to discretize further.
3 - Even if you were to go for a more unified look, you should do this with the colors of the things that are going to be shown at once onscreen. Palettes of the different dungeons are precisely the colors you don't want to merge; at most you'd want to merge the current dungeon's palette with its enemies'. If you merge the colors of everything in a single run of your game (all dungeons, all enemies, everything) into 32 colors, you're going to end up with very distorted color ramps, especially at five colors per ramp.

Brushguy Woodthreep said:
So the idea is that it generates all of those, then reduces the palette down by looking at all of them together. How it works in practice remains to be seen, but that's the theory I have in mind right now!

Well, the good thing is that since you've already implemented it, you will be able to try with and without color merging. That said, until then my advice would be to make any further design decisions as if you weren't going to. ;)

werezompire said:
As long as people aren't outright copy/pasting our assets, I don't mind if their UI looks similar to ours.

You're an incredibly cool person and I was pretty much sure that'd be your stance on the matter, but pf course I didn't want to speak for you. :)

Brushguy Woodthreep · Jun 14, 2018

Weltall Zero I'll reply properly tomorrow since it's late, but I want to clarify one point quickly, since I clearly didn't explain it very well.

The reason I included the colour wheel illustration isn't that I was specifically using triadic colours. (If I meant that, I'd have only included the illustration of triadic colours.) It's that it always ends up with something not too dissimilar to any one of the three options shown.

In picking the two coordinating colours, the game chooses one distance from the base colour, and applies this same distance going around the colour wheel in both directions.

Right now the range of valid angles is very broad. However, because the angle for both colours is the same, it always ends up with analogous, or split complementary, or triadic... or less optimal possibilities like colours at 90 degree angles from the base colour.

By excluding certain angles, it should be easy to restrict it to the ones that look nicest while ensuring there are always three nicely coordinating colours. I assume the ones that have given the best results so far are closest to analogous or split complementary, both of which are very possible with the current routine.

Weltall Zero · Jun 14, 2018

Brushguy Woodthreep said:
Weltall Zero I'll reply properly tomorrow since it's late, but I want to clarify one point quickly, since I clearly didn't explain it very well.

The reason I included the colour wheel illustration isn't that I was specifically using triadic colours. (If I meant that, I'd have only included the illustration of triadic colours.) It's that it always ends up with something not too dissimilar to any one of the three options shown.

In picking the two coordinating colours, the game chooses one distance from the base colour, and applies this same distance going around the colour wheel in both directions.

Right now the range of valid angles is very broad. However, because the angle for both colours is the same, it always ends up with analogous, or split complementary, or triadic... or less optimal possibilities like colours at 90 degree angles from the base colour.

By excluding certain angles, it should be easy to restrict it to the ones that look nicest while ensuring there are always three nicely coordinating colours. I assume the ones that have given the best results so far are closest to analogous or split complementary, both of which are very possible with the current routine.

Ooooh, I get it now. Thanks, that makes sense; incidentally, it also explains how you also generated examples with colors that are actually similar to each other, which was a bit of a head-scratched for me given my initial assumption of pure triadic.

Jintor · Jun 14, 2018

Weltall Zero said:
I think with what I posted you should have a complete working system and solutions for all of your issues. What's your specific issue with "dequeuing"?

Probably the main problem can be summarised below

Weltall Zero · Jun 14, 2018

Jintor said:
Probably the main problem can be summarised below

Hahah, can you be a bit more specific? :D

Your game was in GameMaker, right? Do you think looking at the Unity code for my input queue would help you? It's in C# for whatever it's worth.

Weltall Zero · Jun 14, 2018

Well, here's the relevant bits in any case. I snipped out anything that wasn't relevant, so I don't make claims that this will compile as-is.

Within your control class you'd add something like this:

Code:

/// Inner class that stores a button press or release, with the timestamp when it occurred.
public class ButtonPress {
    public ButtonEnum button;
    public bool pressed;
    public float timestamp;

    public ButtonPress (ButtonControl control, bool pressed) {
        this.button = control.GetButton ();
        this.pressed = pressed;
        this.timestamp = Time.realtimeSinceStartup;
    }
}
 
/// Input queue.
List <ButtonPress> _inputQueue = new List <ButtonPress> ();

This is Unity's function that executes each frame:

Code:

void Update () {
    foreach (ButtonControl buttonControl in _buttons.Values) {
        if (Input.GetButtonDown (buttonControl.GetName ())) {
            _inputQueue.Add (new ButtonPress (buttonControl, true));
        }
        if (Input.GetButtonUp (buttonControl.GetName ())) {
            _inputQueue.Add (new ButtonPress (buttonControl, false));
        }
    }
 
    // Clear expired inputs from the queue.
    while (_inputQueue.Count > 0
        && _inputQueue [0].timestamp + TimeConstants.InputBufferLength
            < Time.realtimeSinceStartup) {
        _inputQueue.RemoveAt (0);
    }
}

This is the function that finds if a button is in the input queue, and optionally removes it from there as well

Code:

public ButtonPress FindButtonChange (ButtonEnum button, bool pressed, bool remove) {
    ButtonPress ret = null;
    for (int i = 0; i < _inputQueue.Count && ret == null; i++) {
        if (_inputQueue [i].button == button && _inputQueue [i].pressed == pressed) {
            ret = _inputQueue [i];
            if (remove) {
                _inputQueue.RemoveAt (i);
            }
        }
    }
    return ret;
}

Looking at this code now, it's somewhat inefficient (foreach in an Update function, creating and destroying ButtonPress objects instead of reusing them), I'll have to optimize it at some point.

Jintor · Jun 14, 2018

Thanks man you're too kind. I've got another day or so of work before I can really look at it but it's appreciated : )

Weltall Zero · Jun 14, 2018

Jintor said:
Thanks man you're too kind. I've got another day or so of work before I can really look at it but it's appreciated : )

Anytime! I should be off to bed anyway.

Looking at the code, something that may not be obvious: Unity's "GetButtonDown" returns true if and only if the button was pressed this frame (not, as one might think, if the button is currently held down). Same for GetButtonUp, it returns true if the button was released this very frame.

Jintor · Jun 14, 2018

i think there are equivalents in GM just glancing through the code recently. I've no idea how to read C# so that's another thing on the learning pile.

But as you say maybe the first priority this weekend will be git. lmao

Weltall Zero · Jun 14, 2018

Jintor said:
i think there are equivalents in GM just glancing through the code recently. I've no idea how to read C# so that's another thing on the learning pile.

But as you say maybe the first priority this weekend will be git. lmao

Hahah, definitely!

Brushguy Woodthreep · Jun 15, 2018

Weltall Zero said:
Oh, sorry about that, I completely missed that.
In any case, a simple, quick and dirty way to implement hue shifting would be, for each color in the ramp, add R = G = c1*(i/t), B = c2*(1-i/t), where i is the index in the ramp, t the total number of colors in the ramp, c1 a constant governing how strong the yellowing effect is, and c2 the same for blue-ing.

Ooh, that could definitely work. I was hoping to do it in HSV space so I had a bit more control over the exact shade of yellow/blue it's shifting to, but with a small tweak the method you've given here could be used to shift towards any colour at all.

Although, the idea is to only adjust the hue, since the saturation and value are already shifted by the rest of the routine. Maybe it is a bit safer/more thorough to do it in HSV space after all. It's also not complicated, just a bit fiddly because the hue goes from 0 to 1 but loops around, so I need to be sure it's really shifting in the right direction.

Weltall Zero said:
I think you may have misunderstood what the point of having a palette is. :)

The reason to pick a palette such as Endesga or DB32 is that its authors have dedicated a lot of time handcrafting a palette that is optimal in its distribution of colors.

As with everything in this game, my goal is to procedurally generate what other people have handcrafted.

On the one hand, I doubt a procedurally generated palette can match something handcrafted. On the other hand, the same is true of dungeons. It's still fun to try.

Weltall Zero said:
If you're going to generate a palette procedurally, especially a palette that already has defined color ramps, collapsing it further seems entirely pointless. The only reason you could have for that is giving some consistency to the run, but the odds that a player will recognize that a shade of green from dungeon 1 as being the exact same one used in dungeon 5 is, well... unrealistic. It would be a different matter if your palette had, say, four colors: then obviously the player would recognize them as being used over and over.

I'd say my goals in limiting the palette are twofold:

1. Prevent having colours appear on screen together that are subtly non-matching. Within each ramp the colours are already distinct, but I want to avoid (for example) having two marginally different mint green ramps on screen at the same time.

2. Restrict the variety of colours used across the whole run, so that the next run feels distinctly different. (I'd expect the user to mainly notice it when changing to a new run, not as they play through the current one. You get subconsciously used to the colours by the end of the run, and then suddenly you're hit with something new.)

Admittedly, I don't necessarily need to restrict the entire palette into 32 colours to achieve these goals, and #2 may be unrealistic.

Weltall Zero said:
There's several reasons why I disagree:
1 - A game with 256 colors at once doesn't look intrinsically worse than one with 16. Hell, quite the opposite; that's why jumping from EGA to VGA was so awesome (I think I just dated myself with this comment. :D).

This is a good point. Believe it or not, I just about remember this too =)

Since I can change the number "32" to absolutely anything, I might find that this is best as a larger number, perhaps calculated as a multiple of one of the other input values (number of dungeons, etc.). I'm not treating 32 as a magic number, just as an example.

Weltall Zero said:
3 - Even if you were to go for a more unified look, you should do this with the colors of the things that are going to be shown at once onscreen. Palettes of the different dungeons are precisely the colors you don't want to merge; at most you'd want to merge the current dungeon's palette with its enemies'.

This assumes that none of the enemies appear in multiple dungeons, or in both dungeons and overworld. If the same enemy appears in dungeon 1 and dungeon 5, I need to be sure it coordinates with both.

Weltall Zero said:
If you merge the colors of everything in a single run of your game (all dungeons, all enemies, everything) into 32 colors, you're going to end up with very distorted color ramps, especially at five colors per ramp.

This sounds less like an inherent flaw in the idea, and more like a problem of improving the colour merging function to minimise distortion.

In my experiments with Endesga for the raw art, I do have to say, it's great but it's not magic. For some colours, if you want to make a ramp with them, you will definitely get distinct shades, but you will have to accept some huge (sometimes jarring) leaps between shades, and occasional left turns into very dramatic hue shifting.

...Which is why I won't feel too bad if my ramps end up with the same thing.

Weltall Zero said:
Well, the good thing is that since you've already implemented it, you will be able to try with and without color merging. That said, until then my advice would be to make any further design decisions as if you weren't going to. ;)

Yup, turning it on and off is as simple as flicking a switch. Although, the further time I spend refining the colour merging routine might end up as wasted time. We'll see!

Jintor · Jun 15, 2018

funnily enough i'm actually driving myself crazy right now trying to figure out ideal sprite sizing. 32x32 isn't quite enough detail for me but 64x64sprites are looking a bit more like an adventure game than anything else (and I don't know what animating bigger stuff for that would be like).

i should make a bunch of temp 64x64 assets and see what the game looks like. Or... I guess I could go 48x48 or something and try that out too? I have no idea what that does to my resolution though ==;;

FantasticMrSnake · Jun 15, 2018

What is the most popular engine nowadays to do something (maybe 2D) for switch?
I have some experience with Unity, bus is unreal more used nowadays?
I also developed lots of stuff on cocos2d-x (and ios version) in the past, but i'm tired of c++, lol.

Weltall Zero · Jun 15, 2018

Brushguy Woodthreep said:
Ooh, that could definitely work. I was hoping to do it in HSV space so I had a bit more control over the exact shade of yellow/blue it's shifting to, but with a small tweak the method you've given here could be used to shift towards any colour at all.

Although, the idea is to only adjust the hue, since the saturation and value are already shifted by the rest of the routine. Maybe it is a bit safer/more thorough to do it in HSV space after all. It's also not complicated, just a bit fiddly because the hue goes from 0 to 1 but loops around, so I need to be sure it's really shifting in the right direction.

I think it's inevitable that you will affect the saturation and value anyway. My intuition is that if you don't affect them, the darker tones won't be blue enough (they'll be closer to black), and the lighter tones won't be yellow enough (will be closer to white). In that sense, I realized that my formula is probably good enough for darker colors (as it adds blue), but for lighter color it should not add yellow (it won't do much if the color is close to white), but substract blue. Perhaps it's as easy as simply averaging the blue channel with 0.5 or something like that! But I think you definitely got this and will nail it with a little experimentation; can't wait to see the results.

Brushguy Woodthreep said:
I'd say my goals in limiting the palette are twofold:

1. Prevent having colours appear on screen together that are subtly non-matching. Within each ramp the colours are already distinct, but I want to avoid (for example) having two marginally different mint green ramps on screen at the same time.

This seems like a quite hard thing to achieve. I'm not entirely sure automatic quantization will help here, as this seems more based on human perception than actual properties of the colors.

Brushguy Woodthreep said:
2. Restrict the variety of colours used across the whole run, so that the next run feels distinctly different. (I'd expect the user to mainly notice it when changing to a new run, not as they play through the current one. You get subconsciously used to the colours by the end of the run, and then suddenly you're hit with something new.)

Admittedly, I don't necessarily need to restrict the entire palette into 32 colours to achieve these goals, and #2 may be unrealistic.

I have a feeling it is. Hell, I've been working with DB32 for months, and I couldn't tell if a game uses it or not at a glance.

Brushguy Woodthreep said:
This is a good point. Believe it or not, I just about remember this too =)

Since I can change the number "32" to absolutely anything, I might find that this is best as a larger number, perhaps calculated as a multiple of one of the other input values (number of dungeons, etc.). I'm not treating 32 as a magic number, just as an example.

Personally I feel quantizing to a palette bigger than, say, 8 is not going to be restrictive enough that the player notices a different palette is used each run. 32 already seems impossible to notice, and any higher makes it even more so.

Brushguy Woodthreep said:
This assumes that none of the enemies appear in multiple dungeons, or in both dungeons and overworld. If the same enemy appears in dungeon 1 and dungeon 5, I need to be sure it coordinates with both.

Not really. There's nothing preventing you from conflating the enemy's palette and the current dungeon's. In other words, there's nothing preventing you from having the enemy have slightly different palettes in different dungeons.

Brushguy Woodthreep said:
This sounds less like an inherent flaw in the idea, and more like a problem of improving the colour merging function to minimise distortion.

It's impossible to avoid distortion if you're clamping colors. That's kind of the whole point of a limited palette; if you didn't have distortion when clamping, you wouldn't be changing your game's palette. There's an inverse relationship between number of colors and distortion, and since there's also a direct relationship between number of colors and "recognizability" of the palette, in the end you're going to choose between lack f distortion and recognizability.

Brushguy Woodthreep said:
In my experiments with Endesga for the raw art, I do have to say, it's great but it's not magic. For some colours, if you want to make a ramp with them, you will definitely get distinct shades, but you will have to accept some huge (sometimes jarring) leaps between shades, and occasional left turns into very dramatic hue shifting.

...Which is why I won't feel too bad if my ramps end up with the same thing.

Indeed, again that's the point of a limited palette. But the difference is that the color distortion you talk about is the result of changing your palette manually; choosing and replacing colors in sprites with the better looking ones from the palette (and even this is laborious, which is why I haven't switched from DB32 to Endesga). If you do it automatically (say, by using any image editing program to force the spritesheet to use the Endesga palette), the results are horrendous. And consider these are the results of decades of professional research into color clamping images, to provide the best perceptual result. It seems impossible for a single person to improve on these algorithms within a few months, or even years.

Brushguy Woodthreep said:
Yup, turning it on and off is as simple as flicking a switch. Although, the further time I spend refining the colour merging routine might end up as wasted time. We'll see!

Yeah, that's my intuition too. In any case, if you're really interested in researching it further, I'm sure there has to be a ton of literature about it.

Jintor said:
funnily enough i'm actually driving myself crazy right now trying to figure out ideal sprite sizing. 32x32 isn't quite enough detail for me but 64x64sprites are looking a bit more like an adventure game than anything else (and I don't know what animating bigger stuff for that would be like).

i should make a bunch of temp 64x64 assets and see what the game looks like. Or... I guess I could go 48x48 or something and try that out too? I have no idea what that does to my resolution though ==;;

Frankly I don't give a thought about my sprite's sizes, I just go with what seems to fit the scale. I also change the canvas size all the time to accomodate for animations that go "out of bounds". For example my characters are about 48 pixels tall, but most have sprites that are 128x128, to account for attacks in different directions.

But then again Unity doesn't give a damn about sprite sizes or grids or anything either, so GameMaker might be different and more restrictive.

WishyWaters · Jun 15, 2018

werezompire said:
As long as people aren't outright copy/pasting our assets, I don't mind if their UI looks similar to ours.

After making that post I looked over our backlog and I think I'm going to put in a feature that would help us stand out from similar layouts. It's an exaggeration on my part to begin with, since it's the location of the 3 main combat ui pieces, the actual pieces are styled pretty differently.

There are only so many ways to organize the player input, party status, and initiative list before you're looking close to someone else.

sabrina · Jun 16, 2018

in my never-ending quest to always keep working on the same thing, I remade one of the shield spells. The magic's been split up into elemental classes now instead of being everything goes, so this is the ice shield. (to be supplemented with gratuitous particles later)

Weltall Zero · Jun 16, 2018

sabrina said:
in my never-ending quest to always keep working on the same thing, I remade one of the shield spells. The magic's been split up into elemental classes now instead of being everything goes, so this is the ice shield. (to be supplemented with gratuitous particles later)

This is beautiful! Particularly love how three-dimensional it looks.

Acquila · Jun 16, 2018

I love the spherical effect! I expected a simple frontal magic ice shield for some reason.

I think it can be improved if the pieces are are made to look more 3D, like a few pieces flipping over into a darker side instead of just tweened rotate/scale.

eryngi · Jun 16, 2018

i got sick of my ambitious projects that never get finished and decided to try to make some relatively simple stuff.. but also to do some basic things i've not done much of before, like focusing on drawing graphics (instead of relying on trippy shader foolery), using specific palettes (instead of whatever random colours i feel like at the time) and hand made levels/etc (instead of procgen).. might start with a little shmup type thing, very basic, like Quad Fighter K which i've been enjoying heaps..

so i need scrolling tilemaps, and a way to script waves of enemies.. so far this is more engine dev than game dev. making "engines" is what i enjoy the most so :P

i started by doing what i've been meaning to do for years - made a shader to simulate proper paletted colour modes like on GBA/DS. it's so much fun, whyyyy did it take me so long to do this!? all it does is use the red channel of the source texture to pick a colour from the palette texture, to draw that pixel with.. palettes can be any number of colours, i'm using 32 atm.. it is nice being able to do real colour cycling and palette swaps, instead of my old way of changing the vertex colours of quads..

then i started making a robust and easy to use littile tilemap system. in the past i've just sort of coded what i needed, when i needed it. it always becomes really messy and hard to maintain after awhile. (wellll i'm sure this will too eventually, haha). my text printing code in particular has always been last-minute and just awful to work with. i want text boxes, and little console windows with a cursor etc. this time i planned everything out beforehand. the console and tilemaps are the same system, ie you can print text onto a tilemap if you turn on the cursor.. tilemaps can scroll and loop and are each self contained in their own little window (if i want multiple layers for parallax etc i'll just put them all on top of each other)... last night i gave the windows the ability to have borders and backgrounds..i really love them jrpg style text boxes =) won't really need them for a shmup, except for menus i guess, but i would like to make some text-heavy stuff in this engine eventually too....

here it is so far, with some random test tiles/maps and palette swapping:

next up i have to relearn how to manipulate textures in memory so i can give it a built-in sprite/tile editor, because drawing all the graphics using the red channel as a palette index is a hassle (well maybe there's a nice way to do this in some image editor, dunno? i want built in editors anyway.).... then i think the last thing i'll need before i can make this shmup thing is the way to script levels, which is something i've never even tried before... don't know exactly how i'll do that yet, i guess something like, in the map editor you place a spawner object on a tile, and when the player gets to within a certain distance from that tile, the spawner spawns its things.. seems like that would be enough for a basic vertical scrolling shooty game...

JonDadley · Jun 16, 2018

On a whim I added a photo mode to my cozy driving game. I'm not much for photo modes in games (except XCOM 2's propaganda centre) but people seem to be really into it. Goes to show your personal likes / dislikes can be completely out of whack with peoples tastes in general. I guess I should make this a more fleshed out feature now!

Kalentan · Jun 16, 2018

JonDadley said:
On a whim I added a photo mode to my cozy driving game. I'm not much for photo modes in games (except XCOM 2's propaganda centre) but people seem to be really into it. Goes to show your personal likes / dislikes can be completely out of whack with peoples tastes in general. I guess I should make this a more fleshed out feature now!

I'd honestly say, just wholesale just take the feature set from any of the recent Sony exclusives (God of War, Uncharted 4/LL) and so on and add as much as reasonable to your photomode. That should cover everything people would want. Obviously some stuff won't be needed but it's a good baseline.

JonDadley · Jun 16, 2018

Kalentan said:
I'd honestly say, just wholesale just take the feature set from any of the recent Sony exclusives (God of War, Uncharted 4/LL) and so on and add as much as reasonable to your photomode. That should cover everything people would want. Obviously some stuff won't be needed but it's a good baseline.

Yeah I think this is a good idea - I had loads of people linking me to videos of Max Max / Horizon / GoW photo modes so I reckon I'll sit down and analyse those today and straight up lift as much as possible like you say. Makes sense really, it's not an area I'm that knowledgeable about and a photo mode is sort of genre independent so it should be easy to directly copy what AAA have figured out already.

Lady Bow · Jun 16, 2018

Finished some css animations for Sir Plume!

Jump_Button · Jun 16, 2018

Well UK Gov mess up my pass port again so going be sometime before i can get my kickstarter up

sabrina · Jun 16, 2018

Weltall Zero said:
This is beautiful! Particularly love how three-dimensional it looks.

thank you ♥

Acquila said:
I love the spherical effect! I expected a simple frontal magic ice shield for some reason.

I think it can be improved if the pieces are are made to look more 3D, like a few pieces flipping over into a darker side instead of just tweened rotate/scale.

The original version was sort of a soap bubble/snow globe. Every time I tried drawing a simple frontal shield I didn't like how it looked in this perspective and art style... either too basic, or too detailed, and never a happy medium.

And I agree, it'd be better if I could rotate the pieces all the way around, but that's an extraordinary amount of work without a z buffer :(

Lady Bow said:
Finished some css animations for Sir Plume!

I love love love how much character you're putting into these poses. Keep it up!

Weltall Zero · Jun 16, 2018

I really should have used any of the other elite enemies (flying enemies are more obvious in how they follow you more closely, and any other enemy looks better because of their red windows / cockpit), but it's 4 AM and I haven't even had dinner yet so there it goes.

K Monkey · Jun 17, 2018

Weltall Zero said:
I really should have used any of the other elite enemies (flying enemies are more obvious in how they follow you more closely, and any other enemy looks better because of their red windows / cockpit), but it's 4 AM and I haven't even had dinner yet so there it goes.

thats shaping up quite good... u got that rampage feeling down

Pleiades · Jun 17, 2018

Been working on fleshing out my little project, some extra assets, some bigger enemies, some UI etc.

Some bigger and badder enemies:

Some UI work:

Some new assets in the form of a hidden base:

(full resolution: https://i.imgur.com/szokQkX.png )
(in gfycat form: https://gfycat.com/ClumsyNecessaryAuklet )

Jintor · Jun 17, 2018

ooooooh i like

Veidt · Jun 17, 2018

sabrina said:
in my never-ending quest to always keep working on the same thing, I remade one of the shield spells. The magic's been split up into elemental classes now instead of being everything goes, so this is the ice shield. (to be supplemented with gratuitous particles later)

That looked pretty good, so I went ahead and checked more of your gifs, some really nice work there. What is the game called?

sabrina · Jun 17, 2018

Veidt said:
That looked pretty good, so I went ahead and checked more of your gifs, some really nice work there. What is the game called?

Thank you! The working title is Moon Magnate, but that's subject to change.

Veidt · Jun 17, 2018

sabrina said:
Thank you! The working title is Moon Magnate, but that's subject to change.

Anywhere I can read more about it? How far along is your game in terms of development?

sabrina · Jun 17, 2018

Veidt said:
Anywhere I can read more about it? How far along is your game in terms of development?

Outside of occasionally posting about it here, discord, and twitter, there's not really much else. Two years along and I'm still in pre-production because the two times I entered production I didn't feel good about it. I really appreciate your interest though!

Veidt · Jun 17, 2018

sabrina said:
Outside of occasionally posting about it here, discord, and twitter, there's not really much else. Two years along and I'm still in pre-production because the two times I entered production I didn't feel good about it. I really appreciate your interest though!

What was the issue(s) you encountered when entering production? From a visual standpoint I'd say it distinguishes itself quite easily, the animation work is quite nice and the snippets of gameplay you showed seem to imply it's a sort of metroidvania (correct me if I'm wrong). I would definitely be interested in seeing more from it.

sabrina · Jun 17, 2018

Veidt said:
What was the issue(s) you encountered when entering production? From a visual standpoint I'd say it distinguishes itself quite easily, the animation work is quite nice and the snippets of gameplay you showed seem to imply it's a sort of metroidvania (correct me if I'm wrong). I would definitely be interested in seeing more from it.

I struggled a lot with identity. The setting changed, the story changed a few times, the era changed, I redesigned the player character a couple times, and the combat mechanics have changed a lot too. Part of the problem was a lack of confidence, and part of the problem was I never fully planned out the game so I kept adding things and adding things and adding stuff that I thought was cool. But what would inevitably happen was that I'd add enough things that I liked but didn't gel together that eventually I'd step back and see a messy patchwork of systems that didn't complement each other, and it'd make me want to start over.

I'm at a good place now. I'm more confident than ever. But I'm taking my time and enjoying the process instead of rushing to move onto the next bit.

Weltall Zero · Jun 17, 2018

sabrina said:
I struggled a lot with identity. The setting changed, the story changed a few times, the era changed, I redesigned the player character a couple times, and the combat mechanics have changed a lot too. Part of the problem was a lack of confidence, and part of the problem was I never fully planned out the game so I kept adding things and adding things and adding stuff that I thought was cool. But what would inevitably happen was that I'd add enough things that I liked but didn't gel together that eventually I'd step back and see a messy patchwork of systems that didn't complement each other, and it'd make me want to start over.

I can relate to that a metric ton. While I have the programming experience, pretty much everything else is ihavenoideawhatimdoing.jpg, and game design first and foremost. In the end I think a big part of making something new is throwing stuff at the wall and seeing what sticks. I implemented an upgrade system, but it wasn't fun, so I axed it.

I have to admit it's one of the things I didn't know I'd be able to do: one of my biggest fear was not being able to look at something I'd spend weeks or months making and actually saying "this detracts from the game, off with it". It was very relieving to realize I could do it, and it didn't hurt as much as I was expecting.

sabrina said:
I'm at a good place now. I'm more confident than ever. But I'm taking my time and enjoying the process instead of rushing to move onto the next bit.

Confidence is the most precious resource for indie devs, isn't it? People really don't realize how much we need it and how often we lack it. I'm no longer surprised to find even the most talented people second-guessing themselves, but really, your work is amazing and something to feel very, very proud of.

_Rob_ · Jun 18, 2018

I regret that I've been seriously neglecting this topic! Discord consumes me... nevertheless, so much inspiring stuff to catch up on!

The last few days have all been about upgrading old levels for me. Bringing areas I haven't touched since Unity 4 into Unity 2017 has been quite the task, but with all the new toys to play with (PBR, lighting, post processing etc) I feel like these areas are finally looking in line with the rest of the game!

sabrina · Jun 18, 2018

_Rob_ said:
I regret that I've been seriously neglecting this topic! Discord consumes me... nevertheless, so much inspiring stuff to catch up on!

The last few days have all been about upgrading old levels for me. Bringing areas I haven't touched since Unity 4 into Unity 2017 has been quite the task, but with all the new toys to play with (PBR, lighting, post processing etc) I feel like these areas are finally looking in line with the rest of the game!

Your color work always makes me so happy. Thanks for sharing!

Weltall Zero said:
I can relate to that a metric ton. While I have the programming experience, pretty much everything else is ihavenoideawhatimdoing.jpg, and game design first and foremost. In the end I think a big part of making something new is throwing stuff at the wall and seeing what sticks. I implemented an upgrade system, but it wasn't fun, so I axed it.

I have to admit it's one of the things I didn't know I'd be able to do: one of my biggest fear was not being able to look at something I'd spend weeks or months making and actually saying "this detracts from the game, off with it". It was very relieving to realize I could do it, and it didn't hurt as much as I was expecting.

Confidence is the most precious resource for indie devs, isn't it? People really don't realize how much we need it and how often we lack it. I'm no longer surprised to find even the most talented people second-guessing themselves, but really, your work is amazing and something to feel very, very proud of.

Thank you for saying that! To me, there's a separation between feeling like I'm doing good work and feeling like I'm doing the best work I could be doing. And, especially with the indie market as crowded as it is, I really want to put my best foot forward. Because at the end of the day that's all any of us can do :)

Ausroachman · Jun 18, 2018

Started Adding some destruction to my levels. Makes the gunplay alot more interesting.

Deleted member 5876 · Jun 18, 2018

Thats cool. How are you handling it? By predefining the fracture points as an animation in the models or are you doing actual procedural destruction?

Indie Game Development |OT 2018| Come, help, learn, show and tell!

Game Developer

Game Developer

Zeboyd Games

Game Developer

Game Developer

Saw the truth behind the copied door

Game Developer

Game Developer

Saw the truth behind the copied door

Game Developer

Saw the truth behind the copied door

Game Developer

Saw the truth behind the copied door

It's Pronounced "Aerith"

Game Developer

Game Developer

Game Developer

Saw the truth behind the copied door

Game Developer

Big Seller