Azaral

Member
  • Content count

    70
  • Joined

  • Last visited

Community Reputation

467 Neutral

About Azaral

  • Rank
    Member
  1. Introduction Now that you understand the technical aspects of blacksmithing, I'll bring up ways that it could apply to a game you might be designing. This article talks about the tools of the blacksmith. The next part will talk about the actual crafting process. Current Blacksmithing Implementations First, let's talk about how it is currently done. It Sucks Crafting in general in most games is a bore. It's uninteresting and bland. It requires no skill whatsoever. A lot of RPG's, especially MMORPG's and games like Skyrim, are missing out on a HUGE aspect that they could expand. Some of the reason is understandable because of limitations of the development team and what not, but I think part of it might be because of unimaginitive designers who only have a vague idea about what really goes on. I'll freely admit that making a blacksmithing system, let alone all of the crafting that can be done in a game, that mirrors reality with all the trimmings would drastically change the core of a lot that goes on in the game. Not only on the developer side, but on the player side too. It would involve a lot of variables that typically aren't dealt with. One of them would be item quality, and not in the typical manner. If you get a long sword, it is just like all other long swords. In reality though, a long sword could be very different from another long sword. It could be made from a different alloy of steel so it would behave differently. If it were made from a softer steel, it would dull faster. If it were heat treated improperly, then it would be too brittle and break easier, it would be too soft and dull faster, or it could have an internal defect that could cause it to break under pressure. Whether or not these things are desireable in combat (I think it would be very interesting if the fighting mechanics were to fit it, and a game like Skyrim has it) is another matter, and one outside the scope of the article. Crafting As Currently Done Crafting right now is based on character skill, not player skill. The only thing the player has to do is gather x,y,z, stand at tool a, and press "Create", and the item is created, with few exceptions. I played Everquest 2 breifly when it was first launched and tried my hand at blacksmithing. It was more than just pressing a button, but barely so. It was nothing more than whack a mole. They presented you with x problem and you would use anti-x crafting ability. The better you were at this, the better the item produced, coupled with the awful state of character skills not tied to fighting. That is the only game I've seen try to do it differently. But it could be so... much... more. One Detailed Example of How It Could Be There are many possibilities of how it could be done, but I'll present one that has been toying in my mind for a while. A game that is like Skyrim will be the setting, where combat is more than pressing hotkeys, like some games who's abbreviation contains two w's and an o in between. Setting the stage The player has access to a blacksmith's shop. Either it is their own or they are using it on a rent or loan basis. Doesn't matter. This system I will be detailing will incorporate both the in game character ability as well as the actual player's knowledge and skill. This might be breaking a game design cardinal rule, which is don't require the player to be required to use outside knowledge to solve an in game problem, but for the sake of the article let's ignore that for now. There could be many solutions to that problem (apprenticeships come to mind. One player who know's what's going on would be teaching another player the ropes, you know, how it works in real life). The Shop The place where the player performs his trade. What would it need? The five basic tools of any blacksmith is a start! So we need a forge, an anvil, a hammer, a pair of tongs, and something to forge. The Forge The forge is used to heat the smith's work. In a medeival fantasy setting, gas forges are out (or are they?) as well as magnetic induction forges (or are they?). This means solid fuel, coal and charcoal. But wait a second, its fantasy. Oh yeah, one advantage fantasy has over real life is magic. This brings back the possibility of a gas forge and a magnetic induction forge, just powered by magic instead of science. The solid fuel forge isn't exempt from this either. But let's explore a regular non-magic forge for a second here and see what it entails. A forge needs two things to do its' job, fuel and LOTS of air (more specifically oxygen). This means you need something to burn and something to push lots of air into the fire. Fuel would be wood, charcoal, or coal. Air would be suppplied through a bellows. The fuel would get used up over time and would require the player to add more to the fire to keep it going. The rate of fuel consumption would be directly tied to how much air they are pushing into the fire, which is tied to how hot they want the fire to be. So, the hotter they fire, the more fuel they burn up. Different fuels also produce more heat per unit weight than others. Of the three, coal produces the most heat. This introduces a lot of variables that would fit nicely into a function that would govern the rate of consumption. Even more than that, there is an anatomy to a forge fire. There is a place called the heart of the fire where it is hottest. There are also different types of fires depending on how much oxygen is available: oxidizing fire, the hottest but also the highest in oxygen, a neutral fire where there is a relative balance of oxygen and fuel, and a carburizing fire, where there is not enough oxygen for a complete burn and so you have instead of something like CO2 being produced as a by product, you have CO. However, each of these do different things to the metal. An oxidizing fire, while hot, will strip the steel of carbon, literally burning it out, as well as producing excess iron oxide scale (the black stuff that comes off metal when it is heated to high temperatures). A neutral flame doesn't do much. A carburizing flame can actually put some carbon into the steel. Here you have a lot of things that would be falling into the player's control and introduce a lot of player skill into the crafting. They would have to put the metal into the heart of the fire for maximum heat, but put it in the desired portion of the fire for what they are trying to do. This could be a matter of aiming the bar into the fire, then clicking the mouse to start sticking it in. The longer it is held, the more it is put in. If they put the whole bar in, then they would start to remove it and vice versa. If they let go of the mouse button while the steel is in the fire, then they would let go of the piece of steel in the game, placing the steel in the fire. If they let go while it is out of the fire, then they would remain hold of it. The player would then wait until they decide to grab the steal back out. Did they leave it in long enough? Did they leave it in longer than they should have? This is nothing but math really. A specific heat value, that is how much energy it takes to raise 1 gram of material 1 degree Celsius. This could be anything the developers want, but if you're going to use steel it would help if real values, or something close, were used for it. It would just be a matter of applying this heat to the metal and coloring the texture appropriately (color is all they had to go off of really). In order to accomplish this, a method of determining the heat throughout the piece would be needed as well as coloring the pixels of the work piece. Setting up some sort of internal temperature mesh that iterates the temperature at each 'vertex' could work. Anything done in between them would just take the average between all vertices next to the point. While the piece is in the steel, the player is going to have to pump those bellows. This would bring into some character skill, namely fatigue. The most important thing for a blacksmith is endurance. You're going to be hitting that piece of steel thousands of times, literally. You will be pumping that bellows hundreds of times. That tires you out. Being fatigued could influence other actions in the smithing process, like swinging the hammer. Trust me, when you get tired, swining a hammer becomes a major chore, namely striking where you want. You get tired, you get lazy, and you get shaky. As for the application of magic, the possibilities are only limited by imagination. It would also open up whole new economies in the game. You could have a special magic coal that burns for longer before it is consumed. You could utlize the blood of the big red dragon you killed that when exposed to air for more than a few moments begins to burn very hot and very long. You could capture the essence of an air elemental and bottle it and tap into it to be the blower for your forge, letting your fire burn hotter without you haveing to pump some bellows. It could also be required to use the essence of air elemental in order to keep that dragon's blood on fire. You might need that dragon's blood fire to be able to get your magic steel hot enough to forge. The Hammer The hammer is the iconic tool of the blacksmith. It is the avatar of his will and he uses it to make the work piece bend to his desires. Hammers are defined by three key attributes: their weight, their peen, and the material they are made of. Their weight affects how much of an impact each strike will have, as well as how strong you have to be to swing it effectively and how long you can swing it for. The shape imparts itself negatively on the work piece. If you have a ball peen, you are going to be putting dimples into the piece. If you have a hammer with a concave peen, you are going to be putting spheres on the work piece. The material affects the hammer's durability and ability to impart it's force into the work piece. If your hammer is too soft, the work piece is going to be putting it's shape on the hammer instead of the other way around. This gives use some attributes to mess around with. The hammer's weight would effect speed of working by multiplying the force of the strike the player puts into a swing. The force of a strike could be controlled by holding the mouse button down for a lenght of time or by moving the mouse down at varying speeds while holding the mouse button down. The force of the blow would be a combination of character strength, player choice of swing strength, and hammer weight. The heavier the hammer, the more fatigue would be accrued with each blow. The more fatigued the character is, the less accurate they would be with their strikes. The less accurate they are with their strikes, the poorer their work will be. The peen would obviously be what determines, along with the force, what happens to the piece. It would simply move the vertices of the work piece's mesh so they are inline with the face of the hammer. The force of the strike, along with the current malleability of the hammer would determine just how much of an imprint would be left. In actuallity, it would be creating new planes in the work piece that are all parallel with the planes of the hammer face. The more force in the strike and the more malleable the piece is at the tiem of striking would determine just how far the hammer would 'dig into' the material. Magical applications abound. You could have a hammer that multiplies force or decreases fatigue. You could have materials that are harder and more able to beat on harder work materials. You could have magical hammers be a requirement for working certain materials. The Anvil The anvil is just another hammer, just much bigger and stationary. It also has things on it like a hardy hole which can be used to place hardy tools in. It has a horn which is used for doing round parts and bending. An anvil has two important properties, weight and material. A good weighty anvil will be steady when you strike it. A good hard anvil will keep the work from imparting it's mark onto the anvil. As the force of blows increase and the hardness of the material increased, so too must the weight and hardness of an anvil. An anvil that is too light to take the force of blows will bounce around making work more difficult. An anvil that is too soft will get marked and marred which will mark and mar the work pieces placed on it and hammered. A lot of what applies to a better hammer applies to the anvil as well. The Tongs Tongs are pretty simple items. They have different shapes and different sizes meant to be held in them. And that isn't a lot of tongs. Smiths that do a lot of work can have 30 or more tongs. This I think is one area where some abstraction would do good. Have maybe a few tongs or just have tongs differ by material. The tongs need to be able to deal with the heat of the metal without becoming weak themselves and bending form being used. They need to be sturdy so the smith can have a sturdy grip on the work. Maybe you could force the player to use the right tongs for the job as far as shape and size goes. It would really only matter when they go to pull something out of the fire and when struck. The more incorrect the more the piece would move when struck, if they could even hold it at all. And for the last item.. Work Material This one opens up WHOLE new bag. As you learned in part one, there are literally thousands of different alloys. Obviously, this would either A have to be severly limited or B the developers would need to come up with a procedural and forumlaic way of determining the attributes of the total material based on its component elements (which is the way I would favor, way more possibilities and really not THAT much more work, especially if you have nothing but fantasy materials). The material would be a key figure in the piece. It would be chosen because of the properties need by the final product. The materail would also determine how it needs to be worked in order to be successfully manipulated into the final product. The material could impart magical properties into the final product. Got some fire steel, well lets use that to make a flaming sword of firey doom. That alone would require it's own things to work properly. Forging that bar of adamantium for an ultra hard blade? Going to need a fire that gets hot and tools made of materials that can handle that! The material would dictate everything about the process and what is required to do it properly. Conclusion Just from this there are new possibilities for the game already coming forth. New economies would be created in trading with the smiths of the world by expanding the thing they need to do their craft. Special fuels would be needed for special materials. There would be materials needing harvested and refined by other players. It would really open up the economic possibilities of the game. This part of the series shows how much of an impact of fleshing out blacksmithing could have on the process. I've hinted at how the actual forging process would work. The next part will delve into the forging process in both a player perspective and a programming perspective.
  2. c++ function pointers

    I must prefer functors. Don't have to deal with any extra weird syntax. Plus, they can store data.
  3. Game Heirarchy

    I would create a header file with a namespace like Tools or something. Inside this namespace I would have the collision functions. I would also have another set of headers that define the collidable types, IE AABB, a circle, etc. I would have these have NO default constructor to force their initialization upon instantiation. I would also have as much data possible in the collidable type be pointers to the relevant data. For example, an AABB would have pointers for the position that point to the position of the entity it is for. Then if possible have the width and height be pointers as well, but they would probably just be non-pointers. I would define a function for each type of collision possible. For example, I would have three functions, one for AABB vs AABB, one for Circle for Circle, and one for Circle vs AABB. They would all be overloads of HasCollided (or in your case, isCollided). Then when I run collision detection, I just take the collidable data from each object and the correct function will be ran. It would require minimal code at the front end of it, just a simple function call. The collidable data should also not be inherited but be part of the regular data for the object. By having as much as possible in the collideable data be pointers, they will automatically have the current values without needing to be updated manually. You could end up with a lot of collision functions to define and that can be alliviated somewhat by more involved programming, but this I think is the simplest way to do it and it is quite effective. For handling collisions, this could be another piece of collision data, which I would also have separate from the collision detection data. Then you would have the same function overload process for how to handle all the different collision types. With this you would call HasCollided( a.GetCollisionDetectionData(), b.GetCollisionDetectionData() ); and if that is true then run HandleCollision( a.GetCollisionData(), b.GetCollisionData() ); I apologize in advance if this doesn't make any sense and I sound like I'm rambling. One too many beers and it's bedtime as well lol.
  4. Game Heirarchy

      Ideally, a class knows nothing of another class. Two classes should interact via an interface class or some other means. Instead of having the player call a function from collision to determine if it is colliding with the wall, have a function that takes the player and the wall as arguments to determine if the player is colliding with the wall (and expand this for all the things that can collide). This way, player doesn't need to know anything about collisions or walls, player just needs to know about player and wall just needs to know about wall.
  5. Why C++?

    http://www.youtube.com/watch?v=sRn9lhkVaxw
  6. Physically Based Shading For Artists

    Interesting stuff.   Combining this with your other video on ditching diffuse maps could yield some startling visual effect I think. If only I knew more about shader programming (I've done precisely zero).
  7.   You are correct that users have no right to mod a game, they also have no right to not mod a game. They can either do it or they cannot do it. They couldn't sell it or distribute it legally without permission from the copywright holders of the software that they based their mod on (as far as I understand). This does not stop them from doing it for themselves. Modding could possibly be in the form of creating/performing a cheat. In the context of the discussion, it is cheating. What I am saying is that in a strictly single player game, where what one player does in their game has NO bearing whatsoever on a player playing their copy of the game, cheating is irrelevant and you are wasting your time trying to prevent it. The only one you are satisfying with your attempts to prevent cheating is yourself.   The idea of creating a game is to make something that someone will have fun with. I fail to see the problem of players altering a game so that they enjoy it more is a bad thing, and such alterations have zero affect on the other players of said game. I see it as a good thing. Are they altering the experience I planned for them? Yes. Is this bad? No.   You are trying to give a ball to a group of kids so they can play basketball, but get upset when they decide to kick it around and play soccer instead so you run out and say "No! You must play the game I want you to play, basketball!". I give them a ball with the intent for them to play basketball, and when they start playing soccer I would be estatic because they are having fun with something I gave them. My point with all this is to save you time by having you not worry about something in your design I think you should not worry about and to help you create a game that will be more fun for people. I think you have placed your game/idea on a pedestal and think it a kind of personal insult to yourself and your creative idea for anyone to not interact with it in the way you want them to.
  8. OR they fail and fail and fail and since they can't do anything but start over or give up, they give up and call your game crap out of frustration. Actually, 'fail and fail and fail' won't really be possible in my games, neither will checkpoints nor cancelling autosave be possible. You fail, you face the consequence, move on and . . . There'll be different things in my games and if isn't implemented before i start making my games, it'll be new things. One more thing, shouldn't the player play within the developers programming? If not, i would have loved to keep going straight in the gtavc but unfortunately, you get magically turned around in the water. Should you let them implement what you didn't program into a game? What if what they implement your idea for a sequel? I'm just asking.     If they want to change the game that they bought from the original, I don't care (speaking of strictly single player games). They are increasing their fun. Sure, I put out a game and I intended it to be played a certain way, but if they change it to make it more enjoyable for themselves then who am I to deny them that?  That would be like deriding anyone who ever writes any fan fiction. They are taking something you made and making it more enjoyable for themselves. You are treating the player as an adversary instead of a partner. As far as implementing my idea for a sequel, they are more than welcome to do that. However, their version of a sequel could be vastly different than my idea of a sequel, and if I the, the original creator of said universe, denounced it, then I doubt anyone would put any credence to it. It could even be spun off as a sort of split in the timeline. It would force me to do a better job. It would be like if someone made a Mass Effect 3 that doesn't have a balls ending that turns the entire series to poo soup. Also, see fan fiction example above.
  9.   [b]OR[/b] they fail and fail and fail and since they can't do anything but start over or give up, they give up and call your game crap out of frustration.
  10. caveman rpg - should snow put out your fire?

      Fixed.  Also varies depending on the type of snow: dusty and dry snow vs more moist snow.     LOL yeah
  11. caveman rpg - should snow put out your fire?

    10 inch of snow = 1 inches of rain. There is far less water in snow than there is in rain. Unless you have a ridiculous amount of snow happening, no. You have to figure that the rate of snow would have to be greater than the rate at which the fire can melt and then boil the snow, and given the small amount of water in each snow flake that rate is pretty fast.   edited for snow to rain correction
  12. I think the more pertenent question, from a game design standpoint, would be if it is a signle player game, then why care? You are only being evil towards the player. It should be an option, not a requirement. The player is not your enemy, they are your friend. If they want to cheat, then so what. The only person it affects is themselves. Save yourself the trouble and time and just simply don't worry about it. That's my opinion at least
  13. SFML 2.1

    I use SFML 2.1 and I think it is fantastic. I use all parts of it and have not had any issues thus far.
  14. Overview? for game I am making.

    Sharing. Wasn't quite sure what to call it, hence the Overview? part.