Vapourware Medieval Isometric RPG focusing on swordplay

[Meatbag]

Learning how to code good enough to use Unity or Godot takes time but you are capable of it. Your "very very low level of competency" will become "very low" in a few weeks, then "low" in a few months, etc. Once you are comfortable with a few key concepts (e.g. object-oriented programming), you will be able to do a lot.
I think it is much more reliable to do it yourself rather than hopefully finding the right person. With someone else, you trade the trouble of coding with the trouble of being dependent on another person.

Your art looks really good.

That's true. I think I just really struggle with the delayed gratification that comes with taking on something like coding. With are I can immediately see every improvement on the screen but with coding, I never manage to get anything off the ground and I get very frustrated with myself.

Do you know of any good resources that explain the bare fundamentals for coding in a way so simple that even a humble retard (such as myself) could gasp them?
when I try to read engine manuals, the huge wiki pages full of text just fry my little brain

Unfortunately I don't have any resource to recommend beyond the Unity or Godot manuals and tutorials, but these contain the bare essential that you need to grasp. Beyond these, you will need to look how to organize your code so that it does not become "spaghetti", that is why I was talking about object-oriented programming in my previous post. For example, the damage value of a weapon should be a variable that is linked to the weapon as an object, not something linked to a character. The more complex your game is and the more you need to organize your code this way. For example, that means you would have a class "weapon" that has all the code and information related to them. This really is the most advanced stuff that you need. If I remember correctly, the Godot tutorial teaches this a bit, with scripts attached to different objects, communication between them without total dependence between them, and variables held by the proper script.

This "spaghetti" is also why no code engines never took off - they are horrible at scaling. I can't imagine using one to create anything beyond a prototype. GDevelop looks pretty good but I would not use it for anything more than concept stuff.

What I really hate about Godot (besides its wokeishness and cultishness) is the whole node based way of doing things. I never ever get very far with it.

Whilst Unity on the other hand is malware/bloatware, the paradigm of the component based system is much better. But that too has its problems particularly when you are trying to extend the Engine it just doesn't fit every need that well.

In regards to resources. If anything there are too many tutorials and information on programming that it can be overwhelming to begin with.

ChatGPT actually might not bad if all you need to do is learn with small snippets. But if you try to push it too far it blows up in your face pretty quickly.

The other point I'd make is that creating isometric games are not for the faint hearted developer, depending on what features you want in there. It can be fiendishly difficult to work with.

Also things like creating a turn based system, and so on, are also quite involved.

Thanks! Yeah, I've had mixed results using AI. It was able to get me through some simple stuff but fell over when I started asking about concepts that had been recently updated in Godot. One thing it was good at was quickly annotating code blocks so I could understand what they were for.

What is it about Isometric games that make them so difficult? (might be a moot point as currently, everything code related is difficult for me) I know state machines for turn based combat can be very tricky but other than that, I don't think I have anything overly complex planned.

Speaking in very broad terms, I plan to have

• Big tile maps with doors to smaller tile maps for building interiors and dungeons
• Tile-based turn by turn combat with attacks that can have AOEs over multiple tiles and reposition characters
• A layered gear system where each piece of equipment has its own 2d animations that get layered over each character (okay I can see this one getting pretty complicated)
• Staple RPG stats, attributes and abilities for levelling up
• A town full of stationary NPCs with dialogue
• No vertically (levels of elevation)
• No cutscenes

 

[The_Sloth_Sleeps]

Learning how to code good enough to use Unity or Godot takes time but you are capable of it. Your "very very low level of competency" will become "very low" in a few weeks, then "low" in a few months, etc. Once you are comfortable with a few key concepts (e.g. object-oriented programming), you will be able to do a lot.
I think it is much more reliable to do it yourself rather than hopefully finding the right person. With someone else, you trade the trouble of coding with the trouble of being dependent on another person.

Your art looks really good.

That's true. I think I just really struggle with the delayed gratification that comes with taking on something like coding. With are I can immediately see every improvement on the screen but with coding, I never manage to get anything off the ground and I get very frustrated with myself.

Do you know of any good resources that explain the bare fundamentals for coding in a way so simple that even a humble retard (such as myself) could gasp them?
when I try to read engine manuals, the huge wiki pages full of text just fry my little brain

Unfortunately I don't have any resource to recommend beyond the Unity or Godot manuals and tutorials, but these contain the bare essential that you need to grasp. Beyond these, you will need to look how to organize your code so that it does not become "spaghetti", that is why I was talking about object-oriented programming in my previous post. For example, the damage value of a weapon should be a variable that is linked to the weapon as an object, not something linked to a character. The more complex your game is and the more you need to organize your code this way. For example, that means you would have a class "weapon" that has all the code and information related to them. This really is the most advanced stuff that you need. If I remember correctly, the Godot tutorial teaches this a bit, with scripts attached to different objects, communication between them without total dependence between them, and variables held by the proper script.

