RPG game engine reflexions

Page 2/4
1 | | 3 | 4

By DarkSchneider

Paladin (748)

DarkSchneider's picture

15-05-2018, 08:19

Metalion wrote:

Collision / behaviour is one of the disadvantages of 16x16 tiles.
You loose some precision in the screen interaction, versus an 8x8 tile.

Well that depends more on your characters size, proportional scale. For small characters (like YS) maybe 8x8 is better, for large characters 16x16.
Also creating maps with 8x8 is much more work.

By Metalion

Paladin (968)

Metalion's picture

15-05-2018, 10:22

DarkSchneider wrote:

Well that depends more on your characters size, proportional scale. For small characters (like YS) maybe 8x8 is better, for large characters 16x16. Also creating maps with 8x8 is much more work.

My character would be 16x32.

Indeed, the separate collision/behaviour map seems interesting but I understand the remark about the fact that very few tile editors allow to add this property, and that it would be difficult to convert to the data structure chosen in the game. Therefore, building the map would be more difficult.

I think I'll choose this structure :
. Individual 16x16 tiles
. Tileset of 1024 tiles
. Properties coded on the 6 remaining bits

By santiontanon

Hero (593)

santiontanon's picture

15-05-2018, 22:41

I agree with Grauw's comment about simplicity. In my experience, every time I try to over-engineer a solution it never ends up being finished. The way that works for me is to start with something as simple as possible, and then extend if necessary. But trying to come up with a perfect system from the start has never worked for me (I end up spending all the time authoring an engine that never gets finished...)

By Metalion

Paladin (968)

Metalion's picture

16-05-2018, 08:31

santiontanon wrote:

I agree with Grauw's comment about simplicity. In my experience, every time I try to over-engineer a solution it never ends up being finished. The way that works for me is to start with something as simple as possible, and then extend if necessary. But trying to come up with a perfect system from the start has never worked for me (I end up spending all the time authoring an engine that never gets finished...)

I have exactly the same problem. I spend too much time finding the best solution and then never finish what I started. So I guess that remark is quite crucial because it is more important than all other reflexions about the game engine ! What matters most is to finish the job ....

By wolf_

Ambassador_ (9691)

wolf_'s picture

16-05-2018, 10:03

My problem usually starts with the dedicated editors I have to make. So, I end up making editors instead. ^_^

By DarkSchneider

Paladin (748)

DarkSchneider's picture

16-05-2018, 11:21

I do the opposite. Always try to find the most global solution, fine for any usage it could get, and then simplify from there. Usually joinning, delegating and anonymizing is enough.

For specific game I think is better the direction simple -> complex, but for an engine is better the other one complex -> simple. You don't know the usage on each case, and making a change in an engine could carry to deep (and many) changes in other parts.

By Grauw

Enlighted (7405)

Grauw's picture

16-05-2018, 18:07

wolf_ wrote:

My problem usually starts with the dedicated editors I have to make. So, I end up making editors instead. ^_^

That’s why I don’t want to make editors anymore. For my first real game project back in the day, "Strategic Army" if anyone remembers, I made a great tile map and tile set editor (on MSX), complete with zoomed-in pixel editor and all. The game itself was never finished, of course.

Now I always try to shoehorn whatever I want to do into some existing tool, and then just write conversion scripts to get the data in the format I need. E.g. tile maps I make in Tiled, graphics in Aseprite, and for music I’m thinking to either use a PC DAW or a spreadsheet Wink.

DarkSchneider wrote:

For specific game I think is better the direction simple -> complex, but for an engine is better the other one complex -> simple. You don't know the usage on each case, and making a change in an engine could carry to deep (and many) changes in other parts.

But then the question becomes, why are you making an engine? Smile Developing a generic engine means that features are added based on the programmer’s imagination rather than a practical use case, and it often ends up doing too much with too much abstraction. I see this in many frameworks. To avoid wasting my time on things that are not actually going to be used, and to keep the code simple and driven by need, frameworks are also something I’m not doing anymore.

Rather, I grow the code base organically as the game demands it, and then on the fly I extract reusable parts into a separate library. That’s how the "neonlib" that I’m using in my projects came into existence, essentially to consolidate the code copy/pasted between projects. The game I’m developing now has a nice core, but it’s still evolving based on the things I need. Once this is done and I start the next project, then I can extract the useful bits so that I have a good basis to start from and can go straight to implementing gameplay rather than scrolling or screensplits.

Not to say making an engine isn't fun or valuable, just, KISS and resist the temptation of abstraction and trying to fulfill every possible use case you can dream of. A restrictive engine which is quick to make and easy to use can be much more valuable than one which tries to take care of everything.

A concrete example, you know that putting spites on line 217 is a problem. You could make a sprite system which avoids this problem automatically, but the sprites code gets much more complex. Or you could say, this engine doesn't scroll vertically, or, it only scrolls in 2 pixel increments, or, the responsibility to work around it lies with the user. I chose the 2nd and 3rd option. But, people said, maybe sometimes you want to scroll by 1 pixel. That's what I mean, don't try to solve that, just say "Nope, sorry. Either just don't do that, or work around it yourself."

By wolf_

Ambassador_ (9691)

wolf_'s picture

16-05-2018, 19:29

It's mostly feature-creep that's problematic. Also, as you read before: just to decide whether you want tiles with location-based functionality, or a second layer with flags, that's worth thinking about. Maybe you want your editor to do both. And what about multilayers like in Fray? And do you open rooftops if you enter a building, or do you go to a new interior map? Are animating doors a feature of the game engine, or custom animations within a generic animation section of the engine? If you choose the latter, then you'll think of building an animation engine first. Will it have a few buttons, or would it be based on a script? If the latter: what would the script look like? Does a textbox engine need special codes to show images and trigger events, are you going to add speed commands for improved reading comfort? Do you need a font in multiple colours? Is it a proportional font and does it automatically wordwrap or should the wrap be a command hardcoded in the text?

I could go on like this. Point is, at least that's how I see it: you can look top-down on an RPG-engine, and each new day you'll see new processes to streamline, and you'll see that even small bits can totally mess-up all of the engine that has already been done. For that reason alone I have massive amounts of respect for games like DS TLoH, SD Snatcher, Fray and the likes. Making a shooter or platformer is so much easier. Smile

By santiontanon

Hero (593)

santiontanon's picture

16-05-2018, 21:27

Ah, editors... hahaha, I hear you there!!! back 15 years ago when I though I was working on "Maze of Galious 2" after the MoG remake, I spent more than a year working on an editor that was just getting more and more complicated, and the game was never done... Sad

Not making that mistake again Smile

By Manuel

Ascended (14659)

Manuel's picture

16-05-2018, 21:59

Wouldn't it be possible to make Maze of Galious 2 just with the existing Konami game engine?
I guess it is generic enough to just:
- replace graphics
- replace maps
And with that you can already make a whole brand new game, seemingly, I think. But it depends on reusable that engine really is.

What was your plan with MoG 2 anyway?

Page 2/4
1 | | 3 | 4
My MSX profile