Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2018-07-07 in all areas

  1. I like your mod idea very much. Since you consider an Amazon map and a big number of factions, I would suggest to consider representing some of the Amazonian peoples (that would be not only nice but also new to RTS games), such as the Marajoara and Tupis. Despite there being around 5 million people living there when the Portuguese arrived these nations are largely unknown by most people - and there is a very prevalent myth that the Amazon forest was a pristine uninhabited place. This couldn't be farther from the truth. In fact, the very forest according to recent findings seems to be largely "man-made". Some of these evidence like the large geoglyphs were only found recently due to recent deforestation of Amazon for large scale agriculture. https://en.wikipedia.org/wiki/Amazon_rainforest#Human_activity Of course this is just a suggestion, but it would be nice for historical reasons and techniques such as "forest gardening" could be interesting gameplay inovations. PS: I offer my help with reference material, testing of the mod and whatever else my skills and time permit. PS2: I just saw that you mentioned the Tupis among the civs in some comment in another post, so my suggestion is not even that novel.
    2 points
  2. 2 points
  3. I spent last 2 of my evening on the implementing of the addition light system in the pyrogenesis to find implementing bottlenecks for new objects. And I found some places, but that's not the topic. How additional lighting system looks: Fully dynamic lighting. And all light sources can be attached as props (i.e. to bones): "May the Light be with you..." But what restrictions do we have? We have 2 main: The lights can't throw shadows, because performance (we can implement it, but only few powerful videocards can handle it). There can't be many light sources in one place (at least for low videocards and since we don't support deferred rendering). Because shaders have own restrictions, particularly uniform sizes. But probably it's not the real problem. So I have a question: do we need additional light sources in near releases? Would it be real useful? P.S. I found strange normal values for some model, it should be investigated (probably the shader problem).
    1 point
  4. hi, I was wondering how it could be possible if I can make predators hunt other animals, in the scenario editor when I place down a predator and a prey animal, the predator does not attack and kill the prey animal, any way I can accomplish predator prey interaction?
    1 point
  5. Implementation Having gathered enough design constraints, the implementing of the sketch is started. It will be easier to implement the sketch and derive new design goals and inspire new ideas from the implementation rather than to try to imagine something great and predict all possible complications that weren't thought. Step 1: Player positions, main streams Step 2: Confluences of the stream, city area, main road Step 3: Civic Center with a little stream or ditch around it. The central attractor and eyecandy of the city is the purple area and will become some kind of marketplace. Step 4: The oppidum receives a set of walls. There are paths (yellow) around the walls to make it more rich than Jebel Barkal. Step 5: A ditch around the walls makes this a lot more attractive. Paths from the CC to the gates of the fortification invoke an initial city structure.
    1 point
  6. Map Idea The next step was to generalize some of the design properties worked out in the sketch analysis and apply them to a new map in a different context. One of the problems of Jebel Barkal is that the central area is occupied by the city, one can only use the lower 35% of the map effectively. So this time I thought to put the city on the left side. To be able to use a greater part of the map for player purposes, the players are located on opposing ends, rather than confined to one half of the map. The Irrigation canals on Jebel Barkal made it not only easy to wall off, but also prolonged the distances to travel between players, and split the map into compartments. That can be maintained and defended independent of each other. On maps without natural barriers, map control is often total. So on this map we could have these compartments again by adding streams and confluences of the streams. To distribute the gaia attackers more evenly on the players, I don't align playerbases in a linear but an alternating pattern. There must also be shallows so that the scripted opponent can reach the enemies at the back. Due to the design trait to be able to wall off compartments of the map near confluences, it would be likely that gaia is walled out from the middle strip of the map. So there must be a safe path for the scripted opponent / gaia in the middle of the map, horizontally. Legend: Black: player locations Purple: scripted opponent city Light blue: Streams / water Green: Safe economy, trade Blue: shallows, direction of playerbase expansion Red: Places of frequent fights
    1 point
  7. 1 point
  8. Can you make this a separate patch ? The best way, would be a simulation triggerable version of it But a map specific one is fine too.
    1 point
  9. Currently I'm trying to add features that popular in modern engines and liked by players to find different implementation bottlenecks in our code. Yes, I mentioned, that it doesn't support many lights per model. Usually video card can support from 8 to 128 lights per model. It uses simple uniform structs (even not UBO). // 8 floats per struct. struct PointLight { vec3 position; float radius; // vec2 - compressed 4 components, instead of unsupported "half". vec2 color; vec2 coef; // Cubic curve coef. }; So we can calculate how many lights we can use from GL_MAX_FRAGMENT_UNIFORM_COMPONENTS. There're 2 import notes: 1) we can use forward and deferred rendering simultaneously (i.e. for different distance), 2) as you noticed we don't have a lot of semitransparent objects; trees, bushes have transparent only for soft edges, so on enough distances we can render them without alpha blending and they're not transparent objects anymore (we don't need to be honest for rendering always; if it looks the same/very similar but cheaper, then we'd can use the cheaper one). If we assume that we don't have a sun at rain, then we'd easily add shadows to the lightnings Nope (at least not yet). It'd be confirmed when it'll be in the our main repository It uses 2D rain texture (drawn by me in Ps for 5 mins ) on many long crosses with double side rendering (because many particles would be slow). They're not moving when the camera is moving. So it seems a correct rain. Current implementation doesn't use shaders yet, but with shaders it can be a little bit nicer.
    1 point
  10. My gosh that Ganondorf
    1 point
×
×
  • Create New...