This "spaghetti" is also why no code engines never took off - they are horrible at scaling. I can't imagine using one to create anything beyond a prototype. GDevelop looks pretty good but I would not use it for anything more than concept stuff.

What I really hate about Godot (besides its wokeishness and cultishness) is the whole node based way of doing things. I never ever get very far with it.

Whilst Unity on the other hand is malware/bloatware, the paradigm of the component based system is much better. But that too has its problems particularly when you are trying to extend the Engine it just doesn't fit every need that well.

In regards to resources. If anything there are too many tutorials and information on programming that it can be overwhelming to begin with.

ChatGPT actually might not bad if all you need to do is learn with small snippets. But if you try to push it too far it blows up in your face pretty quickly.

The other point I'd make is that creating isometric games are not for the faint hearted developer, depending on what features you want in there. It can be fiendishly difficult to work with.

Also things like creating a turn based system, and so on, are also quite involved.

Thanks! Yeah, I've had mixed results using AI. It was able to get me through some simple stuff but fell over when I started asking about concepts that had been recently updated in Godot. One thing it was good at was quickly annotating code blocks so I could understand what they were for.

What is it about Isometric games that make them so difficult? (might be a moot point as currently, everything code related is difficult for me) I know state machines for turn based combat can be very tricky but other than that, I don't think I have anything overly complex planned.

Speaking in very broad terms, I plan to have

• Big tile maps with doors to smaller tile maps for building interiors and dungeons
• Tile-based turn by turn combat with attacks that can have AOEs over multiple tiles and reposition characters
• A layered gear system where each piece of equipment has its own 2d animations that get layered over each character (okay I can see this one getting pretty complicated)
• Staple RPG stats, attributes and abilities for levelling up
• A town full of stationary NPCs with dialogue
• No vertically (levels of elevation)
• No cutscenes

No elevation makes it easier. But you will need to think about how to cut up and place tiles.
Large tiles can be a problem. There are a bunch of sorting issues with isometric but you can design your game around the problems.

I don't think anything else is a problem as such but just a lot of work.
-Inventories
-Classes
-Combat design, lots of balancing needed
-Dialogue needs dialogue trees, where you can unlock part of the trees, and attach scripts.
-etc...

Basically every feature you add is a load of extra work, and can even impact other features. So you need to get your design such that its a fun game but not too many features and too much work. It should do a couple things, and do those well.

 

[Meatbag]

Learning how to code good enough to use Unity or Godot takes time but you are capable of it. Your "very very low level of competency" will become "very low" in a few weeks, then "low" in a few months, etc. Once you are comfortable with a few key concepts (e.g. object-oriented programming), you will be able to do a lot.
I think it is much more reliable to do it yourself rather than hopefully finding the right person. With someone else, you trade the trouble of coding with the trouble of being dependent on another person.

Your art looks really good.

That's true. I think I just really struggle with the delayed gratification that comes with taking on something like coding. With are I can immediately see every improvement on the screen but with coding, I never manage to get anything off the ground and I get very frustrated with myself.

Do you know of any good resources that explain the bare fundamentals for coding in a way so simple that even a humble retard (such as myself) could gasp them?
when I try to read engine manuals, the huge wiki pages full of text just fry my little brain

Unfortunately I don't have any resource to recommend beyond the Unity or Godot manuals and tutorials, but these contain the bare essential that you need to grasp. Beyond these, you will need to look how to organize your code so that it does not become "spaghetti", that is why I was talking about object-oriented programming in my previous post. For example, the damage value of a weapon should be a variable that is linked to the weapon as an object, not something linked to a character. The more complex your game is and the more you need to organize your code this way. For example, that means you would have a class "weapon" that has all the code and information related to them. This really is the most advanced stuff that you need. If I remember correctly, the Godot tutorial teaches this a bit, with scripts attached to different objects, communication between them without total dependence between them, and variables held by the proper script.

This "spaghetti" is also why no code engines never took off - they are horrible at scaling. I can't imagine using one to create anything beyond a prototype. GDevelop looks pretty good but I would not use it for anything more than concept stuff.

What I really hate about Godot (besides its wokeishness and cultishness) is the whole node based way of doing things. I never ever get very far with it.

Whilst Unity on the other hand is malware/bloatware, the paradigm of the component based system is much better. But that too has its problems particularly when you are trying to extend the Engine it just doesn't fit every need that well.

In regards to resources. If anything there are too many tutorials and information on programming that it can be overwhelming to begin with.

ChatGPT actually might not bad if all you need to do is learn with small snippets. But if you try to push it too far it blows up in your face pretty quickly.

