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 499091 times)

0 Members and 9 Guests are viewing this topic.

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re:creation - a top down action adventure about undeads
« Reply #675 on: November 10, 2016, 11:35:28 pm »
You could break them up and seperate into sections for different planes. For examples, that tree's shadow would have two parts: one for the ground and one for the vertical building front.

Personally, I would think that hand-drawn shadows are the better option. That way they appear exactly as you intend. The worst culprit for automatic shadows are things like trees that are quite deep and should have a mostly round shadow since the light is usually somewhat above and the viewer is not.

Manually drawing shadows can take more time, though, and may still become victim to level-design. Again, with that tree, a hand-drawn shadow would still have to take into account that building...

That's right; I'm always here to spot the insignificant things ;D
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

felaugmar

  • Guest
Re:creation - a top down action adventure about undeads
« Reply #676 on: November 11, 2016, 02:19:03 am »
I kind of liked your idea @Hapax;
Two generated shadows.

Do a try @Elias Daler, for sure the effect will be interesting.  ;D

But for a more dynamic shadow maybe you need to add the shadow to collision system and re-create based on the objects touching it.
Hmm, maybe it's not so simple :)
« Last Edit: November 11, 2016, 03:13:29 am by felaugmar »

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #677 on: November 15, 2016, 08:03:18 am »
Don't make him over-engineer even more, @Hapax. ;-) IMO they look just fine right now. Making them better should probably be targeted in the polishing state.

grumpaladin

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #678 on: November 17, 2016, 04:46:37 pm »
I seem pretty late to the party but I just wanted to say that this project looks amazing and it's very inspiring.

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #679 on: November 17, 2016, 06:16:19 pm »
Hey everyone, sorry I didn't write anything for such a long time!
I have some very good news: I've got a new laptop! My old one was six years old and developing on it was very painful for me, compilations took a really long time, VS randomly freezed from time to time, etc. But now everything works so fast! Pair that with VS 2017 RC which is even faster than VS 2015, and I'm perfectly happy. :D

I'm currently writing a dev log about what I've done in the last four months, it should be done in a week, maybe less. So much stuff to cover...

I also started working on my Master's thesis project which will be done in Unreal Engine 4. It probably will be very time consuming, so I won't have as much time to work on the game as I previously had... but on the other hand, I'll still be doing game dev and learning about good engine and game design. Maybe I'll apply some of the stuff I learn to my engine (without over-engineering, of course! I'm constantly amazed by amount of stuff UE4 has...).


As for the lighting... I think I'm going to draw them by hand because having some shadows hand-drawn and some generated will look odd and not very consistent. I'll try to find a way to draw as less shadows as possible, because that's what SNES games did and still looked very nice.

Drawing vertical part of the shadow on other objects is a good idea, unfortunately it will only work in cases where the object has flat surface and is perpendicular to the floor. Otherwise I'll have to do normal maps, specify entity's surface type, etc... That's too complex! So yeah, I think hand drawn shadows are the way to go.

grumpaladin, thank you!  ;D
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #680 on: November 27, 2016, 10:16:25 pm »
New Re:creation dev log. Talking about what I've done in the last five months. I hope you find it interesting to read!

Feel free to ask stuff about things mentioned here. And I'll probably start posting regurarly soon! Just didn't want to bore you with all the restructuring and refactoring. :D

P.S. One quick question for people who've done it before... How can I easily manage input contexts? (switch input callbacks during menus, interactions, etc.)
For example, if the player goes near some NPC, primary action button calls "interact" function, not "use primary item" button. Right now I manually handle such input changes, which means that I have to manually change input in menus or dialogues and later restore it to previous state... I'm afraid that it may lead to some nasty bugs!)
« Last Edit: November 27, 2016, 11:05:53 pm by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

sjaustirni

  • Jr. Member
  • **
  • Posts: 94
    • View Profile
« Last Edit: November 27, 2016, 10:32:56 pm by sjaustirni »

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #682 on: November 27, 2016, 11:05:32 pm »
I haven't implemented complex GUIs yet, but if I did, I'd probably use a simple State Machine http://stackoverflow.com/questions/595231/state-machines-and-user-interface-work-any-examples-experience
https://en.wikipedia.org/wiki/Event-driven_finite-state_machine
https://developer.apple.com/library/content/documentation/General/Conceptual/GameplayKit_Guide/StateMachine.html
I already have state machines implemented. I have thought about FSMs for input, but seeing how much states and transitions I'll have makes me sad. :D

Just some examples. Input may have these states:
1) WASD - move, F - attack, T - become a ghost (normal state)
2) WASD - move, F - select a corpse, T - return to main body (recreation/ghost state)
3) WASD - move, F - interact, T - become a ghost (when possible to interact with entity)
4) WASD - move cursor, F - choose primary item, Enter - close the inventory (in Interaction state)
And then we have dialogues...
5) F - speed up the text (when text is being displayed)
6) F - next phrase/dialogue line (when all text in current phrase displayed)
7) AD - select answer, F - confirm.
etc.

