If it's technically feasible, maybe it could use some ambient occlusion or shadows near the water, so it gives the illusion of the bridge being above the water.
Well my game engine is 2D, so I can't really move the camera and have the characters do a cutscene.
Anyway, update on this story stuff. Justin Nichol (concept artist) and I have plotted out a very basic story. I'll draw inspiration from this thread for smaller stories within each chapter of the game. I hope to post more about this soon.
If I were making a bridge, I'd definitely separate the wall/edge sections from the floor. That way it would be easier to make narrow or wide bridges.
Imagine a 3x3 tile area that covers basic bridges in one direction: the corners are like posts, the walkable edges are specialized to make the bridge to grass transition look good, the other edges are the bridge walls, and the center is a plain walkable tile. There'd be another 3x3 set that covers the other direction (running topleft to bottomright); basically render the same 3D objects from a new angle.
Then a bigger bridge could be built by repeating those tiles in whatever direction is needed.
Thanks about the code. Yeah surprisingly this type of game doesn't require a crazy amount of code. I've taken efforts to keep it readable. Also it helps that Flare has a specific duty (action RPG) instead of trying to be a do-all-things game engine.
I'd love to add automated unit tests and regression testing. Some unit testing should be easy to set up. Testing interface or combat stuff seems tricker, and that's probably where the trickier bugs will appear.
Anon, these tiles only work on 64x32 isometric tile bases. I don't know of a good way to render these for square base tiles, besides stretching the parts in a weird way.
Consider that this is an action RPG. Thus, it can get away with being very light on story.
Examples:
In Diablo 1 there isn't an explanation of the hero's involvement at all. Nor is there a significant story besides "the devil's down there". Diablo 1 has a small set of short stories relating to some levels but that's about it, they barely tie into an overall story.
In Diablo 2 the hero's involvement is little more than "we're glad you're here" from the NPCs. But D2 has a much more developed story with the demon siblings and the horadric stuff.
Torchlight has a short explanation for each class being there, but other than that it's just a dungeon romp. There's one Big Bad at the end, but most of the quests are just something to do in the next dungeon level.
I admire stories that are very light, where the player fills in the details with his imagination. Example: Shadow of the Colossus -- I don't need to understand any back story to be emotionally impacted by that game.
Current-generation consoles probably spend about 5k to 10k poly for main characters -- less if you have dozens/hundreds of characters on screen simultaneously, and maybe much more if you only have a few characters on screen at once. Often a much higher poly model is made (1M+ poly) with subdivision and sculpting, and the detail is baked onto the Normal Map of a lower poly model. Of course, some games swap in a lower-poly model when that object is viewed at a distance.
Depending on the game, though, you can accomplish quite a lot with far fewer polygons. In my game I use 2D renders of the 3D models so poly-count isn't an issue, but generally I make low poly models (about 1k-2k).
Manifold meshes are preferred but not required. Sometimes just for performance reasons you might not worry about the extra polys spent on making it perfectly manifold. I'm sure some things (e.g. animated/dynamic cloth) are easier to work with if they're one-sided and not manifold. The exception to all of this: if you're doing a very specific type of game that requires physics to interact with your mesh.
I keep an eye out for coding style before I approve Pull Requests -- if something is implemented in a funky or confusing way I'll ask for a revision before approving. I'm not too picky though.
What could definitely be useful is some code house-cleaning, e.g. add javadoc style comments to all functions. I know soon we'll be making a pass to move all magic numbers to constants, and possibly into config files (that's what the /engine/ folder is for). Some standardizing on function/variable names etc. could help.
I think there's going to be quite a lot of code hacking with this translations/mods/unicode work coming up, so maybe after that is done we can make a cleaning pass.
These look great. I like the textures especially.
If it's technically feasible, maybe it could use some ambient occlusion or shadows near the water, so it gives the illusion of the bridge being above the water.
Well my game engine is 2D, so I can't really move the camera and have the characters do a cutscene.
Anyway, update on this story stuff. Justin Nichol (concept artist) and I have plotted out a very basic story. I'll draw inspiration from this thread for smaller stories within each chapter of the game. I hope to post more about this soon.
If I were making a bridge, I'd definitely separate the wall/edge sections from the floor. That way it would be easier to make narrow or wide bridges.
Imagine a 3x3 tile area that covers basic bridges in one direction: the corners are like posts, the walkable edges are specialized to make the bridge to grass transition look good, the other edges are the bridge walls, and the center is a plain walkable tile. There'd be another 3x3 set that covers the other direction (running topleft to bottomright); basically render the same 3D objects from a new angle.
Then a bigger bridge could be built by repeating those tiles in whatever direction is needed.
Thanks about the code. Yeah surprisingly this type of game doesn't require a crazy amount of code. I've taken efforts to keep it readable. Also it helps that Flare has a specific duty (action RPG) instead of trying to be a do-all-things game engine.
I'd love to add automated unit tests and regression testing. Some unit testing should be easy to set up. Testing interface or combat stuff seems tricker, and that's probably where the trickier bugs will appear.
Myckel: if your bridge has a noticeable arch then yes, you'd have to alter the hero height.
If the bridge is flat I'd just fake it; offset the position of the bridge so the top of it aligns with the regular grid.
Anon, these tiles only work on 64x32 isometric tile bases. I don't know of a good way to render these for square base tiles, besides stretching the parts in a weird way.
Consider that this is an action RPG. Thus, it can get away with being very light on story.
Examples:
In Diablo 1 there isn't an explanation of the hero's involvement at all. Nor is there a significant story besides "the devil's down there". Diablo 1 has a small set of short stories relating to some levels but that's about it, they barely tie into an overall story.
In Diablo 2 the hero's involvement is little more than "we're glad you're here" from the NPCs. But D2 has a much more developed story with the demon siblings and the horadric stuff.
Torchlight has a short explanation for each class being there, but other than that it's just a dungeon romp. There's one Big Bad at the end, but most of the quests are just something to do in the next dungeon level.
I admire stories that are very light, where the player fills in the details with his imagination. Example: Shadow of the Colossus -- I don't need to understand any back story to be emotionally impacted by that game.
Greetings Quandtum!
Current-generation consoles probably spend about 5k to 10k poly for main characters -- less if you have dozens/hundreds of characters on screen simultaneously, and maybe much more if you only have a few characters on screen at once. Often a much higher poly model is made (1M+ poly) with subdivision and sculpting, and the detail is baked onto the Normal Map of a lower poly model. Of course, some games swap in a lower-poly model when that object is viewed at a distance.
Depending on the game, though, you can accomplish quite a lot with far fewer polygons. In my game I use 2D renders of the 3D models so poly-count isn't an issue, but generally I make low poly models (about 1k-2k).
Manifold meshes are preferred but not required. Sometimes just for performance reasons you might not worry about the extra polys spent on making it perfectly manifold. I'm sure some things (e.g. animated/dynamic cloth) are easier to work with if they're one-sided and not manifold. The exception to all of this: if you're doing a very specific type of game that requires physics to interact with your mesh.
Hope this helps!
If someone wants to take a crack at this, this tutorial may be of help: http://clintbellanger.net/rpg/tutorials/isometric_tiles/ . Also, I'm happy to answer questions about making Flare-compatible tiles.
If the task goes unfulfilled, I can probably do it myself. I hope to work on the grassland tile set as my next big task for Flare.
I keep an eye out for coding style before I approve Pull Requests -- if something is implemented in a funky or confusing way I'll ask for a revision before approving. I'm not too picky though.
What could definitely be useful is some code house-cleaning, e.g. add javadoc style comments to all functions. I know soon we'll be making a pass to move all magic numbers to constants, and possibly into config files (that's what the /engine/ folder is for). Some standardizing on function/variable names etc. could help.
I think there's going to be quite a lot of code hacking with this translations/mods/unicode work coming up, so maybe after that is done we can make a cleaning pass.
Pages