The other point I'd make is that creating isometric games are not for the faint hearted developer, depending on what features you want in there. It can be fiendishly difficult to work with.

Also things like creating a turn based system, and so on, are also quite involved.

Thanks! Yeah, I've had mixed results using AI. It was able to get me through some simple stuff but fell over when I started asking about concepts that had been recently updated in Godot. One thing it was good at was quickly annotating code blocks so I could understand what they were for.

What is it about Isometric games that make them so difficult? (might be a moot point as currently, everything code related is difficult for me) I know state machines for turn based combat can be very tricky but other than that, I don't think I have anything overly complex planned.

Speaking in very broad terms, I plan to have

• Big tile maps with doors to smaller tile maps for building interiors and dungeons
• Tile-based turn by turn combat with attacks that can have AOEs over multiple tiles and reposition characters
• A layered gear system where each piece of equipment has its own 2d animations that get layered over each character (okay I can see this one getting pretty complicated)
• Staple RPG stats, attributes and abilities for levelling up
• A town full of stationary NPCs with dialogue
• No vertically (levels of elevation)
• No cutscenes

No elevation makes it easier. But you will need to think about how to cut up and place tiles.
Large tiles can be a problem. There are a bunch of sorting issues with isometric but you can design your game around the problems.

I don't think anything else is a problem as such but just a lot of work.
-Inventories
-Classes
-Combat design, lots of balancing needed
-Dialogue needs dialogue trees, where you can unlock part of the trees, and attach scripts.
-etc...

Basically every feature you add is a load of extra work, and can even impact other features. So you need to get your design such that its a fun game but not too many features and too much work. It should do a couple things, and do those well.

Ah, I see. I will keep this in mind when refining my GDD. I'm hoping to keep functionality as basic as possible while adding a lot of content (gear, abilities, enemies, environments) for depth.

I'm okay with lots of work, it's just a struggle when I fail to get even the most basic elements to function correctly, don't understand why, and make zero progress. Guess I need more time on the slope!

Thanks so much for your help, I really appreciate it.

 

[man_at_arms]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with characters who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

 

[Galdred]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with character who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

Right, but if he is the artist, main artist hourly wage is not a huge issue, as the programmer load will typically be even higher, so sprites are still doable in this case.
You can have less facings to do if :
- you don't take direction into account (that's what Battle Brothers did). => only one "direction"

You can also do the following
- don't allow diagonals apart for walking when none of the adjacent cardinal direction is obstructed (because diagonals add a lot of issues in squre grids)
- mirror the sprites.
But you still have 2 directions to make (as we did in Zodiac Legion): NW (mirrored to NE) and SW (mirrored to SE).

As for leveraging assets, we went with a very complicated paperdolling system:


That allows us to mix and match armors and weapons.

As for finding a programming partner, it is a bit like fiding your wife. It is very difficult to find the right person, and picking badly might be catastrophic.

 

[The_Sloth_Sleeps]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with character who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

Right, but if he is the artist, main artist hourly wage is not a huge issue, as the programmer load will typically be even higher, so sprites are still doable in this case.
You can have less facings to do if :
- you don't take direction into account (that's what Battle Brothers did). => only one "direction"

You can also do the following
- don't allow diagonals apart for walking when none of the adjacent cardinal direction is obstructed (because diagonals add a lot of issues in squre grids)
- mirror the sprites.
But you still have 2 directions to make (as we did in Zodiac Legion): NW (mirrored to NE) and SW (mirrored to SE).

As for leveraging assets, we went with a very complicated paperdolling system:


That allows us to mix and match armors and weapons.

As for finding a programming partner, it is a bit like fiding your wife. It is very difficult to find the right person, and picking badly might be catastrophic.

What tool/process do you use for creating the animations?

 

[man_at_arms]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with character who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

Right, but if he is the artist, main artist hourly wage is not a huge issue, as the programmer load will typically be even higher, so sprites are still doable in this case.
You can have less facings to do if :
- you don't take direction into account (that's what Battle Brothers did). => only one "direction"

You can also do the following
- don't allow diagonals apart for walking when none of the adjacent cardinal direction is obstructed (because diagonals add a lot of issues in squre grids)
- mirror the sprites.
But you still have 2 directions to make (as we did in Zodiac Legion): NW (mirrored to NE) and SW (mirrored to SE).

As for leveraging assets, we went with a very complicated paperdolling system:


That allows us to mix and match armors and weapons.

As for finding a programming partner, it is a bit like fiding your wife. It is very difficult to find the right person, and picking badly might be catastrophic.

When you mirrored the sprites, did you just accept, as a trade-off, that the asymmetric elements of a character would look flipped (e.g. weapon in wrong hand), or did you have some other technique for mitigating that?

 

