The cloudy mountain image I attached can be used as a material-specific reflection map. You may not need this if you put the swords into a scene that already has an environnment map. (the image is public domain from Burning Well)
I'd like to create .obj (or similar) files for each of these that have materials setup to work correctly upon loading into Unity or Unreal. I don't have that figured out yet (any tips?). For now expect to tweak material settings if importing these into another system.
ShannonGames, all art on OpenGameArt can be used commercially.
This art is licensed CC-BY which basically means you can use it as long as you give credit. So e.g. put my name somwhere in your game's credits under "additional art by:"
Flare purposefully cuts a lot of corners to assume a single hero game. There would definitely be a lot of gutting of the code to make full squads work. Especially if you want to be able to control all of them simultaneously, or be able to command each one separately.
Some of that work may have been bridged because there is light support for Minions/Pets. So combat featuring multiple good-guy units is at least minimally functional.
Another feature to look out for is the Transform feature. Currently that's used to magically transform your character into a different enemy type. Really what it does is gives you the sprites and controls of that creature. Instead of using it to polymorph self, it could be modified to take control of a target unit. That could be one way of switching controls between the units on the squad.
If your game isn't a single player action RPG really close to this Diablo style, then Flare probably isn't the best fit. If you're more interested in code hacking than releasing a game, then Flare could be a fun place to experiment.
I looked for this configuration but couldn't quite find it where I expected it. There's probably enough customization under the hood that Bart will be the one to add allowed file types.
There are a lot of things that can make a model "dirty" or amateurish. Assuming making game-ready models here.
- Shaped in an overly blocky (amateur extruder) or overly blobby (amateur sculpter) way
- Too many polys
- Not enough polys where needed (e.g. joints)
- Not sticking to quads and good topology (unnecessary tris, ngons, etc)
- Overlapping polys that are z-fighting
- Normals not facing correct direction
- Holes in the model (non-manifold), especially if you want to later 3D print or use perfect collisions
- No UV mapping
- UV seams in bad places
- UV poorly done causing texture distortion
- Poor or inconsistent quality textures
- Materials not baked and exported
- Materials missing maps usually found on a given material e.g. specular/gloss, normal, metal/roughness, ambient occlusion, cavity, height, emit, wear, etc.
Malifer, if there's a real-world equivalent it does help to at least get the approximate scale right. But not all modelers worry about that for stand-alone props, cause resizing isn't too difficult for the end devs.
In my games I do try to use the 1 unit = 1 meter scale in Blender for all my 3D models.
capbros: Yeah this is closer to Game Boy resolution. I've been seeing a lot of fun PICO-8 art on my feed, and that system is 128x128.
I didn't give it a ton of thought beyond that. I did some mockups with 16px tiles and it felt good enough. The bigger challenge for me has come from sticking with single-screen rooms (scrolling on vanilla HTML5 isn't pretty on every device at the moment). This resolution and screen size mean designing 8x8 tile rooms. That's really only big enough for one thing in each room, like one item pickup or one platforming challenge.
It's turning out fun though. To fit everything in an 8x8 screen, the rover's basic jumps are pretty small. It can clear a 2 block high jump, or 4 blocks with double jump. The rover can just barely (almost frame perfect) clear a gap that is 6 across, which is a full screen wide at 8 tiles. The sweet spot for fun jumps turns out to be 4 across, 2 up and 5 across, 1 up. With double jump there are lots more interesting skill jumps possible.
I wanted to keep the entire game small enough so that I could start and finish it just for kicks. With just jumping and exploring as game mechanics, there's only so long the game ought to be anyway.
Limitations are fun! They lead to creativity and finished games.
Malifer, no my game won't have a separate driver and all that. I'm keeping this game super simple. But I'll release all the art and code later, so someone could add that stuff in to their own game.
The cloudy mountain image I attached can be used as a material-specific reflection map. You may not need this if you put the swords into a scene that already has an environnment map. (the image is public domain from Burning Well)
I'd like to create .obj (or similar) files for each of these that have materials setup to work correctly upon loading into Unity or Unreal. I don't have that figured out yet (any tips?). For now expect to tweak material settings if importing these into another system.
ShannonGames, all art on OpenGameArt can be used commercially.
This art is licensed CC-BY which basically means you can use it as long as you give credit. So e.g. put my name somwhere in your game's credits under "additional art by:"
Flare purposefully cuts a lot of corners to assume a single hero game. There would definitely be a lot of gutting of the code to make full squads work. Especially if you want to be able to control all of them simultaneously, or be able to command each one separately.
Some of that work may have been bridged because there is light support for Minions/Pets. So combat featuring multiple good-guy units is at least minimally functional.
Another feature to look out for is the Transform feature. Currently that's used to magically transform your character into a different enemy type. Really what it does is gives you the sprites and controls of that creature. Instead of using it to polymorph self, it could be modified to take control of a target unit. That could be one way of switching controls between the units on the squad.
If your game isn't a single player action RPG really close to this Diablo style, then Flare probably isn't the best fit. If you're more interested in code hacking than releasing a game, then Flare could be a fun place to experiment.
@Bluestar55 Dinos are neat! Animating a coin is several hours of work. If you'd like to set up a paid commission, email me at clintbellanger@gmail.com
I really love the way the floor section is lit just slightly different than the wall. It adds all that dimension that I was missing.
I looked for this configuration but couldn't quite find it where I expected it. There's probably enough customization under the hood that Bart will be the one to add allowed file types.
There are a lot of things that can make a model "dirty" or amateurish. Assuming making game-ready models here.
- Shaped in an overly blocky (amateur extruder) or overly blobby (amateur sculpter) way
- Too many polys
- Not enough polys where needed (e.g. joints)
- Not sticking to quads and good topology (unnecessary tris, ngons, etc)
- Overlapping polys that are z-fighting
- Normals not facing correct direction
- Holes in the model (non-manifold), especially if you want to later 3D print or use perfect collisions
- No UV mapping
- UV seams in bad places
- UV poorly done causing texture distortion
- Poor or inconsistent quality textures
- Materials not baked and exported
- Materials missing maps usually found on a given material e.g. specular/gloss, normal, metal/roughness, ambient occlusion, cavity, height, emit, wear, etc.
- Missing armature
- Poor armature (bad deformations when bending)
- Missing animations
- Poor animations (not enough anticipation, acceleration, follow-through, squash and stretch, etc)
- Scale, Rotate, Translate isn't applied (should be at original values 1,0,0) for all objects
Malifer, if there's a real-world equivalent it does help to at least get the approximate scale right. But not all modelers worry about that for stand-alone props, cause resizing isn't too difficult for the end devs.
In my games I do try to use the 1 unit = 1 meter scale in Blender for all my 3D models.
capbros: Yeah this is closer to Game Boy resolution. I've been seeing a lot of fun PICO-8 art on my feed, and that system is 128x128.
I didn't give it a ton of thought beyond that. I did some mockups with 16px tiles and it felt good enough. The bigger challenge for me has come from sticking with single-screen rooms (scrolling on vanilla HTML5 isn't pretty on every device at the moment). This resolution and screen size mean designing 8x8 tile rooms. That's really only big enough for one thing in each room, like one item pickup or one platforming challenge.
It's turning out fun though. To fit everything in an 8x8 screen, the rover's basic jumps are pretty small. It can clear a 2 block high jump, or 4 blocks with double jump. The rover can just barely (almost frame perfect) clear a gap that is 6 across, which is a full screen wide at 8 tiles. The sweet spot for fun jumps turns out to be 4 across, 2 up and 5 across, 1 up. With double jump there are lots more interesting skill jumps possible.
I wanted to keep the entire game small enough so that I could start and finish it just for kicks. With just jumping and exploring as game mechanics, there's only so long the game ought to be anyway.
Limitations are fun! They lead to creativity and finished games.
Malifer, no my game won't have a separate driver and all that. I'm keeping this game super simple. But I'll release all the art and code later, so someone could add that stuff in to their own game.
Pages