Re:creation - a top down action adventure about undeads [hiatus]

[SushiKru]

Hello

First congradulations for your game, it looks really awesome, i read some of your tutorials about entity/component/system and LUA and it's really helps me to understand how it works.
I have a question, i am trying (for learning purpose) to implement an ECS but i can't figure how the game state should be handled. By game state i mean the differents states of the game (title screen, options screen, loading screen, in game screen, maybe the fighting screen in a jrpg etc ...). Do you use a class above everything that will handle screen transitions or do you just use ECS to accomplish this ? Are your systems always working even if they are not needed ? for example does MovementSystem exists even if you are in the title screen ? Or do you add them depending on the screen ?
I was thinking about a GameStateSystem  but i am really not sure how it could work:

enum State { title, inGame, loading }
class GameStateSystem : System {

  void update() {
    if (m_nextState != m_currState) {
      switch (m_nextState) {
        case inGame:
           // what you do here ?
           break;
      }
    }
  }

  void setState(State state) {
    m_nextState = state;
  }
}

[Elias Daler]

SushiKru, thank you!

Here's one important thing: using ECS doesn't mean you have to build everything with ECS in mind. In my game, states are implemented as a bunch of classes which have enter, exit, update, draw, handleEvent virtual functions. I also have a stack of game states, so I can have PlayingState and then push GUIPausedState on top of it.

The StateManager calls update from top to bottom (GUIPausedState, PlayingState) and if one of the current states returns false, it stops. GUIPausedState can return false and then PlayingState update won't be called and this is what achieves pause.

On the other hand, draw is called from bottom to the to (PlayingState and then GUIPausedState). In GUIPausedState you can draw your overlay menu, for example.

All systems are created at the start of the game, but their update functions are called from PlayingState::update only (well, I also have RenderingSystem::draw and PlayingState::draw calls that, but for others update call is enough).

