Enter the Unknown - Devlog

[ghzmdr]

Hi guys from the community!

I decided to start a Devlog on my blog for the game I'm currently working on.

I't name is Enter the Unknown, you can find out why in the blog entry linked at the end of this post.

The game will be a fast paced roguelike/action RPG, with both a story mode and an endless mode. The latter will feature randomly generated levels and permadeath.

The engine will be dynamic and data-driven, restrictions posed will only be structural and really basic. Oh and there will be the prettiest pixel art graphics I can do!

Find out more on my blog, here's the link to the week 1 post ^{_{(Last updated 21/03/15, 20:20 GMT+1)}}

If you're a newbie (like I am..) chances are you'll find useful informations, otherwise you'll inevitably see some errors.

In both cases give it a shot and tell me what you think!

[Nexus]

Please post in the project section. This subforum is about general SFML discussions.

And it would be nice if you could describe a bit more of your game in the post, it's insanely vague

[ghzmdr]

Hi Nexus! Thanks for checking it out, already moved to the correct section.

Well, that will come later on, the story isn't already well defined and so are the features, for now I worked on the basics of the engine and the game idea is outlined only in my brain and some paper sheets, so that was everything I had to say.

I want to have gameplay features at least partially implemented before discussing them, also that post I'm talking about in the intro contains this kind of info and will be published once development reaches a more mature stage.

[Nexus]

I meant the forum post, not the one on your website

It will probably attract more people if you already present something interesting here, even more if you illustrate your project with some screenshots or sketches. I completely agree that it's good to wait until some features are implemented before discussing them in-depth.

[Life&Dev Games Australia]

Sounds really cool man! How long do you expect this project to take?

[StormWingDelta]

Sounds really cool man! How long do you expect this project to take?

When it comes to us programmers it can vary from years to hours.  The word "SOON" comes to mind.


Meanwhile: ghzmdr you might want to post more screenshots of what you are working on so we can see it a bit more.   Might help.

[ghzmdr]

Sounds really cool man! How long do you expect this project to take?

When it comes to us programmers it can vary from years to hours.  The word "SOON" comes to mind.

Thanks! Indeed I have no ETAs, but I expect this to take around a year, level design included, given that is a solo project.

Surely I'll go as fast as I can physically bear, since this is my main goal for now. But I also have a lot to learn in this field, which at least at the beginning will be a bottleneck since I can code 12/7 but if then I have to spend double that time refractoring because I missed some patterns that's a great loss. So for now I spend a great part of that time studying. I really wish I could be like Neo and just plug knowledge in my brain then code as fast as I can, but that's sci-fi 

Oh and I'll post a screen once is worth to, for now you would just see debugging bounds and crappy tilesheets

[Life&Dev Games Australia]

True, solo projects do take a while but don't hesitate too much. The best way to learn in my opinion is to program your brains out and make mistakes! Doesn't matter how good you are, at least with game programming, you probably will have to redo a lot of things and waste a lot of time, but your efforts will eventually all pay off. Anyway, I wish you all the best!

Rob Moll (Life&Dev Games)

[ghzmdr]

Thank you for the kind words. Indeed I'm facing some of issues with design but you're right, without actually implementhing things you can't do mistakes, thus learn. The codebase is 1817 lines now, but surely I wrote at least 2 times that much, and things get better each time.

One thing I learned from this project (wish I knew that before): if you look at a problem and start thinking that's too complicated and will take a lot of effort and you might not be able to solve it, you'll end up being afraid of actually doing it, so you'll not give your best and end up doing more work than necessary (my brain wrongly asserts: more difficult = more code = more effort). Instead you should start tackling it one step at a time and keep it simple, without being afraid of not doing it good, and sometimes the outcome will be even better than you expected. At least this works for me...

This and also that concretely defining your data models before actually implementing related code makes writing it a lot easier

[ghzmdr]

Week 2 update here

[SpeCter]

You defined a getComponent Method which returns void(at least in your blogpost) it should return a Component(*).
Is there any reason for not letting the component know its parent entity? Is it possible for a component to change parents?
What exactly is ComponentID? Is it the same for each ComponentType?
If not why not define it as a const member?

Oh and maybe you shouldn't immediately react to collisions.As of now, if for example 2 balls collide only the first one to update will even react properly to the collision(because the collision will most probably be resolved by the time the second one will be updated).

What will happen:
1. o--><--o
2. o-><-o
3. oXo        (X = Collision!)
3.1 <-o Xo (First ball decides to bounce of)
3.2 <-o <-o   (Collision resolved, second ball follows its original path)   

[ghzmdr]

You defined a getComponent Method which returns void(at least in your blogpost) it should return a Component(*).

Yes that's a typo

Is there any reason for not letting the component know its parent entity? Is it possible for a component to change parents?

The parent entity is passed as reference in the update()

What exactly is ComponentID? Is it the same for each ComponentType?
If not why not define it as a const member?

I still have to tinker with it..
Basically I'm thinking about a way for letting a component know about another's internal state.
So for example, animation could know about texture size or the like, this is done by using the parent's getComponent(string id) and access the required fields. There should be a better way of doing this tho 

Oh and maybe you shouldn't immediately react to collisions.As of now, if for example 2 balls collide only the first one to update will even react properly to the collision(because the collision will most probably be resolved by the time the second one will be updated).

What will happen:
1. o--><--o
2. o-><-o
3. oXo        (X = Collision!)
3.1 <-o Xo (First ball decides to bounce of)
3.2 <-o <-o   (Collision resolved, second ball follows its original path)

Thank you very much for this one! Solves a nasty issue with collisions 

Could someone reccomend some resources on Component System design?

I'm not updating the blog in these days because some things are keeping me away from the project, instead of updating weekly I'll update once there are some concrete changes.

[Grimshaw]

What's the difference between a GameObject and an Entity?

[SpeCter]

Could someone reccomend some resources on Component System design?

There are many ressources I could mention now

I pretty much liked:

http://www.optank.org/2013/01/19/game-development-design-the-component-system-part-2/
(And Part1)

The Artemis Entity Component Framework(Java based though)
More like a working reference implementation to look at, easy to read, easy to use and fast.
(Unfortunately the website seems to be down(expired) but you can still look at the code on googlecode)

There should be other implementations in C++/C# etc. around which copied its design.

http://www.randygaul.net/2013/05/20/component-based-engine-design/
Great Intro with many links to other references at the end.

There are many good ones which I probably would mention here(most of them are referenced to in the mentioned articles though)