Tons of states, tons of possible transitions... For example, suppose player goes near some NPC and talks to it.  Transitions: 1->3->5->6->3.
What if NPC goes away after the dialogue? We get this: 1->3->5->6->1.

(Or maybe this isn't that bad as I think? Maybe if I manually manage transitions in code, I can make it all maintainable...)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

sjaustirni

  • Jr. Member
  • **
  • Posts: 94
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #683 on: November 28, 2016, 03:15:22 pm »
I do not have the needed insight, but it seems, that you  have 2 main states (non-dialogue and dialogue), with 2 more levels of depth for the former, whilst each state has up to 2 possible transitions.

Try to draw diagrams and also go hierarchical. FSMs are always easier with diagrams.

Tukimitzu

  • Full Member
  • ***
  • Posts: 117
  • Anti-Hero Member
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #684 on: December 05, 2016, 04:28:45 pm »
Can you explain how did you made so your console input text box stay active after pressing enter?
(click to show/hide)

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #685 on: December 06, 2016, 08:39:16 am »
Can you explain how did you made so your console input text box stay active after pressing enter?
(click to show/hide)
Check out imgui_demo.cpp and how Console example is implemented there, it's pretty complex and I just copy-pasted this code.


The work on the game continues! And the biggest change I've made since the dev log is GUI implementation.
Previously I did GUI manually. Storing various sprites and GUI's state in GameStates, etc. But this causes the following problems:
1) Some GUI code was very repetitive
2) GUI was hard coded, I've manually set positions to each sprite and text string
3) GUI callbacks were in C++ which I don't like, because with most of the logic, game state and wrappers being in Lua, it's much easier to do things on Lua side.
4) I've managed to remove almost all GameState's, but GUIs were pretty hard to do in Lua, so I couldn't move GUI states there. (main menu, inventory screen, game UI, dialogue GUI, etc.)

My first idea was not the easiest one: I wanted to expose some of SFML's interface to Lua to draw GUI stuff from Lua and handle all the logic there too. Looking back at it now, it just looks like a really bad idea which would have cost me tons of hours!

Thankfully, after I've started making C++ GUI classes, I've realized that there's no need for doing drawing or even basic GUI logic in Lua! So, let's look at the current stuff I've got going. Here's how the main menu looks now (it isn't a final look, of course!)


Here's a JSON which defines it:
(click to show/hide)

As you can see, GUI has a few basic classes: StaticText, TextButton, Image, NinePatch. I can create children to any element and what's nice is that all positions are kept relative to the parent element, so it's easy to organize stuff! Right now the positions are still kinda hard coded (no automatic placement and aligning), but it's totally fine.
I can also add callbacks to buttons like this:
return {
        callbacks = {
                {
                        tag = "CONTINUE_BUTTON",
                        onPress = function(self)
                                continueGame()
                        end
                },
                {
                        tag = "NEW_GAME_BUTTON",
                        onPress = function(self)
                                print("NEW GAME IS NOT IMPLEMENTED YET")
                        end
                },
                {
                        tag = "EXIT_BUTTON",
                        onPress = function(self)
                                exitGame()
                        end
                }
        }
}

There's nothing novel about the implementation, just base GuiElement class which inherits from sf::Drawable and sf::Transformable, has some children and virtual load, update and draw functions.
Cursor has pretty nice input: it's kinda like key repeat, when you hold "down", it scrolls down the first time with bigger delay, but then continues scrolling down with less delay between "ticks". I manually keep track of time for delays to make it available to gamepad input and also not to depend on system settings (you can easly change delay of key repeat).

GUI system is already powerful, I've managed to make a Dialogue GUI with it!

It looks and behaves the same way as the old GUI, but now it's much easier to control it, drawing it is just this:
target.draw(gui);

I will also implement main game UI next and also inventory screen. They will be a bit trickier to make, but it'll be so worth it. I'll also do options menu which will require some additional GUI work, but this will be done a bit later.

So, handling GUI is much easier now, but the best thing about it is that now I can have just a bunch of GameStates: MenuState (all the GUI will be there: main menu, dialogue, inventory screen, game UI, etc. and I'll just switch between them), LoadingState, GameState (which just calls updates to entity systems and rendering system draw function), TransitionState (used to in-between areas transitions, very tricky, uses some shaders, so I don't want to do it in Lua) and that's it! Other game states (mini-games, ghost state, etc.) can be easily implemented in Lua now.

They don't contain any of the game logic, all of it is now in Lua and this makes me incredibly happy! Engine and game are almost separate now, which means that it'll be easy for me to reuse my engine for other projects in the future.


I've also started working on AI... and there's so many things I have to do here! Better state machines (or maybe even planning system), better path finding... Path finding aspect is pretty hard to do, because I'll have to implement some algorithm for automatically building a nav-mesh (or maybe I'll be fine with just using grid graphs?) I don't want to create graphs by hand, it'll take lots of time and in the end it doesn't give very good results.

