Jump to content

Wijitmaker

WFG Retired
  • Posts

    9.658
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Wijitmaker

  1. Agreed. If you could make a blender version of the default humanoid then any animations make in blender would be able to be applied to the existing .dae models and vice versa - any existing animations of humanoids could be applied to new blender humanoid models.
  2. I think it shouldn't be to difficult to import a .dae into blender. I know that there is some issues getting the .dae animations into blender... but does that mean that the file doesn't open at all? Or, can it at least load up even if none of the animations work? These things I don't know. If you import a .dae head from the game, you should be able to snap him to the position of blender's head bone. We seperated the head from the body because the body uses the alpha channel in it's map for player color, while the head uses the alpha channel in it's map for random object (hair) color. The game engine can only use the alpha for one thing at a time. Anyway... Once you import a head, snap and attach it to the head bone. When you animate the head bone the imported head should follow. I'm using 3ds max terminology, but I'm sure Blender has something similar. About the boat, it isn't as difficult as you think to sync them. Just ensure that the number of animation frames in both the boat animation and the fisherman animation are the same. Also ensure that the animation speed defined in the actor file are the same. If those 2 factors are identical they should be sync'd. You should be able to work with them both in the same scene in blender. The only trick is to select what you want to export when it is time to export to .dae and then "export selected" to separate them from each other into different .dae files. At least that is how I would do it in max. Your blender rig looks pretty good, but something is going on with the hands there... perhaps the hand bones are rolled over or twisted and it is distorting the wrists? When your creating a rig, note when you import a .dae file from the game. It should come into blender with some dummy objects that are being used as nodes to define prop points. These nodes are linked to the skeleton, but are not exported with the mesh/skin so they aren't rendered in the game.
  3. I'd be happy to help, but I fear my advise would be outdated and it is 3ds max specific, not blender. The blender guys could help you I think. All the old 3d max animation, rigs, and original files are in the SVN art repository. for your questions... if you create a sword, you put it's origin at the handle of the sword. When you define what prop point the sword is attached to in the actor.xml file - the game engine will do that for you. You don't animate the sword, it simply moves with the actor's hand. for your boat and fisherman... I would create two seperate rigs. One that animates the boat. The boat would include a prop point that would be the bottom of the foot location of the fisherman. The fisherman and his movements would be his own animation that shares the same skeleton as all the rest of the humanoid characters in the game. This would allow you to perhaps use that fishing animation by a guy who isn't on a ship, and maybe on shore. There isn't anything super fancy about the skeletons.xml file. I think one of it's main purposes is to allow cross compatability of .dae files and different software packages and their unique rigs. For example, a standard named rig out of XSI software can be common with a rig out of 3ds max (biped). The heierachical bone structure between animals could be shared by the skeletons as well. For example, a goat and a deer could have the same skeleton because they would likely have the same number of bones and joints. Elephants and camels would be different because they have unique bones for things like an extra long neck or a trunk. Boat rowing skeletons could be shared across all boats. Siege units, and chariots could each be common... etc. Alas I fear I'm not explaining myself well... let me know if I can provide more guidance.
  4. Great work! Keep it up! mreiland = Michael Reiland Former Programming Leads: Raj = Raj Sharma H20 = Daniel Wilhelm Dak Lozar = Dave Loeser (tragically passed away August 2004) I sent you a PM with some old old information. Though they contributed in the early stages of the game and their contributions may have now been replaced... 0 A.D. would not be what it is today without their contributions. Edit: doh - Philip beat me
  5. While your at it fix the logo at the top of the forums too... GAMES is the wrong font http://upload.wikimedia.org/wikipedia/en/e/e2/Wildfire_Games_Logo.svg
  6. I think that would be a fantastic addition. These were features we were planning to include years ago: http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Attack http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Move#Run Trample was intended to be a "damage" aura that was going to be coupled with the stamina (run capability) of the units. Accuracy was to be a function of unit class, rank, distance, formation, etc. Philip has done some pondering on this in the past: http://www.wildfiregames.com/forum/index.php?showtopic=12669&view=findpost&p=204807 Many of these features were implemented in the pre-simulation rewrite in 2009. After the re-write I suspect they haven't been given a priority to be re-implemented. Another advanced attack features to consider are elevation bonus to the unit that takes the higher ground, also the direction of attack. Face to face combat is best case vs. an attack from behind which would cause considerable more damage.
  7. These are two interesting articles: http://wildfiregames.com/0ad/page.php?p=1587 http://wildfiregames.com/0ad/page.php?p=1594 Follow that up with this: http://www.dailymail.co.uk/sciencetech/article-1332636/DNA-tests-Chinese-villagers-green-eyes-descendants-lost-Roman-legion.html
  8. Good discussion, sorry if this has been brought up... What if the formation does not reach it's target, if it is confronted by an attack or comes to a unpassable object (wall/water/forrest), will it stay in column, or assume the designated formation?
  9. Great, glad you like them. Re-reading this topic I now realize there were two separate people making the request. Ganon, if you are out there shoot me an email and I can send them to you too.
  10. Shoot me an email, I think I can dig it up for you and reply with an attachment.
  11. If you have any specific questions, I'd be happy to answer them. WFG wasn't directly affiliated with SCNPunk, WFS was focused on modding - not scenario design. However, they "sponsored" us which allowed us to get website and forum hosting through Heaven Games. We (Tsunami, Woad Creations, etc..) were a part of the SCNPunk Network. Reverie Studios (initially lead by Micah H.) and WFS didn't really have a direct connection other than we launched into game development around the same time and had roots in AoKH. If I recall correctly Konstantin (EX-T from SCNPunk) didn't join Reverie until a few years later. I think there was a little friendly competition in the early days that encouraged both groups to make some great progress.
  12. Just payed the yearly $25 IPB renewal fee: Here is our balance as of today: $3,613.15 USD
  13. I would suggest Westood's RTS capture model. Have a GUI command to "capture" on units that are given that capability. A 3 click process: select your unit you want to capture, select the capture button from the UI, then select the building you want to capture. This starts the processes of "capturing". During which the building starts flashing/pulsing (you can do whatever you want - this is what Command and Conquer games did. You could have an audio sound with it, you could have the pulse speed up the closer it got to completion of the capture... etc.) notifying both players that a building is trying to be captured/stolen. The duration of the capture is a function of the health points (and possibly the number of units preforming a 'capture action' - though, I seem to recall only one being able to preform the command at a time). So, weaker buildings are much more vulnerable it is to being captured. Capturing can only be possible if there are no units garrisoned inside, and no enemy units that have this structure/entity in their LOS. So, if you want to take a building, kill all the units in the vicinity. A decision needs to be made if you capture a Roman barracks as a Persian, are you able to train roman soldiers? I would suggest no... Or as Michael mentioned, do something with a tech choice. If you as a player hear that someone is trying to steal your building, you need to get a unit to that building ASAP - to eliminate the capturer. Similar logic can be used for female citizens, loose domestic animals, special structures in a "capture the flag" objective game, and probably others.
  14. Wow, that is an awesome feature Philip. Oh how I would have loved to have such a feature 15 years ago back in the modem days. Who knows... I may have enjoyed playing on the internet in multiplayer games. Keep up the good work.
  15. If I recall correctly the reason was because the "box" using the skybox textures (in the standard default viewing angle) was causing the edges of the map to inherit the colors of the skybox. So what you ended up with was various shades of blue around the edges of the map, not black. Philip modified the rendering engine to only show the skybox to the be reflected through the water textures. It was an easy "fix". I believe the correct fix would be to modify all of the skybox textures so that they were black from the horizon (prefect halfway point of the texture) down, and re-implement the feature.
  16. Nice, good pic! Where did you find it? Do they have more?
  17. Yeah I noticed that. I guess what I was asking was... can you do rectangles and ovals?
  18. Looks very nice You have put a lot of thought into this. What would you suggest for an approach to non-round/square entities, such as chariots, elephants, and boats? Yes, the plan (as far as I know) is to have the ground deform when constructing most "structures" in the game. This would basically be taking the Z height of the vertexes in the grid that are under the structure's envelop and averaging them.
  19. If you can export .dae files from Maya (and I'm pretty sure you can), you most certainly could use Maya. Setting up a bone/skeleton structure in Maya and replicating it in the skeleton.xml file is certainly doable. I would recommend some simple rigs to test an export and animation before you invest to much time, but I'm pretty sure any bugs could be worked out.
  20. Hey Malte, glad to hear things are going well with you. It's always neat to hear about current stories of past members. Perhaps 0 A.D. made a small contribution in your education and career development. That was always one of my main intents Can you tell us what your doing at Google?
  21. To further automate you could also waypoint the citizens to automatically rally at a specific building. If you want to focus in the early part of the game on food, move them to the farm center. If you need more lumber, move it to the mill. If you are ready to create some military, move it to the barracks. If you aren't sure yet what you want, just move it to a patch of ground near the town center. A commoner is good, I like that. In the game you wouldn't have to identify them as a commoner, citizen or a slave, you could just call them a roman, carthaginian, etc. Few more things to consider. Would advanced (in your model - units that were trained), elite (units that gain greater stats through experience) soldiers still have an economic purpose? Right now they do, just not as efficient as a basic citizen soldier (freshly created unit). I believe they should, as a fall back option. Or could a unit have multiple training - both military and economic? Would a generic commoner have any economic or military capability without any training? If the training wasn't done at a structure, and instead done by clicking on a single unit then doing the "training/upgrade" specialization from there - it would be a similar idea to Westwood Command and Conquer RTS games and later the same studio that EA bought and made Battle for Middle Earth. Basically your applying a tech through means of garrisoning a unit in a structure for a period of time.
  22. I agree, not all civilizations represented in the game had such larger percentage of their population as slaves, such as the Romans and Persians. That was one reason why we chose to use the word citizen instead of slaves. So, I'll call them citizens. It could almost be implemented entirely with modifying lots of xml files. One might need some help setting up the auto generation of citizens. Also there is some logic needed to 'transform' entities when 'trained' in structures. Perhaps some GUI elements as well. It wouldn't be simple, but it wouldn't to laborious I think. I think the biggest hurdle one will have is convincing the team that it is a good idea, when in doubt the team tends to do things like the Age of Empires because that is mainly the audience that will be playing this game. It can be done though. I would suggest making a clear and objective list of pros and cons. Also create a little mini document that details all the effects this would have on the game inside and out. How would food effect technologies? How is food collected? What would the interface of the UI look like to train the citizens? What structures would it require and what actions would each structure take? How does it (or does it at all) fit in with game design elements like auras, citizen soldiers, trading, building structures, promotions, heroes... etc (see here: http://trac.wildfiregames.com/wiki/Design_Document & http://trac.wildfiregames.com/wiki/XML.Entity - Note not all documents are up to date with the changes the team has made in the last several years - I'm sure they will correct you as you go). The output of this effort would give the team a good picture of what the risk/rewards of doing a system like this is and give them the ability to estimate workload for such a task. Good luck
  23. That is a really neat idea! Very interesting and fits well with the citizen soldier concept. You could arm the basic citizen solder with a pitchfork and rocks or something if ever attacked (making them primarily a econ unit. Rather than battle experience to make the jump from basic to advanced, you could do just as you suggest. Make them pay for training at a barracks by "garrisoning" the unit there. Advancement from advanced to elite would be through experience still. Off the top of my head, the main gripe I could think of is that it would be a little tedious to micromanage. A game designer needs to consider what they want players to spend their time/clicks doing. Do you want players to spend their time tasking their slaves/citizens to a barracks to "train" or would you want them to spend more time engaging in other activities like battle tactics? I like the idea of specialist citizens. It offers the players choices on how to manage their economy and adds strategy and depth. I'm not sure it would be a good idea to have citizens/slaves to always appear automatically at a constant rate. Perhaps have a system similar to civilization. The rate at which food is collected would be linked to the rate your population would increase. Food would perhaps have to then be generated from resources that provide a constant regenerative source of food (farms, corrals, fishing). Though bumps in the rate might occur with hunting. Or, maybe food could solely be used to "generate" citizens/slaves. Perhaps every increment of 100 units of food collected, you automatically get a new citizen/slave (until you hit a cap - necessary for system requirements). Although... how would you "buy" a horse, camel, elephant. Maybe you could queue it and instead of 100 food automatically going to a human, it would instead use the next 200 food (for example) to purchase a horse that would be available for someone to train with at your barracks? Neat idea, just doing some brainstorming
  24. Celts are supposed to be weak in siege (though have a sufficiently strong turf wall - Julius liked them so much he started using them)
×
×
  • Create New...