[Galdred]

What tool/process do you use for creating the animations?

Most of it is detailled in the Twitter thread (and probably in some part of the Zodiac Legion thread):
The artists started planning the animations with stick figures, then made them for the skeleton, then added a "human flesh" layer over it.
Then they added each of the armor pieces variation on top
We worked with GraphicsGale. It is a bit dated UI wise, but it has a few great features:
The way it organizes layers is really great, which is critical in our case because some frames have 250 layers:
You can hide/show all layers wearing the same name among all frames, while Aseprite has layer matching priority (so if the sword starts higher than the shield, and ends up behind in another frame, you need separate layers for the sword).

But Aseprite can be extended with lua, so I added quite a few scripts to make navigating and importing layers easier.

When you mirrored the sprites, did you just accept, as a trade-off, that the asymmetric elements of a character would look flipped (e.g. weapon in wrong hand), or did you have some other technique for mitigating that?

It has been an accepted convention for ages in isometric games I think. I never had any complain about it.

 

[man_at_arms]

[...]

When you mirrored the sprites, did you just accept, as a trade-off, that the asymmetric elements of a character would look flipped (e.g. weapon in wrong hand), or did you have some other technique for mitigating that?

It has been an accepted convention for ages in isometric games I think. I never had any complain about it.

Yeah, I know that it's an accepted convention, but I was wondering if you had tried to solve it, because I'm always curious about process details like that.

 

[Meatbag]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with characters who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

This is smart advice. Personally I really I really love having 8 directions of movement and I think having them all fully rendered would be cool visual pint of difference as it's very rare for hand drawn games of this style to do so. A few of the animations can be mirrored but as you say, as soon as I put a weapon in the characters hand and put them in a bladed stance, I basically have to draw every direction by hand. I don't mind it too much as I actually really enjoy the process and just see it as part of my education as I never studied or worked in art, game dev or animation.

I've looked into animating with bones but there's so much clean up involved (for pixel art sprites of this size) that it's actually faster to just draw from scratch. This is because certain elements rotate and show new surfaces to the 'camera' for a lot of the animations.

Though I do hear you that I need to be very weary of the huge mountain of animation work that will need doing. Especially as I flesh out the combat system. Only cheats I've worked out so far is reusing animation frames across multiple actions. For example I could create multiple attack variations by changing the timing of the frames, double up or tripling the Hit frames, or only making small alterations like changing the weapon angle. Also I've had some luck reusing anticipation and recovery frames for different attacks. Movement is a bit more tricky to cheat but easier to mirror.

 

[Meatbag]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with character who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

Right, but if he is the artist, main artist hourly wage is not a huge issue, as the programmer load will typically be even higher, so sprites are still doable in this case.
You can have less facings to do if :
- you don't take direction into account (that's what Battle Brothers did). => only one "direction"

You can also do the following
- don't allow diagonals apart for walking when none of the adjacent cardinal direction is obstructed (because diagonals add a lot of issues in squre grids)
- mirror the sprites.
But you still have 2 directions to make (as we did in Zodiac Legion): NW (mirrored to NE) and SW (mirrored to SE).

As for leveraging assets, we went with a very complicated paperdolling system:


That allows us to mix and match armors and weapons.

As for finding a programming partner, it is a bit like fiding your wife. It is very difficult to find the right person, and picking badly might be catastrophic.

I plan on implementing a similar paperdolling method in my game. You can see my attempt with the link the original post. Do you have any advice or did you have any big takeaways after using this method?

Did you ever run into instances where you had a piece of gear that needed to appear both in front of, and behind key sprites at the same time? (Say a pair of pauldrons has one side needing to appear in front of the head and one behind. Or a cloak that needs to appear above the shoulder and also behind the legs.) is the solution just to cut them up onto different layers?

 

[man_at_arms]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with characters who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

This is smart advice. Personally I really I really love having 8 directions of movement and I think having them all fully rendered would be cool visual pint of difference as it's very rare for hand drawn games of this style to do so. A few of the animations can be mirrored but as you say, as soon as I put a weapon in the characters hand and put them in a bladed stance, I basically have to draw every direction by hand. I don't mind it too much as I actually really enjoy the process and just see it as part of my education as I never studied or worked in art, game dev or animation.

I've looked into animating with bones but there's so much clean up involved (for pixel art sprites of this size) that it's actually faster to just draw from scratch. This is because certain elements rotate and show new surfaces to the 'camera' for a lot of the animations.

Though I do hear you that I need to be very weary of the huge mountain of animation work that will need doing. Especially as I flesh out the combat system. Only cheats I've worked out so far is reusing animation frames across multiple actions. For example I could create multiple attack variations by changing the timing of the frames, double up or tripling the Hit frames, or only making small alterations like changing the weapon angle. Also I've had some luck reusing anticipation and recovery frames for different attacks. Movement is a bit more tricky to cheat but easier to mirror.

