The very beginning

[Arachnis]

Hello everybody,

I have some questions regarding prototyping:

I want to know, how to create a combat system for a top-down game from scratch.
The programming part is not so much the problem. The real problem is deciding which sprites to use for testing the system. My game's combat system is supposed to be kind of similar to diablo.

Now, the game itself will have very little similarities to diablo, except for how the combat system is supposed to work. My problem is deciding for the right sprite-placeholders to test the system.

Should I use 128x128 simple circle-shaped sprites?
Can I use smaller sprites?
What shape should they really have? Are rectangular sprites more befitting to the game?
How do I decide whether to use isometric perspective or not?
Are there tutorials for that kind of combat system?

I need to test the combat system first in order to see if it is fun or not. Now, my plan is to make the minimum viable product (I think that's what it's called) and once I'm satisfied go to an artist and say "make me some sprites please". What I don't want is creating a system and then realizing I have to change everything again, because otherwise the artist won't do the job. He could for example say something like "the sprites are too small" or have the wrong shape and that would screw up my whole work in the end, because I would have to recalibrate the whole system based on the new sprites.

How do other people go on about creating a prototype like this?

Greetings

 

[Yal]

I personally make more or less everything based around 16x16 sprites (or possibly a 16x16 grid with bigger sprites taking up several cells, for instance characters being up to 32 px tall), and then I decide on other things based on how many of those sprites need to be shown at once to make the gameplay (and GUI elements) readable. There's too many variables you can change freely to make a 'best' solution for all of them, so you should try to lock some down to arbitrary values early on and THEN make decisions based around what would make sense given those limitations.

 

[EncomLab]

I personally make more or less everything based around 16x16 sprites (or possibly a 16x16 grid with bigger sprites taking up several cells, for instance characters being up to 32 px tall), and then I decide on other things based on how many of those sprites need to be shown at once to make the gameplay (and GUI elements) readable. There's too many variables you can change freely to make a 'best' solution for all of them, so you should try to lock some down to arbitrary values early on and THEN make decisions based around what would make sense given those limitations.

THIS - plus the end scaling is not going to be based on what some artist wants - it is directly related to the platform you intend to publish to. For example when publishing to mobile or tablets I always use a 9/16 ratio for vertical and 16/9 for horizontal views and that is the initial scalar value that drives the final sprite sizes. Those ratios will also work for a widescreen monitor view but for a regular monitor or tv display they will probably give you odd distortions when scaled to fit. When i start initial testing I just use some variation of base 10 to keep the math simple and then once things are working and it's time to finalize sprites I adjust to the scalar required. No "real" artist is going to object or refuse to make an asset based on scalar values lol.

 

[Yal]

Yeah, 16/9 ratio is probably a pretty good start nowadays... and to keep it even simpler, it's almost the same as a 16/8 ratio, aka a 2/1 ratio - make the view twice as wide as tall and you've got a pretty good approximation of what you're going for.

 

[c3pu]

Do not use circles because game maker collision are square based by default, because they are the easiest to work with, so use squares and rectangles.

For the size of your sprite think what kind of graphics you want.

NES: 8x8 or 8x16 (probably not for you)

SNES: up to 64x64

PS1: up to 256x256

For 16bit and 32bit graphics first decide the internal resolution of your game, the view in room.
Then ask yourself how big should my character be in that view? That will give you the resolution of your character then reduce the height until its square, that gives you your tile size.

In general characters are 1x2 1x3 compared to your base tile to keep things nicely lined up.

As for tutorial heartbeast as an entire series about making a top down rpg it doesn't have clicking combat but i highly suggest checking it out. https://www.youtube.com/playlist?list=PL9FzW-m48fn2ug_FSNnfozQs3qYlBNyTd

 

[RujiK]

Do not use circles because game maker collision are square based by default, because they are the easiest to work with, so use squares and rectangles.

This is somewhat misleading. Sure the "default" mask shape is a rectangle, but that's like saying the "default" sprite is empty, so don't use sprites, since the default sprite is a 32x32 transparent nothingness.

All these functions are for non-squares collisions (Although some can be used with squares too):
point_in_circle
point_in_triangle
collision_circle
collision_ellipse
collision_line
collision_point

As for your collision system, there isn't a right or wrong collision mask, but it's about what feels better. Why not try both and see which one you like better?


And just because I'm super special, I personally use a rectangle-based collision for NPC-2-world collisions and a circle-based collision for unit-2-unit collisions. (I don't recommend this unless, like me, you realize this would work well)


And just for the heck of it, A comparison of a circle vs square collision no built-in collision functions:

//CIRCLE
var dx = npc1.x - npc2.x;
var dy = npc1.y - npc2.y;
if (power(dx,2) + power(dy,2)) < power(distance,2) {WE HAVE A COLLISION!}

//RECTANGLE
if (npc1.x < npc2.x + npc2.width && npc1.x + npc1.width > npcx &&
    npc1.y < npc2.y + npc2.height && npc1.height + npc.y > npc.y) {collision detected!}

In some cases, circles can actually be faster due to less conditions, but the minuscule performance boost shouldn't affect your decision. Good luck!

 

[c3pu]

This is somewhat misleading. Sure the "default" mask shape is a rectangle, but that's like saying the "default" sprite is empty, so don't use sprites, since the default sprite is a 32x32 transparent nothingness.

All these functions are for non-squares collisions (Although some can be used with squares too):
point_in_circle
point_in_triangle
collision_circle
collision_ellipse
collision_line
collision_point

As for your collision system, there isn't a right or wrong collision mask, but it's about what feels better. Why not try both and see which one you like better?


And just because I'm super special, I personally use a rectangle-based collision for NPC-2-world collisions and a circle-based collision for unit-2-unit collisions. (I don't recommend this unless, like me, you realize this would work well)


And just for the heck of it, A comparison of a circle vs square collision no built-in collision functions:

//CIRCLE
var dx = npc1.x - npc2.x;
var dy = npc1.y - npc2.y;
if (power(dx,2) + power(dy,2)) < power(distance,2) {WE HAVE A COLLISION!}

//RECTANGLE
if (npc1.x < npc2.x + npc2.width && npc1.x + npc1.width > npcx &&
    npc1.y < npc2.y + npc2.height && npc1.height + npc.y > npc.y) {collision detected!}

In some cases, circles can actually be faster due to less conditions, but the minuscule performance boost shouldn't affect your decision. Good luck!

I always found circular collision to be glitchy and tricky. I only ever use them when absolutely necessary. but that might just be the way my game is built.

 

[gamedev4life]

for a top down game, think of sprite size as graphical level: 8x8 sprites is like original nintendo (8 bit); 16x16 sprites is like super nintendo (16 bit); 32x32 sprites is like playstation 1 (32 bit); etc. so it depends on what kind of "look" do you want your game to have

in my game (see sig) the main character is 32x64, albeit for a platformer not top down but u get the idea