Some games just use steering behaviours for AI (and I've previously used just them too!), but this is only fine as long as your enemies are some monsters or "possesed" people (older Zelda games only use steering algorithms). I want enemies in my game be a just bit smarter and not get stuck in any obstacles on their way.


Enemies in Link to the Past get stuck all the time. They don't get completely stuck, however, because steering algorithm slides them along the wall. But it's still not as good as proper path finding. (Or maybe I'm overthinking it...)

Hope implementation of all that stuff won't take long. But I'm a bit glad that I'll finally get the chance to write all this stuff.


But that's not all. I'm also planning to work on combat system and I'll try to make combos, targeting and dodging to feel good. I want combat to feel a bit like it does in Dark Souls or 3d Zeldas. Basically, you approach the enemy, target it and now can circle around it, dodging it's hits and hitting it with combos. Not sure how it would work in 4 directions (it would have been perfect in 8 directions, but I can't draw so many animations!), and so far I haven't seen any 2d action rpgs with complex combat, so it'll be pretty interesting to see what I can do.

The closest to what I want is Bastion (hey, the main character uses hammer too!), but it uses isometric perspective and has 8 directions. If anyone knows good 2d top-down games with good melee combat system, please tell me about it! ;D
« Last Edit: December 06, 2016, 08:56:58 am by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #686 on: December 06, 2016, 11:36:17 pm »
If you want to be adventurous, Hyper Light Drifter has a pretty cool combat system iirc. It's not exactly like re:creation, but it is a 2d top down 8/16 style game, so I reckon if you use basic 2d Zelda combat as your base, you could take influence from more complicated systems like that of Hyper Light Drifter.

dabbertorres

  • Hero Member
  • *****
  • Posts: 505
    • View Profile
    • website/blog
Re:creation - a top down action adventure about undeads
« Reply #687 on: December 07, 2016, 02:54:01 am »
Here's what I can think of that I've enjoyed:

  • Stardew Valley
    • Based around blocking, timing, weapon length, attack speed, 4 directions
    • Kept simple due Link to the Past esque AI
  • Transistor
    • If you ignore the turn based time pausing side of the combat
    • same devs as Bastion and similar style
  • Hammerwatch
  • Titan Souls
    • Player doesn't do melee, but the combat generally involves melee enemies and is well done imo
« Last Edit: December 07, 2016, 02:55:44 am by dabbertorres »

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #688 on: December 09, 2016, 08:40:14 am »
Thanks for suggestions, guys! I'll totally check them all out. :D

I've also started working on AI!

The red path is original path found using Dijkstra's algorithm (going to implement A* soon!), the green line is "smoothed" path which just removes unnecessary edges to give even more efficient and natural paths.
The grid graph is created with a bit of brute force... I create a grid and then remove all vertices/edges which collide with the level. This gives somewhat okay result, though it's not very fast and very likely to be improved in the future.

I'm really glad it was pretty fast and easy to implement, there isn't much want to improve there! One more thing I'll soon add is wall avoidance which will make the movement even better.

From there I plan to implement a bit better AI state machines (or maybe I'll use behavioural trees and some goal planning behaviour). Some games use very simple AI, because the enemies are just some random monsters which may stuck in walls and it'll look okay, but in Re:creation you're mostly fighting with people, so they have to be somewhat intelligent, but of course I'm not going to make something overly complex.
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #689 on: December 09, 2016, 10:51:20 am »
To be honest this sounds a bit overkill for a tile based game with rectangular areas only. :) I'd try using some splines or bezier curve for the green path. Add some random deviation for a more natural movement and you should be fine.

Btw. you shouldn't have to create your navigation mesh before I think (although it's probably helpful). Have you tried just associating infinite costs with paths going through geometry?

 

anything