To continue my Kung fu training I'm building a second training dummy for the school, one much lighter than the first. In the back of this photo you can see the body of the dummy. The frame you can see lying on it's back, the bottom support will have triangular braces to the suspension post.
The body of the dummy will have small tire act as a housing on the base and chain to suspend from the post that will mount to the base. Tentative design is to make a three or four part collapsible construct.
The body will have 2 tire halfs on the opposite side of the dummy to both provide spring to the body when using the first wooden arm side; and when inverted provide a rubber spring striking surface. Other projects take priority as I'm on a time crunch to get more tooling made up to prep the barn and forge for winter. Keeping small projects updated here for posterity and to keep my phone memory.
Speaking of:
The first post I made on the construction of my first dummy was deleted, idk when, those photos are gone I'll rewrite some of that when I can if it becomes relevant. Otherwise I'll just take some more photos later
The knifesmithing project has reached the point of needing new tools. Earlier I've recorded the progress with upgrading the forge, I have weldable heat now and am one step closer to that holy grail of making Damascus.
The next important upgrade is power, hammering and forming power that is; I'm one person with limited calories to burn per hour, as much as I can hammer a shape into the other shape I want, the more the steel the harder that is and the more fuel it burns. So my design goals are to build a hammer and press with a non-existant budget. So far I have most of what I need for this upcycled design.
There are some tricky design issues I'm excited to tackle. For resource and reference I'm using; '507 Mechanical Movements Mechanisms and Devices' by Henry T. Brown.
In no specific order these are some of the Mechanisms I hope to include in a drop hammer. The main goal of this project is to make a wooden frame vertical reciprocating drop, to have a treadle powered flywheel powering the lift and drop.
Fig 154 is a drop hammer off a drum
Here is another iteration on the simple drop hammer, closer to our design
Fig 353 is a variation on the Da Vinci cam hammer
Figure 420 is a hammer swing stop,
Fig 416 is a continual motion treadle assistant, the spring helps the right angle turning assisting the momentum of the treadle moving the drum.
Figure 261 is a play on a weight drop pully system where the upstroke is slower than the downstroke
As mentioned in previous post; instead of inserting a z axis and platforms into a randomizing machine, I'm re-evaluating the approach and making each of the puzzel pieces I want the machine to fit together first. I don't need the randomizer throwing together indipendent pieces if I don't know if or where or how they work together.
Sooo. Long time before I've gotten around to updating. This pandemic has had me attempting to focus more on removing obsticles then completing projects.
I'm much farther in understanding how to make a Z access and a global camera that might give me the LOCK ON toggle feature, or panning the camera around the corners, or include an active dynamic camera for mounted combat.
The main issue I've had is structuring the underlying framework of the level to produce all the elements I want to include in the game within the level randomizer. And the proper links between each element so I might be able to add and remove things from a data map into the level and have those dynamics tied to player progress. With that I can have my doors between random levels and the random or otherwise sequence between each level spawned to create the labyrinth between game location. I'll have a very basic map but that will structure the rest of these features I want to plug in.
I have two builds I am refining to try to get this rotation and stacking feature working just right. One is starting from a working randomized build with improper rotation. The second has beautiful rotation and needs the randomizer.
My initial goal was to figure a NorthSouthEastWest door spawn feature to test a basic loop between Spawn Room to the opposite side of a newly spawned room and South Door to the Home Room, with this I'll have the basic fuctions of the map. Then if I can make it add a second room between the Home Room and South Door after entering the North Door, and do the same with the East and West, I'll have something close to the map I want before I start playing with AI. But then I got this sprite stacking working and the movement and envorment I want to fit inside the randomized duengons that make up the game map needs multiple Z axis levels and would require a z axis . I'm just lucky the code that I needed to have a dynamic camera like I wanted around the player also helped adding the platforming effect and depth I was scratching my head about jamming into what working code I have. It reminded me how easy it is to put the cart before the horse when thinking ahead while working. So as much as the doors and randomizer make up a big aspect of the framework that will make this game a "game" with progression, and that is a fundimentially more important key in a finished product, the first step I ought focus on is all those blocks functioning within the camera physics and game collision physics before I stitch them into a randomizer.
tldr;
I have a puzzel maker that I wanna put interactive stickers on but soon as I got my eyes working and the puzzel spinning and I realized that also lets my game piece jump it'd be better if I make a puzzel piece variety pack with stickers that works with my eyes and my game piece, and the puzzel spinning; before I build the puzzel making machine. Beeefore I make the puzzel quilt. Fingers crossed.
Wanted to give a quick update, learned alot following the farming tutorial, enough to get the first room started and mess with playtesting.
(great tutorial series, rather advanced for my level but still really easy to follow)
So, essentially I have followed this two part tutorial series, and a working randomized room. What I need to figure out now is how to make the randomize controller place enemies and other objects about the room, like exits and chests.
I'm not totally clear how I can plug in more random spawns in the room rn, so before I have a working project get stuck between another rock and a hard place I'm going to work on the bow and arrow mechanics. If I get the particle drop on the arrows and then the inventory segments of the bow mechanics done I'll either explore the tile system again and see if I can get more items to load, if not I'll look at messing with the arrow physics. I still hope to have at least a rebound effect in the first open build, also being able to recover arrows would be very cool as well.
Not a full update, just decided to organize my tutorial references for easier access. Plus having them here means someone besides me might find the resources they need.
Making a bow and arrow in an top down view posed a large challenge then just skewing the ratio and visual illusion, mostly because I haven't seen a tutorial that is tooled to incorporate all three; top down perspective, bow with charging shots, and a projectile motion. But I can throw them in a blender and see what happens; so what I'll want to do is figure my features and what I want the end product to happen and do the simplest version. Here is what I'm thinking.
1. Inventory compatible, ought be able to switch too your bow from unequipped and switch through arrow types easily. Easy version is just an inventory, bow equipped (y/n) and are there arrows(y/n)?
2. Aim to mouse point, the arrow ought be able to be shot in full 360 degree range; that's above, below, and at the level of the player character, this means a toggled 3 layer ray casting system that works together. Easy version is just a ray coming out from the player character and if there is a target in range maybe the player "locks-on" or something.
3. Charged projectile, player should be able to "charge up" their shots, and arrows should go farther with less projectile drop or ricochet dependent on how charged the shot was.
See how these squares move about on a 2d world... and their arrows also look very 2d and make the world feel flat. I don't want that, I don't think I have to do it like that.
4. Projectile DROP
I've tested nothing with arrow drop yet, but here's a different one in case I don't like that other one.
Okay, now I have that out of my system, back to the grind.
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".
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.
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.