Indeed, 2D art using bones is not well suited to pixel art at that resolution; it's more typical for higher resolution, painterly-styled art, where the stretching and bending of the image looks fitting. It was more an example of a streamlining technique, rather than something specific to your art samples.

On the subject of the design of the game:

You say you would like to have a demo to attract financing, and so you would ultimately try to make a commercial project. My guess is that if you intend to make a commercial project, you will likely need one other person who can help with code, testing, implementing content (like mapping, NPC stat blocks, maps, creating dungeons or working on procedural content, the data-driven type of stuff) as well as assist with all the other responsibilities of a commercial project (social media, Steam community, applying for grants and media funding, incorporation, all the admin and prep involved in something like a Kickstarter, etc). Therefore, you need something that has at least the chance to appeal to enough customers so that two people can make a livable income, after Steam's cut, after the Kickstarter & payment processor cut, and possibly a publisher cut, if your game gets picked up by one of them, and they take charge of marketing and other admin / social related tasks. And that's if everything goes well, the stars are aligned, your project gets discovered and players like it.

In order to make this kind of money, I believe you should try to do a bit of market analysis, look at the types of indie RPGs (or RPG-adjacent genres, like tactics or roguelikes) that sell, and bring your core mechanics closer to that genre. I think you should also be careful about verisimilitude. Verisimilitude-based experiences, like Kingdom Come Deliverance, or a game like Tarkov, are popular, but also real-time, first person and strive for photorealism. In the 2D, top-down space, verisimilitude can very easily be associated with banality, and have trouble standing out. RPGs that people remember tend to have elements of weirdness to them, even if they take themselves seriously. Morrowind, Planescape Torment, Fallout, Gothic, Underrail, D&D games, Age of Decadence, Space Wreck, Kenshi, basically every cRPG I can think of, has fantasy, sci-fi, cyberpunk, steampunk, post-apocalypse or some kind of "weirdness" to them that makes them distinctive. For games that are more grounded, like Mount & Blade or Battle Brothers, they are typically tactics-related games, where you command lots of character, rather than a single character. Battle Brothers distinguishes itself with its iconic artstyle for the characters (no legs), while Mount & Blade had exceptional first/third person mounted and melee combat systems, good multiplayer, and an impressive number of bots in mass battles, particularly for its time.

If you hadn't mentioned the financial side, I would usually just say do whatever you are passionate about, since it will usually just amount to hobby projects, but if you are thinking of turning it into a career, you must combine personal passion with finding an audience. You can do this without "selling out" or "casualizing". It's more about standing out, being memorable and having a good moment-to-moment experience. And catering to an existing niche large enough to sustain you. If you are a godlike dev you might create your own niche but that's really exceptional.

 

[The_Sloth_Sleeps]

I happen to be a senior-level developer who is looking a competent artist interested in the CRPG space. I would echo sentiments on avoiding Fiverr or any short term contractor. However, I do believe in the 2-man artist-programmer indie team as a force multiplier rather than a weakness, although it takes very good alignment between the two.

