Jump to content

Yves

WFG Programming Team
  • Content count

    1,131
  • Joined

  • Last visited

  • Days Won

    25

Yves last won the day on July 11 2016

Yves had the most liked content!

Community Reputation

349 Excellent

1 Follower

About Yves

  • Rank
    Primus Pilus
  • Birthday 08/25/1988

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,296 profile views
  1. Yves

    Unread Content unavailable?

    I had loading times of 40-50 seconds for a few days and now I'm getting http 503 too. I'd guess there's a performance issue with the forum database because files load quickly and other parts of the forum are also relatively slow (like around 10 seconds loading time).
  2. You answered my question only partially. So far you have identified most issues with the current gameplay and you have outlined some possible ways for fixing them. That's a good start, but it's still quite far away from a concept that can be implemented. Decision have to be made where multiple alternative solutions have been suggested, dependencies between features have to be identified and clarified, detailed descriptions have to be written per feature etc. If developers want to help, they need very specific and detailed information how a feature should work. Do you think it's realistic to design such a concept, write it down and then also implement it in roughly 6 months (I guess 3-6 is too ambitious)? As I said, it would not be complete yet, but it should be complete enough to give a good impression of the final gameplay. If you don't know how long it would take to implement something, that's fine. you could still estimate how long it would take until the first parts of the concept are finalized enough so that someone can start with the implementation and how long you'd need for the whole concept.
  3. Do you think it would be possible to implement your suggested changes in a proof of concept mod/branch in relatively short time of around 3-6 months? The scope would have to be limited as much as possible without leaving out anything that is crucial for the gameplay as a whole. For example, it could only focus on one civ, placeholders could be used instead of new artwork and workarounds or hacks for difficult features are OK. What tasks would have to be done exactly and how much help would you need from the team? We are still discussing your application in the team and I can't give you an official answer yet, but such a proof of concept implementation seems to be well supported. The tasks required for it (further work on the concept, setting priorities, defining tasks) are the next step anyway, so it should be ok to get started with it.
  4. I'm looking forward to reading that document! The lack of a coherent gameplay design is the main issue that prevents us from going to the beta stage and eventually releasing a 1.0 version in my opinion. We need someone with dedication for this task! I've been working on game design for several weeks but then got stuck with a problem I haven't been able to resolve yet. There has to be a plan who could implement missing features in a reasonable timeframe, otherwise it's not going to work. As soon as your design includes some very though technical requirements, this becomes an issue. In my case, I felt that fighting mechanics in this game are quite dull at the moment and I wanted to include some formation fighting mechanics (see: http://trac.wildfiregames.com/wiki/FormationsWip). When looking at the technical aspects, I realised that all our pathfinding code is currently designed around single unit pathfinding. The formation system we have is basically a hack that works more or less OK in most cases, but it would require a major overhaul to meet the quality requirements for such a formation fighting system. Because the fighting system has such a strong impact on other aspects of gameplay, I stopped working on the design and started looking into pathfinding. How would you handle such issues? It's always a possibility to work around such technical problems with the design (drop formations, reduce population cap). You actually see that a lot in commercial games. One part of me thinks that perfectionism is misplaced here (if large companies with big budgets do it, why shouldn't we?). On the other hand, I'd like to strive for more than just another generic RTS that copies the same mechanics we have seen in commercial titles for years or even decades now. Maybe both is possible with a very clever design...
  5. Yves

    ===[TASK]=== Parrot

    Hello and welcome! I like it, that's a nice addition to the hawks which already fly around in some maps. I'm a programmer and not really qualified to give feedback about art, so I leave that for one of the artists. Yes, you can. Have you already taken a look at the existing hawk actor xml here?
  6. Yves

    Your screenshots

    Looks like the perfect testcase for the instancing I'm working on.
  7. I don't had anything specific in mind for multiplayer. It's maybe just because I think that multiplayer games are way more interesting than single-player games. They are more dynamic, more surprising and more challenging (even though wraitii, mimo and the others did a very good job with the AI ) . My comment about tutorial videos was just my personal preference. If you have something in mind, go ahead and give it a try.
  8. In my opinion, tutorials how to play the game aren't particularly interesting. There are some around already and even though I've enjoyed watching some let's plays on Youtube, I've never watched a pure tutorial video about a game on Youtube. In addition, gameplay is still changing quite a bit and tutorials could be outdated soon. Traditional let's plays don't seem to work very well for 0 A.D. either. We don't have a single player campaign yet and only some multiplayer videos were really interesting to watch for me. What really sets us apart from other games is how our development works. There's regularly new content to showcase and gameplay frequently changes because of new features or balancing changes. Something like the development reports, but in a video format, could work and could also attract new developers. You can search in the Announcements and News forum for these development reports. I'd say some well commented multiplayer matches would also work and modding or creation of a custom map in our map editor, but I don't know how well the modding and mapping suits you. EDIT: These guys do it pretty well with development reports in video form: wolfire.com
  9. A problem with writing to the config file could be. It would be user.cfg, not local cfg and for the Mac it's in "~/Library/Application\ Support/0ad/" according to the wiki.
  10. I didn't know we take Bitcoin donations. Everything about donating is described here: http://play0ad.com/community/donate/ EDIT: I misunderstood your question. I thought you wanted to donate but don't want to use Bitcoin but it appears you meant the opposite.
  11. Part of what you describe seems normal. The Javascript engine, for example, schedules a Garbage Collection (GC) regularly. During GC, it reclaims unused memory, but it only gives it back to the operating system from time to time. If I remember correctly, it should not go beyond 400 MB, though. But there are other parts of the game that do similar things like the VFS (virtual filesystem). The VFS keeps some data in the cache because it takes longer to load it from the disk than loading it from memory. So it doesn't work to look at memory usage in the first few minutes after the game is started and then calculate a memory growth rate based on that. But... This must not happen and is a bug. When did this happen? Was it in the menu, in the multiplayer lobby or during a game? If it was a game, was it paused?
  12. Yves

    Improving the trading mechanic.

    These ideas look interesting and I also don't like how the current system encourages to have so many traders. However, in my opinion the system should be somewhat self-explaining and it should be possible to understand how it works without looking at number too much and certainly without making calculations. Facts like these are hard to figure out for players: -Markets generate income based on "connections" with other markets. -Traders increase this "connection". -You can only build one market per CC. The basic idea isn't that hard to get, but how can you influence the number of connections exactly, how much benefit do you get from an increased number of connections and is there a difference between own markets and allied markets? It's hard to explain these things to players in a mathematical formula. Restricting the number of markets by CC seems to be a bit arbitrary, especially considering that some civs just have these smaller military settlements. I liked the separate "trading good" resource because it's something which is easier to understand by players. What about having different trading goods as a less abstract way of explaining these "connections"? You'd get more profit if more different types of trading resources are connected to your market. These trading resources could be placed by the map designer and whoever owns the resource could build a market close to (or on) it and trade it (kind of like in Riese of Nations).Or it could be that each player can trade one or more predefined types of these resources and the only way to get more different types is to trade with allies. In this case we'd have to find a solution for how the distance between markets affects the system. It could require more traders to operate a short trade route (less profits if you sell the resource close to where it's being produced).Or these two approaches could be combined and there would just be some generic "trading camps" on the map where the players could build their markets and trade their own trading resource(s).This is just some brainstorming and it would still require quite a bit of work to get to a solid concept. In any case I'd probably reduce the maximum number of markets to a very low number. Generating profit there should be more about setting up an efficient trade network and not just about building more markets and more traders.
  13. The development version is for developers and modders. If you just switch to SVN because you want to download only the differences between Alpha releases, then you end up downloading much more.
  14. At the moment we are limited on the CPU side by the number of objects and not the polygon count of these objects. At least that's true for dedicated graphics cards. In my OpenGL 4 branch, I'm working on reducing driver overhead with OpenGL 4 functionality such as glMultiDrawElementsIndirect. So far, I've only worked on the aspect of uniforms and don't even do real instancing yet. Still, this has already improved performance quite a bit. I hope and expect to see some more improvements by introducing bindless texture management, which should then allow real instancing. In my opinion, it doesn't make much sense to work on a LOD system, before we overcome these limitations.
  15. Hello Mikita and welcome! As Stan already said, programmers usually just pick a task and submit one or more patches before they eventually get invited to join the team. You may want to pick a simple task (link) or fix a bug to start with. If you are interested in a specific task, you may also work on that. Is there anything you are particularly interested in (AI development, GUI programming, network code, rendering etc.)?
×