REFINING DESIGN
Interestingly enough, I've been working with horses for the past few months and been refining the control design. The actual coding is much less impressive.
As I mentioned in Rouge Type One Step 2.0, Things are slow and I'm working on movement still. I'm using Friendly Cosmonaut's pixel perfect movement rather then Shaun's, because it works into the overall stretch goals of a simple growth/ time/ day night system that is an aspect of the main design. Right now I can't figure the glitch that makes the box draw itself rather than move and ghost underneath walls instead of colliding with them.
Base build will be in Beta when
1. Player Movement & Action
Because I want to include a variation of ways to interact with the map because the more combinations of approaches to play the broader the options in replaying the game.
Kinds of movement are more important to consider than speeds of movement. If the player can run or walk only matters if there are times when both are the optimum option.
Consider this, on a big project maybe you'd see and expect 16 different vehicle types with customization and tuning options, but if every line of code counts why include 10 vehicles that no one will play with? On the same side why code an entirely new vehicle or action that will only be used once in a while? This is why the kind of movement rather than the speed should be considered, if their are 3 options of unlockable vehicles and the only difference is speed then only one is useful at any given time. But if the three move differently; then the result is the player perceives movement differently. Checkers is a different game than Chess. When you play checkers you are looking at the board and movement for each piece all the same, but on a game of Chess every piece matters individually from each other because you must consider the board from a variety of perspectives.
So sticking with that theme of approach and perspective changing what the situation is, we're sticking with classic adventure-game-platforming-puzzle-movement.
That means WASD controls
1.Crawl-walk-run
2.Climb up/down
3.Shoot arrow
4...And catch-all "interact".
Alpha would work include
1.Multiple weapons
2.Jump
3.Swim
4.Swing on rope
5.Mounted(on horse)
2. Level Spawn
The inspiration for what I'm looking to make with the level design comes from the likes of Binding of Issac. Zelda's lost wood segment, and Nuclear Throne.
Base build will include one homestead room that allows entry into the segment of randomly chained forest rooms, each forest room will have randomized placed exits to the other forest rooms(incorrect door will lead one or more rooms back), upon climbing to the top of the trees from any of the forest rooms there will be a vertical parallax triggered to bring a far off tower into view (as if climbing to a greater height and seeing the tower in the distance) The tower will be either in the north, south, west, or east quadrant of the canopy and only visible in the distance if it is daylight, or there is a light in the tower, or a full moon, or whatever.
The purpose of this is to create some benefit or value that can alter the difficulty of finding the tower besides simply changing the number of forest rooms the player must play through before reaching the tower, or what would be characterized as the boss level.
Tentative step after this would be to tool separate randomizing sequences with separate sprites to differentiate between forest dungeon rooms, cavern dungeon rooms, and fortress dungeon rooms.
Option 1
Heartbeast Vs1
Option 2
GmSkew Cave Generator
Option 3(pick me)
Heartbeast vs2
3. Enemy Spawn
In truth I don't want to even begin to tackle this until I've figured how the dungeon generators are worked out, most of the player's interaction with the enemy will be in the random chained rooms, how many I make and how they work together should be linked to the difficulty. I'll set the number of enemies and difficulty of sort of enemy to increase as the player gets closer and closer to whichever specific tower and enemy.
Hand crafted levels will always retain a better quality of polish then any procedural generated level, but what I can do is control how many and how close together the encounters are. The main plan is to aid a single item into the random spawn of the forest that will position the mobs and give them an origin point to operate from.
Beta draft will include a firepit in it's randomly spawned forest levels, the firepit will be in one of the more open corners of the level and will spawn with mobs around it, this will be the basis for where I test out the AI.
Beta will include
1. Mobs that rage while player is in view, chase after the player, attempt to inflict damage, and loose rage while player is out of view.
2. tentative next step at this point would be to build onto the base A.I. and include duties that they might be performing, for example one might tend the fire while idle, the other look for firewood, possibly forging for food (an option if I get the level spawning to work nicely with the farming segment.
4. Art Assets
I'm not bad spritework, but also I'd rather design and aim within my own capabilities. I'll at least gear my placeholder art to resemble a Zelda 3/4th's top down isometrics perspective similar to oldschool gameboy art. I might do a hyper simplified pallet, like Rougelight Or (again) something like Titan Souls.
Interestingly enough, I've been working with horses for the past few months and been refining the control design. The actual coding is much less impressive.
As I mentioned in Rouge Type One Step 2.0, Things are slow and I'm working on movement still. I'm using Friendly Cosmonaut's pixel perfect movement rather then Shaun's, because it works into the overall stretch goals of a simple growth/ time/ day night system that is an aspect of the main design. Right now I can't figure the glitch that makes the box draw itself rather than move and ghost underneath walls instead of colliding with them.
Base build will be in Beta when
1. Player Movement & Action
Because I want to include a variation of ways to interact with the map because the more combinations of approaches to play the broader the options in replaying the game.
Kinds of movement are more important to consider than speeds of movement. If the player can run or walk only matters if there are times when both are the optimum option.
Consider this, on a big project maybe you'd see and expect 16 different vehicle types with customization and tuning options, but if every line of code counts why include 10 vehicles that no one will play with? On the same side why code an entirely new vehicle or action that will only be used once in a while? This is why the kind of movement rather than the speed should be considered, if their are 3 options of unlockable vehicles and the only difference is speed then only one is useful at any given time. But if the three move differently; then the result is the player perceives movement differently. Checkers is a different game than Chess. When you play checkers you are looking at the board and movement for each piece all the same, but on a game of Chess every piece matters individually from each other because you must consider the board from a variety of perspectives.
So sticking with that theme of approach and perspective changing what the situation is, we're sticking with classic adventure-game-platforming-puzzle-movement.
That means WASD controls
1.Crawl-walk-run
2.Climb up/down
3.Shoot arrow
4...And catch-all "interact".
Alpha would work include
1.Multiple weapons
2.Jump
3.Swim
4.Swing on rope
5.Mounted(on horse)
2. Level Spawn
The inspiration for what I'm looking to make with the level design comes from the likes of Binding of Issac. Zelda's lost wood segment, and Nuclear Throne.
Base build will include one homestead room that allows entry into the segment of randomly chained forest rooms, each forest room will have randomized placed exits to the other forest rooms(incorrect door will lead one or more rooms back), upon climbing to the top of the trees from any of the forest rooms there will be a vertical parallax triggered to bring a far off tower into view (as if climbing to a greater height and seeing the tower in the distance) The tower will be either in the north, south, west, or east quadrant of the canopy and only visible in the distance if it is daylight, or there is a light in the tower, or a full moon, or whatever.
The purpose of this is to create some benefit or value that can alter the difficulty of finding the tower besides simply changing the number of forest rooms the player must play through before reaching the tower, or what would be characterized as the boss level.
Tentative step after this would be to tool separate randomizing sequences with separate sprites to differentiate between forest dungeon rooms, cavern dungeon rooms, and fortress dungeon rooms.
Option 1
Heartbeast Vs1
Option 2
GmSkew Cave Generator
Option 3(pick me)
Heartbeast vs2
3. Enemy Spawn
In truth I don't want to even begin to tackle this until I've figured how the dungeon generators are worked out, most of the player's interaction with the enemy will be in the random chained rooms, how many I make and how they work together should be linked to the difficulty. I'll set the number of enemies and difficulty of sort of enemy to increase as the player gets closer and closer to whichever specific tower and enemy.
Hand crafted levels will always retain a better quality of polish then any procedural generated level, but what I can do is control how many and how close together the encounters are. The main plan is to aid a single item into the random spawn of the forest that will position the mobs and give them an origin point to operate from.
Beta draft will include a firepit in it's randomly spawned forest levels, the firepit will be in one of the more open corners of the level and will spawn with mobs around it, this will be the basis for where I test out the AI.
Beta will include
1. Mobs that rage while player is in view, chase after the player, attempt to inflict damage, and loose rage while player is out of view.
2. tentative next step at this point would be to build onto the base A.I. and include duties that they might be performing, for example one might tend the fire while idle, the other look for firewood, possibly forging for food (an option if I get the level spawning to work nicely with the farming segment.
4. Art Assets
I'm not bad spritework, but also I'd rather design and aim within my own capabilities. I'll at least gear my placeholder art to resemble a Zelda 3/4th's top down isometrics perspective similar to oldschool gameboy art. I might do a hyper simplified pallet, like Rougelight Or (again) something like Titan Souls.
As important as art is ultimately, skin without muscle or bones isn't a body, so I'm going to spend little mentioning the art during the bulk of the coding and testing process.
No comments:
Post a Comment