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

0 Members and 13 Guests are viewing this topic.

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #555 on: March 27, 2016, 09:40:02 am »
Damn scarecrow, always causing trouble, so many places for it to be, but noo, slightly below the platform is the best spot.
Ha-ha :D

Also, what if I want to jump from the second to the first floor with the character (while performing a double front flip, of course) and want the impact to cause an earthquake that destroys the platform I was on? I think you should handle this situation as well.
I don't think I'll add jumping. It's pretty hard to implement and make levels having that in mind :)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Hyden

  • Guest
Re:creation - a top down action adventure about undeads
« Reply #556 on: March 27, 2016, 05:06:23 pm »
Love the art style.

bitano

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #557 on: March 27, 2016, 10:18:34 pm »
Looking at your (once again thorough) explanation including visuals, I wanted to reply with something quite profound....but couldn't think of anything. Mainly because i'm thinking you've investigated quite a few options yourself and therefore are well-informed on the pros and cons of each existing method.

I don't think I'll add jumping. It's pretty hard to implement and make levels having that in mind :)
Just wanted to add the question: Does this mean you also don't want to add falling from platforms and/or hovering off of them (or from one to the other) in ghost form?

Also you mentioned preventing placement of entities larger than 2 tiles in those zones, but what if you have a scenario with a 3 tile high moving entity?
Maybe an entity / mob would have a tile-height to check against (and simply cannot move underneath when tile-height > Z)?

Keep up the good work! :D

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #558 on: April 12, 2016, 11:56:25 am »
Also you mentioned preventing placement of entities larger than 2 tiles in those zones, but what if you have a scenario with a 3 tile high moving entity?
Maybe an entity / mob would have a tile-height to check against (and simply cannot move underneath when tile-height > Z)?
I will just keep large entities (mostly bosses) in isolated areas, so they shouldn't be a problem. :)
The problem is not with collision, it's with drawing order, so I just have to prevent large entities from appearing near bridges and stuff like that.

Progress update
Studying continues...

Not a lot of time to work on the game, but I managed to work on level editor for some time and implement some cool stuff with ImGui:

There's a room for improvement, of course! For example, adding a small preview for each entity in Entity Creation tab.
I've also drawn some new cool stuff but I'll show it once everything is completed.

I've also made a repository which contains the code which I use for ImGui. The related discussion about it will be here:
http://en.sfml-dev.org/forums/index.php?topic=20137.0
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 #559 on: May 07, 2016, 02:48:34 pm »
I'm back again! While I was busy studying I've had some time devoted to the game and I'll have more of it in the next months, so the progress will be faster hopefully. :)

Here's the latest screenshot from the game!

As you can see, there are some new graphics there. Houses were previously just sprites, but now they're created out of tiles which makes creating new variations of houses much easier! Their proportions changed too.

I've also redrawn main character sprite which is more undead-y and has a lot more detail in it!

I've also worked on the level editor a lot. (click or zoom in to view in better resolution)

Now I can add tile overlays which makes creating combinations of tiles easier and lets me greatly reduce the number of tiles in tilesets. This makes creating more interesting levels and changing/reusing graphics much easier!
I can also set z-levels for tiles now which determines drawing order (for example, if the tile has z = 1 then all entities with z less than 1 will be drawn below the tile).

One interesting change in code I've done was using std::stringstream to parse bitmap font config files (BMFont format) and level files which reduced loading times a lot (not like it was very high, hehe).  Previously I had a function which worked like this:
auto tokens = splitString("firstToken,secondToken,thirdToken", ',');
// returns std::vector<std::string> with "firstToken", "secondToken" and "thirdToken" in it
for(auto& token : tokens) {
   ... // do something
}
 
This function used stringstream internally but it was still much slower than this code:
std::stringstream ss(str);
std::string token;
while(std::getline(ss, token, ',')) {
    ... // do something
}
There were thousands of splitString calls during level/bitmap font loading, so replacing it with a better solution improved perfomance a lot.
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Mr_Blame

  • Full Member
  • ***
  • Posts: 192
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #560 on: May 07, 2016, 09:04:24 pm »
Very cool GUI!
Did you use premade lib or made one yourself?