I also agree with those that caution about the workload of isometric, due to having 8 different facings, especially if the characters have asymmetry, which is the case with characters who have a 1H weapon in one hand and a shield in the other. A lot of classic isometric games used 3D models, rendered from different angles, and converted to sprites. These days, that pipeline is more efficient as a pure 3D game. I would brainstorm about system mechanics and visual styles that would limit the art to as few directions as possible (possibly just one facing forward, another facing backward), in a projection like top down oblique (Ultima VII, Pokemon games, old Zelda games, a lot of retroclones these days, although you can make top down oblique art that doesn't look like retroclone pixel trash). There are many possibilities, but I would definitely have a mindset of trying to cut as much work as possible while maintaining the core design pillars.

There are also techniques like 2D skeletal animation (bones) that allow for breathing cycles, moving limbs, etc, without having to animate each frame yourself.

This is smart advice. Personally I really I really love having 8 directions of movement and I think having them all fully rendered would be cool visual pint of difference as it's very rare for hand drawn games of this style to do so. A few of the animations can be mirrored but as you say, as soon as I put a weapon in the characters hand and put them in a bladed stance, I basically have to draw every direction by hand. I don't mind it too much as I actually really enjoy the process and just see it as part of my education as I never studied or worked in art, game dev or animation.

I've looked into animating with bones but there's so much clean up involved (for pixel art sprites of this size) that it's actually faster to just draw from scratch. This is because certain elements rotate and show new surfaces to the 'camera' for a lot of the animations.

Though I do hear you that I need to be very weary of the huge mountain of animation work that will need doing. Especially as I flesh out the combat system. Only cheats I've worked out so far is reusing animation frames across multiple actions. For example I could create multiple attack variations by changing the timing of the frames, double up or tripling the Hit frames, or only making small alterations like changing the weapon angle. Also I've had some luck reusing anticipation and recovery frames for different attacks. Movement is a bit more tricky to cheat but easier to mirror.

Indeed, 2D art using bones is not well suited to pixel art at that resolution; it's more typical for higher resolution, painterly-styled art, where the stretching and bending of the image looks fitting. It was more an example of a streamlining technique, rather than something specific to your art samples.

On the subject of the design of the game:

You say you would like to have a demo to attract financing, and so you would ultimately try to make a commercial project. My guess is that if you intend to make a commercial project, you will likely need one other person who can help with code, testing, implementing content (like mapping, NPC stat blocks, maps, creating dungeons or working on procedural content, the data-driven type of stuff) as well as assist with all the other responsibilities of a commercial project (social media, Steam community, applying for grants and media funding, incorporation, all the admin and prep involved in something like a Kickstarter, etc). Therefore, you need something that has at least the chance to appeal to enough customers so that two people can make a livable income, after Steam's cut, after the Kickstarter & payment processor cut, and possibly a publisher cut, if your game gets picked up by one of them, and they take charge of marketing and other admin / social related tasks. And that's if everything goes well, the stars are aligned, your project gets discovered and players like it.

In order to make this kind of money, I believe you should try to do a bit of market analysis, look at the types of indie RPGs (or RPG-adjacent genres, like tactics or roguelikes) that sell, and bring your core mechanics closer to that genre. I think you should also be careful about verisimilitude. Verisimilitude-based experiences, like Kingdom Come Deliverance, or a game like Tarkov, are popular, but also real-time, first person and strive for photorealism. In the 2D, top-down space, verisimilitude can very easily be associated with banality, and have trouble standing out. RPGs that people remember tend to have elements of weirdness to them, even if they take themselves seriously. Morrowind, Planescape Torment, Fallout, Gothic, Underrail, D&D games, Age of Decadence, Space Wreck, Kenshi, basically every cRPG I can think of, has fantasy, sci-fi, cyberpunk, steampunk, post-apocalypse or some kind of "weirdness" to them that makes them distinctive. For games that are more grounded, like Mount & Blade or Battle Brothers, they are typically tactics-related games, where you command lots of character, rather than a single character. Battle Brothers distinguishes itself with its iconic artstyle for the characters (no legs), while Mount & Blade had exceptional first/third person mounted and melee combat systems, good multiplayer, and an impressive number of bots in mass battles, particularly for its time.

If you hadn't mentioned the financial side, I would usually just say do whatever you are passionate about, since it will usually just amount to hobby projects, but if you are thinking of turning it into a career, you must combine personal passion with finding an audience. You can do this without "selling out" or "casualizing". It's more about standing out, being memorable and having a good moment-to-moment experience. And catering to an existing niche large enough to sustain you. If you are a godlike dev you might create your own niche but that's really exceptional.

This is kind of the problem I have, whats caused a stall. I reached the stage in developing that I had to decide what I actually really wanted my game to be about. Trying to choose 1 or 2 things to really focus on, and those things are going to impact the engine design.
Ultimately this is where I am stuck, I have not found what is it I am really trying to do, because going to wide and deep is not feasible as a single dev. For a passion project its not a problem, but if you want to make *some* money, its really a lot to think about. Do one or two things and do them well.

So I would echo what you are saying.

Having a working demo and steam page is a starting point...although I don't know much about funding. I think for things like KS you of course have to deal with KS and their pound of flesh, and you are responsible for driving traffic to the campaign. I assume that needs some kind of deep interest from several communities, some enormous interest from somewhere, and/or marketing. It sounds like a big challenge and from what I've seen in the past maybe 95% likely to get completely mediocre sub $5k campaigns.

Selah.

 

[Galdred]

I plan on implementing a similar paperdolling method in my game. You can see my attempt with the link the original post. Do you have any advice or did you have any big takeaways after using this method?

Did you ever run into instances where you had a piece of gear that needed to appear both in front of, and behind key sprites at the same time? (Say a pair of pauldrons has one side needing to appear in front of the head and one behind. Or a cloak that needs to appear above the shoulder and also behind the legs.) is the solution just to cut them up onto different layers?

Not much comes to my mind, but in our case, having good asset variety was possible because we recycled a lot of frames apart from legs and arms:
legs and arms have something like 150 frames, heads have 6, torso 10, and pauldrons around 30.
copy/pasting is your friends (also, I would recommend keeping the framecount a bit lower than we did, as our system makes it pretty expensive to add arms/leg armor...).

As for layers that need to be on both sides of a sprite, you have to split them:
We have a separate layer for right and left pauldron, and even for the front and rear of some tassets.

Actually here is our list of layers:

• head/helmet
• collar/gorget
• left pauldron
• right pauldron
• left arm/left vambrace
• right arm/right vambrace
• surcoat
• torso/breastplate
• tassets: front
• tassets: rear
• legs/greaves

The surcoat was made its own layer because it covers both torso and tassets, but we could just have split it in 2 parts instead.
We have a single layer for both legs, but having 2 would probably have made recycling frames more efficient.

On the subject of the design of the game:

You say you would like to have a demo to attract financing, and so you would ultimately try to make a commercial project. My guess is that if you intend to make a commercial project, you will likely need one other person who can help with code, testing, implementing content (like mapping, NPC stat blocks, maps, creating dungeons or working on procedural content, the data-driven type of stuff) as well as assist with all the other responsibilities of a commercial project (social media, Steam community, applying for grants and media funding, incorporation, all the admin and prep involved in something like a Kickstarter, etc). Therefore, you need something that has at least the chance to appeal to enough customers so that two people can make a livable income, after Steam's cut, after the Kickstarter & payment processor cut, and possibly a publisher cut, if your game gets picked up by one of them, and they take charge of marketing and other admin / social related tasks. And that's if everything goes well, the stars are aligned, your project gets discovered and players like it.

In order to make this kind of money, I believe you should try to do a bit of market analysis, look at the types of indie RPGs (or RPG-adjacent genres, like tactics or roguelikes) that sell, and bring your core mechanics closer to that genre. I think you should also be careful about verisimilitude. Verisimilitude-based experiences, like Kingdom Come Deliverance, or a game like Tarkov, are popular, but also real-time, first person and strive for photorealism. In the 2D, top-down space, verisimilitude can very easily be associated with banality, and have trouble standing out. RPGs that people remember tend to have elements of weirdness to them, even if they take themselves seriously. Morrowind, Planescape Torment, Fallout, Gothic, Underrail, D&D games, Age of Decadence, Space Wreck, Kenshi, basically every cRPG I can think of, has fantasy, sci-fi, cyberpunk, steampunk, post-apocalypse or some kind of "weirdness" to them that makes them distinctive. For games that are more grounded, like Mount & Blade or Battle Brothers, they are typically tactics-related games, where you command lots of character, rather than a single character. Battle Brothers distinguishes itself with its iconic artstyle for the characters (no legs), while Mount & Blade had exceptional first/third person mounted and melee combat systems, good multiplayer, and an impressive number of bots in mass battles, particularly for its time.

If you hadn't mentioned the financial side, I would usually just say do whatever you are passionate about, since it will usually just amount to hobby projects, but if you are thinking of turning it into a career, you must combine personal passion with finding an audience. You can do this without "selling out" or "casualizing". It's more about standing out, being memorable and having a good moment-to-moment experience. And catering to an existing niche large enough to sustain you. If you are a godlike dev you might create your own niche but that's really exceptional.

I think a realistic medieval game could work, but one issue is also that the game needs to have interesting combat. One core issue is that it is very, very hard to make 1 character non action combat interesting, and when it is, it is usually only with a spellcaster, but the general ideas are good (having ways to degrade stability or inflict damage directly, things like that...). Combat being a bit dull was one of the issues with Darklands, and it didn't even have single characters, so you definitely need more maneuvers than just attack.

As for sustainability, it is very hard to tell:
The advantage is that there are very little competition in historically accurate games, but one issue is that it might require some research, as there would probably be a strong overlap with turbo autists getting triggered by historical inaccuracies.
One thing that works well is historical with mythical creatures (King Arthur would be a good example), but if you have interesting combat, you can probably even skip the surnatural.
But man_at_arms is right, you really need to make sure it can be sustainable through market research first.
As for funding:
Going historical would probably make it pretty easy to get public funding (if you are from Canada or Europe). But you can go kickstarter on art alone, however, that will not bring you enough to get a developer, so that would only help covering marketing.

 

[Meatbag]

I plan on implementing a similar paperdolling method in my game. You can see my attempt with the link the original post. Do you have any advice or did you have any big takeaways after using this method?

Did you ever run into instances where you had a piece of gear that needed to appear both in front of, and behind key sprites at the same time? (Say a pair of pauldrons has one side needing to appear in front of the head and one behind. Or a cloak that needs to appear above the shoulder and also behind the legs.) is the solution just to cut them up onto different layers?

Not much comes to my mind, but in our case, having good asset variety was possible because we recycled a lot of frames apart from legs and arms:
legs and arms have something like 150 frames, heads have 6, torso 10, and pauldrons around 30.
copy/pasting is your friends (also, I would recommend keeping the framecount a bit lower than we did, as our system makes it pretty expensive to add arms/leg armor...).

As for layers that need to be on both sides of a sprite, you have to split them:
We have a separate layer for right and left pauldron, and even for the front and rear of some tassets.

Actually here is our list of layers:

• head/helmet
• collar/gorget
• left pauldron
• right pauldron
• left arm/left vambrace
• right arm/right vambrace
• surcoat
• torso/breastplate
• tassets: front
• tassets: rear
• legs/greaves

The surcoat was made its own layer because it covers both torso and tassets, but we could just have split it in 2 parts instead.
We have a single layer for both legs, but having 2 would probably have made recycling frames more efficient.

On the subject of the design of the game:

You say you would like to have a demo to attract financing, and so you would ultimately try to make a commercial project. My guess is that if you intend to make a commercial project, you will likely need one other person who can help with code, testing, implementing content (like mapping, NPC stat blocks, maps, creating dungeons or working on procedural content, the data-driven type of stuff) as well as assist with all the other responsibilities of a commercial project (social media, Steam community, applying for grants and media funding, incorporation, all the admin and prep involved in something like a Kickstarter, etc). Therefore, you need something that has at least the chance to appeal to enough customers so that two people can make a livable income, after Steam's cut, after the Kickstarter & payment processor cut, and possibly a publisher cut, if your game gets picked up by one of them, and they take charge of marketing and other admin / social related tasks. And that's if everything goes well, the stars are aligned, your project gets discovered and players like it.

In order to make this kind of money, I believe you should try to do a bit of market analysis, look at the types of indie RPGs (or RPG-adjacent genres, like tactics or roguelikes) that sell, and bring your core mechanics closer to that genre. I think you should also be careful about verisimilitude. Verisimilitude-based experiences, like Kingdom Come Deliverance, or a game like Tarkov, are popular, but also real-time, first person and strive for photorealism. In the 2D, top-down space, verisimilitude can very easily be associated with banality, and have trouble standing out. RPGs that people remember tend to have elements of weirdness to them, even if they take themselves seriously. Morrowind, Planescape Torment, Fallout, Gothic, Underrail, D&D games, Age of Decadence, Space Wreck, Kenshi, basically every cRPG I can think of, has fantasy, sci-fi, cyberpunk, steampunk, post-apocalypse or some kind of "weirdness" to them that makes them distinctive. For games that are more grounded, like Mount & Blade or Battle Brothers, they are typically tactics-related games, where you command lots of character, rather than a single character. Battle Brothers distinguishes itself with its iconic artstyle for the characters (no legs), while Mount & Blade had exceptional first/third person mounted and melee combat systems, good multiplayer, and an impressive number of bots in mass battles, particularly for its time.

If you hadn't mentioned the financial side, I would usually just say do whatever you are passionate about, since it will usually just amount to hobby projects, but if you are thinking of turning it into a career, you must combine personal passion with finding an audience. You can do this without "selling out" or "casualizing". It's more about standing out, being memorable and having a good moment-to-moment experience. And catering to an existing niche large enough to sustain you. If you are a godlike dev you might create your own niche but that's really exceptional.

I think a realistic medieval game could work, but one issue is also that the game needs to have interesting combat. One core issue is that it is very, very hard to make 1 character non action combat interesting, and when it is, it is usually only with a spellcaster, but the general ideas are good (having ways to degrade stability or inflict damage directly, things like that...). Combat being a bit dull was one of the issues with Darklands, and it didn't even have single characters, so you definitely need more maneuvers than just attack.

As for sustainability, it is very hard to tell:
The advantage is that there are very little competition in historically accurate games, but one issue is that it might require some research, as there would probably be a strong overlap with turbo autists getting triggered by historical inaccuracies.
One thing that works well is historical with mythical creatures (King Arthur would be a good example), but if you have interesting combat, you can probably even skip the surnatural.
But man_at_arms is right, you really need to make sure it can be sustainable through market research first.
As for funding:
Going historical would probably make it pretty easy to get public funding (if you are from Canada or Europe). But you can go kickstarter on art alone, however, that will not bring you enough to get a developer, so that would only help covering marketing.

Thanks man, this is all super helpful!

 

[droozy]

Sorry if this has been answered already, but are you doing a Diablo 2 style modular sprite system, or are those armor sets all drawn as a single set?
If you're looking to do the former but aren't already, there's a guy that made a totally opensource diablo clone that showcases that art technique: https://github.com/flareteam/flare-game

if you browse the art_src/character/hero folder, you'll find what the actual modular sprite sheets look like to achieve this. He also commented in an old reddit thread on the technique, I can dig that up if you want.