next »

[eliasdaler]

Thanks for sharing the info about your implementation. It looks pretty cool.
I've come up with other method which is to store ComponentHandles which hold index of a component in a vector. So, even if reallocations happen, the ComponentHandle would still be valid and you can get a component by this index.
But here are results of my tests.
Okay, so I've created this wonderful scene:

Lots of entities, moving randomly.
I've tested this scene with old ECS system (components are stored randomly in memory) and new ECS system (components are stored contiguously in std::vector).
The results shocked me: there was no perfomance increase.
This is not a dissapointing result for me (but kind of stange... I was expecting at least some perfomance increase). In fact, I'm quite relieved that I don't have to integrate the new system into my project (this would be painful and long).
But this was not a complete waste of time. I've come up with lots of useful improvements for my old system when I was writing the new system, so I'll improve my old system with that. I'll come back to actually making the game soon. So, expect to see some cool screens in the future

[eliasdaler]

Sorry for the lack of updates, been working on some awesome stuff and fixing bugs all week.
I'm working on a combat system and try to make it enjoyable and not boring. So far, the progress is great.
I'll work on the new art soon, so expect some cool screenshots and gifs.

I'm trying to focus more on making the game, not the engine for it, and it feels good. Are there any great articles about this? I want to plan better and focus on what's the most important.

And here's some random concept art:

[JobLeonard]

Making things not boring is a good ambition with games

I'm sure there's plenty of great articles on this, but I don't have them at hand. I'm sure others will step in though.

[eliasdaler]

Making things not boring is a good ambition with games

He-he. I just thought that combat would stay pretty simple, but I've thought that I must make it better and add some new mechanics. :D

[eliasdaler]

Another concept art of cafe

I'm working on art for it, so in-game screenshots will come soon.

[eliasdaler]

And now it's in the game. What do you think? :D

[eliasdaler]

Cute undead cat tells about its life:

And do you recognize the painting behind the cat?

There are some cool changes I've made lately.
First of all, I've changed the dialogue font. Compare it with the old one:

First of all, the new font is more readable. It also lets me fit a lot more text in the dialogue window.
The text doesn't scroll anymore. I think that separating text by meaningful chunks (1-2 sentences) keeps it more readable. That's how most games do it, anyway.
Because I have to fit as much as I can in one screen, rephrasing stuff is important. I think it's a good thing, because it keeps text short and precise (most people don't like to read long texts in games, unless it's a huge RPG with deep history).

I will also start to add line breaks myself (I was breaking text in lines automatically before). It lets me compose the text manually, so it looks and reads a lot better. If you look closer at NES/SNES games with lots of dialogue, you'll notice that most of the text fits the box very neatly.
To do this more easily, I'll create a tool which will let me edit text in it and immediately see how it will look in the game. This tool would also be useful for translators, I think. (especially for languages which have long words!).
I also added little talking animation which makes things a bit more lively. :D

I'll also start to move animation data from Lua to JSON, so the script won't take as much space as its currently does. For example, main hero's script is now 504 lines. 354 of them is devoted to animation descriptions (location on the sprite sheet, frame time, etc.). And there's no need to keep info like that in Lua files, because this info doesn't use any Lua capabilities. So, I would move each animation description into JSON file and then just write something like this in the script:

Code: (lua)

GraphicsComponent = {
    ... -- some stuff
    animations = "anim/hero.json"
}

This animation info would be loaded in C++ later.

Oh, and one more thing. I finally came up with the name of the main character! I'll tell you later with some other cool stuff.

[eliasdaler]

I've moved animation descriptions to JSON.
This removed 1047 lines from Lua scripts which is cool, as scripts are now more compact and easier to edit.

I also made a dialogue tool. It took me just half an hour to make!

Yes, line breaks can be easily inserted automatically. But this tool lets me compose the text in such way, that there's no situations like this:

Code:

Some text, some text, some text 
some_very_long_word_which_doesn't_fit_in_previous_line, even more text,
a giant space is left on the first line. Meh, not cool!

This also lets me see how much text I can still fit in this box. I don't want to break one long sentence into several boxes, because this may be not very readable.

[eliasdaler]

Here's something another... I've decided to write music for the cafe. Hope you enjoy.
https://soundcloud.com/elias-daler/cafe-demo

[bombjack]

First time I get around this devlog. The game idea seems original.
Is there any demo yet ?
The music you just posted is very nice. I wish I could do music...

[eliasdaler]

First time I get around this devlog. The game idea seems original.
Is there any demo yet ?
The music you just posted is very nice. I wish I could do music...

Thanks! No, there isn't any demo yet. I'm working on it.
You see, I should make the demo as good as possible to make a good first impression, that's why it would take a while.

[eliasdaler]

Okay, here's the biggest change in the art in a long time. I've changed pespective to axonometric 3/4.

Just compare it with the old one:

GIF:


Drawing in this perspective is a lot easier, because all lines are straight. It's also a lot less confusing and more readable!

[eliasdaler]

Progress update
Can't really show much at the moment. Working on the cool fog system which I hope to show off soon. It's not just overlay sprites, clouds can actually be of any height and interact with objects they collide with!
I'm also prototyping some stuff. I've understood that this is absolutely neccessary.
This is something which I need to be used to. Drawing raw, unpolished sprites, making levels without lots of details, etc.
If I make a level with some detail (even not a lot of it), changing stuff becomes harder. So, raw prototyping helps here. Just draw some boxes, throw them on the map and change them to get a good level. And then I can start with details. But it's actually pretty hard, because I want the game to look good all the time, but I have to overcome this thing. Does anyone feel that about their games? :D

[eliasdaler]