EDIT:

Found it as your project, and I like it.
« Last Edit: May 07, 2016, 09:08:02 pm by Mr_Blame »

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Back to C++ gamedev with SFML in May 2023

TheGuerilla

  • Newbie
  • *
  • Posts: 27
  • Cynical Prick.exe
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #562 on: May 09, 2016, 01:30:19 am »
Game looks pretty damn good. Any vague idea when a release will be availible?

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #563 on: May 09, 2016, 09:37:51 am »
Mr_Blame, thanks!
TheGuerilla, thank you. To be fair, I don't have any idea about the release sadly. Hard to predict how much I'll be working in the next months and how much time some stuff is going to take. My aim for now is a demo which is still not near horizon sadly but I'll try to finish it this year.
Right now I have 2-4 hours per day to work on the game. This isn't much to be fair so even little things take a lot of time considering I have to do everything in those 2-4 hours: programming, art, level design, etc.
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Mr_Blame

  • Full Member
  • ***
  • Posts: 192
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #564 on: May 09, 2016, 10:10:08 am »
My aim for now is a demo which is still not near horizon sadly but I'll try to finish it this year.
Welp, will check this thread as rapidly as I can to not miss the demo release :)

EDIT:

Download you SFML version of imGui, this lib will definitely go to my SFML-app-making-lib-collection(or just SFMLamlc).
« Last Edit: May 09, 2016, 10:13:44 am by Mr_Blame »

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #565 on: May 09, 2016, 09:55:06 pm »
Implemented much better zoom in. This one responds to where the mouse points and is much smoother than the previous one (the previous one was jitterry because of rounding errors!)
This was made with the help from this tutorial by Hapax!


As I made some work with sf::Views I've realized that the way I was doing things was quite awkward. To be fair, I have global pointers to the views as I sometimes need to switch some view, draw something, switch to another view, etc. This leads to some confusion and globals feel just very wrong.

Here are the views I have in my engine:
1) Game camera view
2) Game camera view with rounded position for pixel-perfect rendering
3) GUI view
4) Level editor view

So, where can I store sf::Views to get easy access to them? How do I make sure that stuff gets drawn correctly? Should I keep putting window.setView in the beginning of each render() function call? (There're several of them, so there may be bugs because some previous function changed the view and the next one assumed that window has another view...) I can't just pass sf::View* to each render() function, because one render function may use several views at one (for example, GUI can be drawn in GUI view and some stuff may be drawn with game camera view, for example when drawing some GUI stuff relative to game entities)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

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 #566 on: May 10, 2016, 01:53:40 am »
You could set the view at the beginning of each render function. It's a tiny thing to do. How many render functions do you have?
If you want to definitely avoid setting them unless they've changed, another option could be to store flags that keep track of if a view has been altered and set the view depending on the flag.
That said, what difference is it making? Are you altering the views in the rendering functions? It may be better to set up each of the views that are needed before any rendering occurs and then just switch amongst them during rendering. Should the views really be altered by the rendering process?

p.s. glad you found the view zooming code useful :)
Depending on how you want the interface to be, you may want to zoom out (only out!) from the opposite pixel (window size - mouse position in window). Try both ways and see what works best for you!
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #567 on: May 10, 2016, 09:21:50 am »
You could set the view at the beginning of each render function. It's a tiny thing to do. How many render functions do you have?

Not much, in the game it's just two render functions: for the game and for the GUI. But level editor is much more complex: some GUI is drawn with window default view, some GUI is drawn in the world itself (stuff like bounding boxes). So at least two views are needed. Probably the level editor instance will store them as others won't need it.