Transitions between states can be accomplished by making some states like FadeOutFromBlackState or something like that. And then you'll just have LoadingState pushing PlayingState and FadeOutFromBlackState to state stack after it's done loading stuff (and popping itself from it). And once FadeOutFromBlackState finishes, it can pop itself from stack (possibly sending an event which PlayingState and other things can catch, so it'll start processing player input and updating stuff...)

[Elias Daler]

Just a little thing I did in 3 minutes. But hey, it made such an improvement!

This works extremely simple: I just start playing "idle" animations from the random frames.
This will work really great for making the world feel more alive, especially when I'll add more animations to the scenery.

[SushiKru]

SushiKru, thank you!

Here's one important thing: using ECS doesn't mean you have to build everything with ECS in mind. In my game, states are implemented as a bunch of classes which have enter, exit, update, draw, handleEvent virtual functions. I also have a stack of game states, so I can have PlayingState and then push GUIPausedState on top of it.

The StateManager calls update from top to bottom (GUIPausedState, PlayingState) and if one of the current states returns false, it stops. GUIPausedState can return false and then PlayingState update won't be called and this is what achieves pause.

On the other hand, draw is called from bottom to the to (PlayingState and then GUIPausedState). In GUIPausedState you can draw your overlay menu, for example.

All systems are created at the start of the game, but their update functions are called from PlayingState::update only (well, I also have RenderingSystem::draw and PlayingState::draw calls that, but for others update call is enough).

Transitions between states can be accomplished by making some states like FadeOutFromBlackState or something like that. And then you'll just have LoadingState pushing PlayingState and FadeOutFromBlackState to state stack after it's done loading stuff (and popping itself from it). And once FadeOutFromBlackState finishes, it can pop itself from stack (possibly sending an event which PlayingState and other things can catch, so it'll start processing player input and updating stuff...)

Yeah this is what i read on few topics in stackoverflow or gamedev. I think the RenderSystem is a special case, i can't imagine how it could work if the render is done in update(), the idea of having a draw() function that is called at a specific time is probably a better solution. You can even call it on a different thread so you will use 2 cpus core (well it's overkill for a 2D game probably  )
Thank you for the answer, so a state machine above everything, and depending on the state i could create different ECS. It's really hard to understand fully ECS, when you start using it, you want to do everything with it but it's probably not a good idea.

[Elias Daler]

You're welcome!
I think it's better to update more than you render. Sometimes you can update faster than you draw, it's good for input and slowdowns due to rendering (e.g. if you start rendering at 20 FPS, your deltas get big and may kinda ruin your physics system, things like "bullet through the wall problem" and such).
Check out this implementation of the game loop, I like it a lot and currently use it for my game.
As for the ECS - just use it for game objects only. Don't bother with the rest until you have a reason to do so. Keep things simple!

[Hapax]

Animation offsets add natural feel to them. Good addition!

I think it's better to render more than you update.

I think it's possible that you may have phrased this incorrectly.

[Elias Daler]

Animation offsets add natural feel to them. Good addition!

Thanks!

I think it's better to render more than you update.

I think it's possible that you may have phrased this incorrectly.

Oops, I'll fix that

[Elias Daler]

Little details... Cat's talking animation stops when translation is shown.

And meowing now corresponds to translated text more, he-he.
Don't worry, I work on much bigger stuff too, I just don't have much time to write it down! (Everything will be written in a huge blog post soon)

[Elias Daler]

Working on a lot of engine stuff. Not just for "I'm gonna need this later", but just finishing very important stuff which is crucial for quick iteration and development.

One such feature is a console, which was previously written in SFML, but now is written with ImGui! It finally has history, native-like text field, scrolling, etc.
And I've made special "Lua" mode for it, which lets me just input Lua commands which are then called with lua_dostring. This allows me to do stuff like this!

And that's just one tool which will make my life better. There are other tools which I'll soon show, which will free me from printf debugging! (some things can't be debugged with printf/cout/breakpoints!)

Also, I only recently understood that it's time to move my object's origin to something reasonable.

Like this. Previously it was left up corner of a sprite. Yeah, silly, I know!
I wonder if there'll be some things which are obvious, but aren't talked about often. (just remembered that I created "damage" entity instead of just placing damage rect and disabling/enabling it when attack occurs).

One more thing I want to talk about: what is the best way to handle collision rect? In some games it's okay to have a static one, but in my case, it should change depending on entity's direction, and maybe even on animation! (Fighting games do this). And I wonder... what's the best way to separate animation and collision so that they won't depend too much on each other? Any ideas?

[Ethan.Calabria]

And I wonder... what's the best way to separate animation and collision so that they won't depend too much on each other? Any ideas?

I don't know what the best way is, but the way I'd do it is have animation frames associated with an attack geometry class.  The class would describe the initial size of the collision geometry (a rect for example), and then keys for size and rotation, which would be interpolated over the frames until the end frame (which could default to the animated end, or be specified).  It would have an entityID associated with it. 

I'd do basically the same thing for the hitboxes.  Then I'd sort them based on which quadrant (or some smaller factor) they're in.  There would be a similar sort for the collision geometry.  When any collision geometry was active, it would then check against the hitboxes in it's same quadrant.  If it hits, the event system would tell the attacker it hit, and the one attacked that it was hit...and then those entities would handle their own behavior. 

That's my very straightforward approach.  I'm not really sure how well it would work, my own game is turn-based, so the animations themselves don't determine if something is hit or not, that's determined beforehand.  I tried to keep it fairly generic since I don't know how you have your game set up.  Anyway, don't know if you'll use any of those ideas, but maybe it will inspire something cleverer.

[Elias Daler]

Thanks for your ideas Ethan, I'll certainly think about how to make something similar in my game.
Sorry for no posts lately. I'm working hard on the game. So much stuff done, that I'm afraid that writing about them will take me a lot of time. But there's so much nice stuff I did! So I can't promise anything at the moment, but I'll try my best.

P.S. gifs from my game got featured in an ImGui talk. That's pretty nice.
https://youtu.be/LSRJ1jZq90k?t=3m18s

[Mortal]

that's really a good news, congrat for your success Elias. 

when you going to release the game. i believe this is good time to this step. "CppCon" is sponsored by Microsoft and Google and many more.  even the entire C++ community are gathered in "CppCon" conferences. this is great opportunity for you.

[Elias Daler]

Thanks!
Yes, I hope that I'll be able to deliver some talks at CppCon some day. Maybe something about Lua/C++ interaction, maybe a Re:creation dev talk or postmortem (*wink-wink*) one day.

I need to work hard to make this happen!

[Hapax]

Still going well, I see!

I have just noticed that the shadows are slightly mismatched.


The angles of your dynamically created shadows are different for differently sized objects. For example, compare the building's shadow to the shadow of the small item in front of it.

You can see it more clearly in your original explanation. The vertical line of the building should have its shadow at the same angle to the scarecrow's shadow vertical line. The scarecrow looks more skewed than the building.

If I was to guess, it looks like you the skewing is done based on offsets which are based on overall size (or similar) but the angle of 1-2 (and 0-3) here:

should always be the same for every shadow.

[Elias Daler]

Yep!

Thanks for noticing that. I'll try to see how I can make it more consistent. 
But I'm doubting that automatic shadows will work as good as I thought, so maybe I'll have to go back to hand drawn shadows.
The biggest problem is objects casting shadows on walls/non-flat surfaces. See the tree on the left in the latest gif. The shadow should be different. (Or maybe I shouldn't place trees like this, but this will limit level design, which isn't very good).