Okay, here's how the fog looks in the game


Notice, that it's not just an overlay. It actually has some height and draws depending which objects are in it. Just a neat simple effect...

This wasn't easy to make, though. Here's how it works:

Suppose we have one object. First, we draw the part of the fog which is behind it. Then we draw the object itself. After that, we draw the rest of the fog sprite in front of the object.
It all depends on the line which divedes the front and the back.It's easy to get it by substracting fog height (in pixels) from lowest Y coordinate of the object.
So, I split one big sprite in smaller ones depending on objects around.

Stuff becomes a lot harder if there are several objects in fog. I won't explain how to deal with it, as it would take too much time, but stuff works mostly the same.
And by the way, the most interesting thing about it is that the fog sprites don't move. Only textures move on sprites. This is done to make tiling of fog easier. I don't have to create additional sprites to do this, sprites just follow the camera if it moves.

There are other stuff I can do with this system. Like simulating water (some stupid undead forgot to turn off the taps...)


Or deep snow...

You get the idea. It's always cool to reuse stuff like that!

[eliasdaler]

Fixed one big bug where hero's sprite was shaking during camera scrolling. Turns out, I was setting the updated camera view too late (somewhere in the rendering phase, he-he). This took me like 3-4 hours to find! I'm not a clever man, heh.

As for 256x240 resolution. I've chosen this resolution because of SNES (but actually SNES is 256x224!).
So, I'm thinking about changing resolution to either 256x244 or 320x240 (4:3!).
320x240 would actually be cool because it would give me more horizontal space.

16:9 ratio for resolution would be cool, but I think that this would make my game look weird and too much horizontal space is not needed anyway (it's better for platformers).

[Jabberwocky]

I first saw re:creation over on the SFML forum.  I'm happy to see it's made it's way over here as well.  

I agree the new artwork style looks more clean.  And I've learned a new word today, "axonometric".  

The fog/snow/water is looking pretty cool, too.

[eliasdaler]

I first saw re:creation over on the SFML forum.  I'm happy to see it's made it's way over here as well.  

I agree the new artwork style looks more clean.  And I've learned a new word today, "axonometric".  

The fog/snow/water is looking pretty cool, too.

Hi there! Thanks. :D

[eliasdaler]

Here's a summary of what I've made during the last five months.
https://eliasdaler.wordpress.com/2015/10/15/recreation-dev-log-june-october-2015-theres-a-lot-of-stuff-made/
It's so good to look back and see how much of the stuff changed and improved.

[eliasdaler]

Progress update
So, I've been refactoring and improving the code this week. This actually feels very good, because I'm fixing a lot of bugs and improving the readability and structure a lot. I'll tell more about stuff I've been doing a bit later.

So, I have a question about one aspect of the code.

For a lot of time I could get components from entities with this function:

Code: (c)

template <typename T>
T* Entity::get() {
    ...
    if(...) { // component found
        return componentPtr;
    }
   return nullptr; // component not found
}

And I could check if the component exists like this:

Code: (cpp)

auto gc = entity->get<GraphicsComponent>();
if(gc) { // do stuff
     ...;
}

This is needed for two reasons:

1) Systems check if entities have components which they are interested in

2) C++ functions which can be called from Lua check this to send error messages if you call something like setAnimation(e, "anim") for entity which has no GraphicsComponent.

But what if I return the references instead?

Code: (cpp)

template <typename T>
T& Entity::get() {
    ...
    if(...) { // component found
        return component;
    }

   ??? // component not found
}

The question is: what do I do in the situations where entities don't have the component? I think I can do it like this:

Code: (cpp)

template <typename T>
T& Entity::get() {
    assert(...); // check if component is found
    ...
    return component;
}

And I'll have to check if entity has a particular component if I'm not sure if the components exist

Code: (cpp)

if(e->hasComponent<GraphicsComponent>() {
    auto& gc = e->get<GraphicsComponent>();
} else {
    ... // do something else
}

So, I think this is better than getting nullptr errors where I don't check if component exists and it doesn't.

Code: (cpp)

GraphicsComponent* gc = e->get<GraphicsComponent>(); // nullptr
gc->doSomething(); // crash!

vs

Code: (cpp)

GraphicsComponent& gc = e->get<GraphicsComponent>(); // assert!
gc.doSomething() // component totally exists, because if assert aborted the program, we won't be there

Is this a good way to do things? Is there a better way to do it? Maybe returning the pointer to component is fine?

[eliasdaler]

Progress update
I'm almost finished with refactoring. The structure of the engine is much better. I've also done some stuff like fixed-time step, better collision testing (spatial partitioning with grids) and some other stuff. I plan to write a blog post about the stuff I've done this Saturday or Sunday.

I also plan to finish demo prototype by the end of November. There will be some finished stuff and there'll be some placeholder art/NPCs/dialogue, etc.
The best case scenario is me finishing the demo by the end of this year, testing/polishing it for a month and then releasing somewhere by the end of January or somewhere near my birthday, ha-ha (which is on the 2nd of February).

And by the way, Re:creation is now 2 years old. Please, don't use this as a way to tell how much I have to work to finish the game. Now that I have a set of good tools and better experience with art, I'll be able to work much faster. Most of the work I've done during those two years was about creating the engine from almost a scratch. And I'm glad that I did, because now I know lots of stuff about game dev and have an awesome system which I'm quite proud of.
I'm almost done with the engine, there are some minor things I've yet to add, but they'll be implemented quite fast. Most of the game I have in mind can be implemented with the tools I already have. This makes me very happy.
So, the new era of Re:creation development will begin soon. Thank you for supporting me so far, I hope you'll get some cool stuff from my future work. :D