Leaderboard
Popular Content
Showing content with the highest reputation on 2015-03-28 in all areas
-
Something like that would work. Instant ownership change like sheep would be easiest. Would be really interesting for traders; you'd have to have units patroling to keep ownership. I don't see that as an issue for blacksmiths. Just allow research of all the techs that your civ has (the blacksmith ones are surprisingly universal among our civs). Or we could just make them turn into your civ's version of that structure but just keep the original civ's graphics. Special buildings probably would have no real purpose to your civ though though. I think siege weapons should just damage buildings though. As mentioned, a damaged structure could be made easier to capture.2 points
-
I see Yes, most of the roman textures have this already. I can't find the file that Enrique baked from though (I would like to take a look), since there are way to many files to just go around blindly. (b.t.w the texture is up-side-down on this rounded part: Celts seems to have some. But the structures doesn't really fit well with a normal map. I guess I'm not sure what I should be modeling. Adding another animal probably won't really take the graphics to the next level.2 points
-
Some thoughts about capturing Units should be able to actively capture enemy buildings. Instead of the attack they now do. I propose the following game mechanics, these should work for games with or without teams, and even with asymmetric alliances. Capturable component Capturable buildings have a capturable component, similar to health. By default, all buildings start with a number of capture points, assigned to the owner. For example, a fortress belonging to player 1, starts with 5000 capture points for player 1, and none for the other players (in the example there are 3 players) Cp: [5000, 0, 0] When player 2 wants to capture the building, he tasks units to capture it (equal to the attack command, as buildings shouldn't be attackable by units). Bit per bit, the capture points are shifted towards the second player Cp: [5000, 0, 0] > [4000, 1000, 0] > [3000, 2000, 0] > [2000, 3000, 0] > ... Now say player 1 stops player 2 from completing the capture (f.e. by killing all units that are capturing) before the capture is completed, then the capture points distribution stops changing. There are some different scenarios that can happen now. If player 3 comes along, and also tries to capture the building. Say player 2 and 3 aren't allies, then player 3 takes capture points proportionally to the existing distribution. Cp: [2000, 3000, 0] > [1600, 2400, 1000] > [1200, 1800, 2000] > [800, 1200, 3000] > [400, 600, 4000] > [0, 0, 5000] When all capture of the owner reach 0, player 3 owns the building. On the other hand, if player 2 and 3 were allied, then player 3 would only take capture points from player 1 like this Cp: [2000, 3000, 0] > [1000, 3000, 1000] > [0, 3000, 2000] At that point, the owner has no capture points left, and thus loses the building. The owner should lose the building to who did most work to capture it, in this case, the building gets owned by player 2. Selecting on who did the latest capture operation isn't opportune, as captures can happen simultaneously, so the exact switch point can be rather arbitrary. The owner could also chose to re-win capture points even if the building wasn't completely captured. This is done in the same way as just capturing other buildings. Cp: [2000, 3000, 0] > [3000, 2000, 0] > [4000, 1000, 0] > [5000, 0, 0] Note: I didn't consider Gaia in this context, Gaia buildings are possible, and players should be able to capture from Gaia, so Gaia should simply be player 0 here Statistics Some sort of armour (like in the attack) isn't needed. There's only one way to capture a building, so there's no need to balance the difference with different armour stats. On the other hand, the units will need a separate capture attack, with all details a normal attack has (repeat time, amount of capture points, ...). Effect of garrisoning on capturing Garrisoning should probably help defending the building. I think each garrisoned unit should act like it's constantly re-winning capture points for that building. Keeping siege engines useful Of course, capturing is all neat, but there must be a way to keep siege engines useful. Here I see two possible possibilities. But are based on the principle that siege engines harm the building in a way that makes it easier to capture. For the first possibility, siege engines attack like normal, reducing the health of the building. But the health of the building also relates to how vulnerable it is for captures. F.e. if the building is only at half the health, it becomes double as easy to capture the building. This takes the "harming makes it easier to capture" thing pretty much literally. However, it might make the UI more difficult (having health and capture points for buildings), and it might also make it more difficult to understand and balance. A different result would be that players can capture each others buildings more frequently. If one player damages the building to capture it, it will stay damaged for until the reparation, making it easier for a different player to capture it again. Thus this could result in a more vivid gameplay. For the second possibility, siege engines don't attack to demolish, but instead have very strong capture stats. This could fully eliminate the need of a health component for buildings. It could make the UI cleaner and easier to understand, which also means easier to balance. It could also make translations easier (translating health is really hard when it counts for buildings too IMO). The drawback is that it would probably break the AI harder than the other possibility. As the AI wouldn't be able to check health of buildings anymore. However, such a major gameplay change is expected to need AI modifications anyway. With the second choice however, when re-winning capture points of your own buildings, it would look silly to use siege engines for that (like you're demolishing your own building). So it should be possible to limit siege engines from capturing on buildings you own, and there should probably also be possible to give a bonus to other units, so the lack of siege usage can be compensated. Keeping captured buildings useful Captured buildings should stay useful to some degree, however, they shouldn't allow you to virtually switch civilisations (like getting the sudden ability to reconstruct the entire enemy civ from one captured building). So I propose the following: Buildings should still be able to produce all units they can produce. This reflects that different civilisations often used concurred civilisations in their own army, and of course, concurred people would work for the concurror. A possible exception to this are the heroes. Heroes should probably stick with the right civ. Although there are also stories of heroes who changed alliances.Units should only be able to build buildings from their own civilisation. So if you create a soldier from a captured CC, you won't be able to use that soldier to build a fortress of the enemy.Technologies on captured buildings should be completely disabled. First of all this avoids technical problems where different techs are used for the same purpose (f.e. the Athenian civ has a special town phase tech, and you shouldn't be able to research the town phase twice). But it also reflects the history that many civs stopped developing new technologies when they were concurred. The drawback is that this makes the blacksmith useless as captured building, but that's only a very small issue IMO.All the other things (attack, population bonus, the ability to drop resources, ...) should transfer directly to the new owners.Destroying buildings Destroying buildings should still be possible (f.e. you reached the tower limit, and you want to build more towers towards the enemy). However, it shouldn't be possible to destroy a building right before it's captured. So I propose only if the owner of the building also holds the majority of capture points, he would be able to destroy the building GUI For the GUI, I see it similar to the health bar, but instead of using a green-red bar, the bar should be divided in a number of parts, showing the playercolour partitions instead. As the numbers are also important, they should be showed too in some way, however, I'm not sure if all numbers are needed. It might be enough to show the capture points you have on the building, and which player has the most capture points on the building (so which player will be the next owner if the owner is defeated). That makes it easier than showing an array that can possibly be 9 numbers long, while it still gives you enough information to play the game I think. So, tell me what you think of it, I'm wondering if you consider this a good concept or not.2 points
-
Ok I found this review sometime ago. ------- http://blog.en.uptodown.com/0-d-free-spiritual-successor-age-empires-saga/ Youve surely seen it in one of the many top-games lists or collections of best freeware games for Windows but as its free you probably didnt give it a shot, thinking it would be second-rate. So naive! 0 A.D. is, by all accounts, exactly everything you could ever ask for from a new installment of the Age of Empires saga: a real-time strategy game with a historical setting and a deep development system for your cities thats constantly being expanded and is now available for Windows, Mac, and Linux. Once upon a time, the game was going to be a mod to Age of Empires II: The Age of Kings, but the project was gradually expanded and since the year 2001 has been undergoing transformation to the point that, eight years later, it was officially announced that it would be developed as a completely freestanding and open-source game. Wildfire Games is made up today of nearly 50 fans who donate their time to develop the game. In 2013 they tried to finance the project with a crowdfunding campaign, but didnt have much success. Nevertheless, they forged ahead with development of an alpha version. That said, the advanced state of this game doesnt make it look too much like an alpha. Dont be fooled by the fact that the game isnt finished. 0 A.D. contains an enormous amount of content. It includes 12 different factions in the form of iconic historical civilizations, including Celts, Spartans, Persians, Romans, and Athenians, each with its own aesthetic for units and buildings as well as strengths and weaknesses. Its precisely in the buildings that you can see the might of the progress system. Each civilization has 20 different constructions, each with its own function in powering the collection of primary materials, population growth, or military development. With nearly 15 years of development, the games level of detail verges on sickening. To give an example, if you decide to hide a unit within a building, it wont disappear as if it were inside, but rather youll see soldiers hanging out on the roof or walls. The fauna that populate the game will change in accordance with your geography and flourish depending on the resources available, meaning itll be normal to see a pair of elephants playing along a riverbank or a herd of antelope wandering on an empty steppe. The expansion of your cities is totally customizable. There are no geographical or structural limits, so you can place any building or wall anywhere that its physically possible to set it. The enormous number of collection systems will make it so your city residents can hunt wild animals, cultivate plots of land, care for farm animals, cut wood, or extract minerals from quarries. Although it doesnt have an official campaign, you can set up a match with battles between up to eight civilizations in more than 20 settings, where youll have the option to play against either the computer or other users via LAN, or online through game rooms that you can either join or create yourself. You can also customize the battle by selecting a condition of victory, which could be simple and straightforward domination on the battlefield to a race to see which civilization can technologically develop first. But the battle mode is not the only game mode, as you can also participate in preset scenes to take part in famous battles between certain civilizations and with predetermined objectives. As if that werent enough, the game also includes a complete scene editor to create your own campaigns, and in fact, a bit of browsing online will reveal many mods created by the community.1 point
-
1 point
-
The heightmap used in the engine is the alpha layer of the normalmap. You may be able to get it using gimp or photoshop. For the roof problem you may try using three quads instead of two (for each tile column) to make it more rounded and less pointy to the eyes.1 point
-
Ok, then I'll go with that scenario If you have a proposal for an influence (preferably expresses as mathematical formula), that's welcome. But I think that inverse proportional isn't too bad. 50% damage will make it a lot faster to capture, but the damage gets transferred to the new owner. And as repairing takes a long time, the players who first damage their buildings a lot before capturing will also be more vulnerable for a counter-capture. So instead of two choices: capture or destroy, you'll have a complete spectrum of choices.1 point
-
I'm in favor of the 1st option regarding to siege engines, siege engines shouldn't become capture engines. I think that the attacking player should still be able to destroy the building (which should also go faster than capturing it, otherwise destroying a building would be completely useless) Also damaging a building shouldn't affect the capture-rate of that building so much (given your example of a building at half health makes the capturing go twice as fast as a full health building) (since you would damage the building first and quickly capture it afterwards) Some influence would be logic and realistic though IMHO.1 point
-
Hey Micket did you enable manually the advanced graphics options by setting material quality in the user.cfg ? Otherwise you wont see normals(parrallax) in game. Actually according to Enrique rome is one of the civ which has a good bump.... The celt though...doesn't Enrique submitted the file he used to bake the bump in the art source.1 point
-
In the Aristeia mod, the New Kingdom Egyptian civilisation currently presents the player with a choice when choosing the city-phase tech - to go with a Theban or a Ramesside city phase. Although not reflected fully in art yet, the two choices provide different heroes, champion units and selection of city-phase structures. My point being, the idea is not entirely lost.1 point
-
1 point
-
Fun fact 10 years ago 0 A.D. originally had only these civs: Celts Hellenes Iberians Romans Persians Carthaginians Two of the civs "branched" into sub-civs (celts - britons, gauls & hellens - sparta & athens). But, this was intended to happen during the game as a strategic choice - not something you decide and set in stone before the game even started. The choice would have shown itself during one of the town/city upgrade phases, and would have affected the hero choices, special structures, and late game technologies. I'm not saying the existing method is bad, just that I personally like the concept better (more strategy, easier to balance) than having dozens of civs that are slightly different from each other to choose from at the start. But... it is no longer my decision to make and hasn't been for years. I'm just throwing the idea back on the table1 point
-
I wasn't thinking obstruction based on height, but rather based on structures/buildings. I don't think there's any building shorter than a unit, except farms1 point
-
1 point
-
1 point
-
1 point
-
Yeah I know what you mean. I don't usually triangulate until I export it to the game in case there is the need to change anything in the mesh. Running anim:1 point
-
Skin wobbling around would be excessive IMO, there needs to be a bone for each part that we want skin wobbly parts and I think there's no need for such detail in a RTS. I've added more weight to the head, animated the mouth, flapping ears (not too much since they don't have inner geometry), and fixed the tail movement. There's some stretching in the lower part of the chest that I couldn't get rid of due to the mesh topology, but it shouldn't be a problem from the game's camera perspective.1 point
-
1 point
-
Realistically, shouldn't they rape them first? Just kidding, that shouldn't be in a game. The kids might learn bad manners...1 point