If you want to definitely avoid setting them unless they've changed, another option could be to store flags that keep track of if a view has been altered and set the view depending on the flag.
That said, what difference is it making? Are you altering the views in the rendering functions? It may be better to set up each of the views that are needed before any rendering occurs and then just switch amongst them during rendering. Should the views really be altered by the rendering process?
Views won't be altered during the rendering. I just don't know what is the best way to access them from rendering functions without using globals. Well, maybe I can add them to Context struct which can be accessed from GameStates, so I can do something like this:
auto& view = *getContext()->gameView;
But PlayingState::render calls RenderingSystem::render so RenderingSystem doesn't have access to Context. So, I should probably pass needed views to the RenderingSystem::render function?
Or maybe I should just do this in PlayingState::render:
window.setView(gameView);
renderingSystem.render(window);
and hope that I won't ever need to draw anything in GUI view from renderingSystem function. :D

EDIT: After a lot of refactoring I've managed to manage views pretty nicely by putting them into Context struct which can be used from GameStates. So the problem is no longer relevant, unless someone has a better approach!

p.s. glad you found the view zooming code useful :)
Depending on how you want the interface to be, you may want to zoom out (only out!) from the opposite pixel (window size - mouse position in window). Try both ways and see what works best for you!
Tried zooming out with the opposite pixel - felt really weird, so I'm going to go with original version. :D
« Last Edit: May 10, 2016, 04:03:27 pm by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Carlos Augusto Br Cpp

  • Newbie
  • *
  • Posts: 40
  • Programming is life
    • View Profile
    • Email
Re:creation - a top down action adventure about undeads
« Reply #568 on: May 12, 2016, 07:07:13 pm »
Hey man...I'm your biggest fan..and I will realy apreciate if you support me..
I have some questions:
1) You use a game engine?If yes tell me what..
2) Where you learn your C++ skills...If you learn at your own tell me why and what material you use?
3) The same question as above but changed to Lua Language...

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #569 on: May 12, 2016, 11:20:44 pm »
Hey man...I'm your biggest fan..and I will realy apreciate if you support me..
I have some questions:
1) You use a game engine?If yes tell me what..
2) Where you learn your C++ skills...If you learn at your own tell me why and what material you use?
3) The same question as above but changed to Lua Language...
Hey! Glad to hear that, thank you!

1) I'm writing my own engine with the help of SFML. SFML is used for rendering, window creation, input and audio. This is just a basics upon which you can build a game engine which I'm doing right now. You should read this thread and my blog more, there's a lot of info about my engine. 
2) My C++ skills come from lots of books which I've read and lots of time spent programming in C++ (I've been developing in C++ for almost 7 years now!). I'm learning on my own, though there's a lot of help coming from more experienced people telling me what I'm doing right or wrong and telling about best practices.

I should probably write a recommended reading list on my blog, but I'll probably do it later. Okay, let's go!

C++
As far as the learning books go, I can't recommend C++ Primer (5th edition) by Stanley B. Lippman enough (not to be confused with C++ Primer Plus!).
Read it if you're not very confident in your C++ skills and want to learn it more.
As for more advanced/in-depth books (don't be afraid to read them, they're mostly not hard, they're just not tutorial books like C++ Primer)
  • Effective C++, Effective STL, Effective Modern C++ by Scott Meyers - very good and useful books. Some of the advice in the first two books may be a bit outdated because of C++11, but most still holds true. Some parts of Effective Modern C++ are pretty difficult (especially about rvalues and all that stuff), but there's a lot of really good advice there which is pretty easy to understand and apply to your code.
  • A Tour of C++ by Bjarne Stoustup - a nice and short book showing of modern C++ in all it's awesomeness. Lots of nice and clean code, lots of explanations about modern C++ stuff and more.
  • API Design for C++  by Martin Reddy - nice book about making good classes, interfaces and working with other people. At times it feels like Code Complete (which is another great book which you should read if you haven't already) which is a very good thing.

Resources:

Lua
There's probably only one book I can recommend: Programming in Lua by Roberto Ierusalimschy. Very well written and covers everything you'll need to know about Lua. Can be used for learning from scratch but provides a lot about more difficult concepts.

Resources:
http://lua-users.org/wiki/ - lots of tutorials, sample code, libraries and bindings.

If anyone has anything nice to add, feel free to do so.
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

 

anything