Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Re:creation - a top down action adventure about undeads [hiatus]  (Read 202670 times)

0 Members and 2 Guests are viewing this topic.

Elias Daler

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #705 on: June 04, 2017, 03:13:20 pm »
That's a great falling animation!

It's always really interesting to me to see how other developers program their engines...there's a lot of ways to accomplish things I never would have thought of with my own style.
Thanks! I wish more people talked about their engines in depth. It would really help other people learn. :)

Hey Elias... when will you give to us the grace of an demo?  :D
Sorry, I have no idea. It's hard to work regularly with lots of study needed to do, plus I'm just starting to actually use my engine and not add new features all the time, so hopefully I'll get some estimate in a 2-3 months of work on the game. :)
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Elias Daler

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #706 on: June 12, 2017, 11:37:25 pm »
First of all...this thread have reached over 100,000 views!

I want to thank everyone for reading this thread and making it so awesome with your replies. I didn't think that my game will get so much attention and so I'm very glad it happened like this. Thank you.

What to you think of the thread so far? Anything that you want me to write more about or something unrelated to current progress that you want to discuss? :)


And it's time for another dev log!
Things are progressing quite well. I don't have much time to work on the game, but it's great to see how much I'm able to do with so little time!

AI field of view
I've used rectangles for AI previously, but it didn't work so well because human field of view doesn't quite work like that. I had no idea how to implement "circle sector" field of view, but it turned out to be pretty simple.
First of all, I wanted some way to visualize each entity's field of view. Thankfully, SFML has sf::PrimitiveType::TriangleFan for sf::VertexArray, so implementing CircleSector class was very simple.

Then came implementation for AI. So, here's what I do
1) Find all entities which are closer than circle's radius
2) Calculate dot product of enemy's heading and ||playerPosition - enemyPosition||. If it's less than cos(viewAngle/2) then player is in enemy's field of view.
Here's a picture for you to visualize what's happening:

3) Check if any obstacles or solid tiles are on the way between enemy and player. This is done via ray-tracing. Right now I use one ray which goes from enemy to player, but one ray may not be enough because of situations like this:

Instead, I'll use three parallel (or maybe at small angle?) rays so that this will happen instead:


Entity's heading
Previously entities could only face four directions only: up, left, down and right. This came from animations being drawn only in four directions, so I didn't have direction vector. But having it is certainly is useful, especially for AI! This also lets me easily compute current entity animation direction based on current heading.
As you can see here, archer's field of view turns smoothly instead of player's discrete heading movement (that's because I'm using keyboard to move, only gamepad's stick can be used to achieve smoother movement)

This seemed like a pretty big change for me, but good encapsulation helped me implement this in a few minutes! There were lots of calls like this:
someEntity.transform.setDirection(Direction::Down);
So, all I had to do now is to set needed heading to (0, 1) instead of setting direction variable to Direction.Down. I've also had to rewrite getDirection function to return one of four directions based on heading variable, but that was pretty easy to do, of course. And that's all I had to change in regards to previous direction variable being used by some systems. Imagine if this field was public? Ohh, I'd have to change a lot! So, getters and setters can be an important time-saver sometimes!

Improved archer's AI
After field of view improvement I decided to tune archer's AI a bit. I made archer follow the player so that he could get a better shot. The algorithm is pretty simple right now, so I won't explain it.

As AI gets more complex, I'm thinking about trying to use behaviour trees, but we'll see, maybe state machines with some simple goal based system will work just fine! If anyone dealt with behaviour trees before, please tell me your experience with them.

Small (but important) changes
First of all, I've finally started to render stuff to sf::RenderTexture so that I will always get pixel perfect rendering even when rotating/scaling stuff. It also prevents tearing even at weird resolutions and also allows me to easily apply shaders to the whole frame.
And by the way, when I enter level editor, I start to render to window which can be of any size, so that I can zoom level out and still see things clearly.

I also finally moved origin of entity's position from top-left sprite corner to center of its collision box like this:

This makes a lot of things easier to handle as I usually want to position entities next to each other based on this origin, not on top-left corner of the sprite which is not useful at all. Using center of collision box as origin allows me to only store collision box size and I can easily calculate worldBoundingBox from player's current position and this size. This origin is also used for AI's field of view which works just fine. I'll also change sprite's origin based on current animation (e.g. if entity changes origin relative to frame boundaries).

And I also finally separated Animation from GraphicsComponent making AnimationComponent. This simplified a lot of things and I should have done it sooner, but oh well. The new AnimationSystem takes care of all animation related things and makes RenderingSystem's code even more simple.
« Last Edit: June 12, 2017, 11:39:06 pm by Elias Daler »
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

BluFedora

  • Newbie
  • *
  • Posts: 1
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #707 on: August 11, 2017, 07:54:56 pm »
Hey for the Archer AI (if you aren’t already), you should use the player’s heading to determine a direction to overshoot the arrow as to add a nice sense of difficulty. This would encourage quicker reflexes. Of course it’s your game but I want to help with this small suggestion. 😀

Schorsch

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #708 on: March 20, 2018, 02:34:13 pm »
Hey,
do you still develop on this game? I saw on twitter that you have another project with this games engine. Will you return to this one?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 9573
    • View Profile
    • development blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #709 on: March 20, 2018, 02:40:46 pm »
Checkout Elias' "2017" blog post where he explains the current situation with Re:creation. :)
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Elias Daler

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #710 on: March 23, 2018, 09:54:14 am »
Yes, situation is still the same. I'm working hard on Tomb Painter now. Re:creation is put on a shelf for now.
You can see Tomb Painter stuff on my Twitter (https://twitter.com/EliasDaler), and I'll make a thread for it here soon. :)
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

 

anything