Matei

BTW, I'm also curious to see if other ways of doing map generation would work better. I went with the TileClass design (where a TileClass is just an arbitrary set of tiles) because it was simple and fairly fast (RangeOp is pretty cheap in both memory and access time). My guess is that a quadtree would perform similarly, but maybe this changes when you implement it in JS.

Sorry for the late reply, it took me a bit of time to page this back in. RangeOp is actually a data structure that is meant to store an array of counts in an efficient manner. In particular, suppose you had the following problem: * You have an array A of integers of size N. * You need to quickly query it for sums of the values on ranges of the form i..j (so you want A + ... + A[j]). * You want to be able to add or subtract from the values at any spot in the array. RangeOp lets you do this in O(log N) time for each operation. In particular, RangeOp maintains a number of smaller arrays: the big array of size N, then an array of size N/2 that contains sums of groups of 2 adjacent entries, then an array of size N/4 that contains sums of groups of 4 adjacent entries, etc. When you do a set() on a single element, it updates these group arrays too. When you do a get() on a range, it gets the value by looking at the highest-granularity subarrays it needs to. In the RangeOp class, all of these arrays are actually in a big array of size 2 * nn, where nn is the first power of 2 that is greater than or equal to N, so that is why the code is just doing stuff inside this big array. More concisely, RangeOp is exactly like a 1-dimensional quad tree. I chose to go with one dimension because that seemed to give a big enough performance gain that implementing a 2D quad tree wasn't worth it. This is why TileClass actually contains an array of RangeOp objects (one per row) that do its counting. We can come up with a better name for RangeOp, or even a better implementation (e.g. 2D quad-tree). I'm kind of shocked that I didn't document it. I guess it just slipped off my radar as I stopped working on rmgen. Normally I try to document these kinds of datastructures more carefully. The reason it's called RangeOp, by the way, is because the "operation" we're performing on ranges (sum in this case) could be other operations too. However, there's probably a better name for this kind of datastructure. This is just what I've seen it called before.

I should add: the best way to contact me is to email me at matei@eecs.berkeley.edu, but you can remind me to post here as well.

Hi Bruno, Jason forwarded me this link. I wrote the old rmgen (in source/tools/rmgen), so I'd be glad to answer any questions you have about it. I like the idea of integrating it with the main game engine. Right now there are some parts that are C++, but the system is intended to let you write scripts in JS. The parts that are in C++ are mostly that way for performance (e.g. Perlin noise is fairly computationally intensive). However, performance might be good enough with pure JS code, in which case it would certainly be nice to move everything to JS.

I think this is a great idea, Philip, sidestepping a lot of issues associated with building our own GUI that we'd have to address as we go on. (Even if we started with a very simple GUI, inevitably, people would want more from it, and would have to hack it in somehow.) Defining GUI pages using standards (HTML, CSS, etc) is also a big win for modding. The only question is whether Webkit embedding is really as easy as advertised. Seeing EVE use Webkit is very promising. I also know that a lot of apps on Mac OS use it (beyond the browser), and it claims to be designed for embedding.

I had the same problem with Atlas on OS X before - it would load but then freeze. I assumed it was a problem in the wxWidgets configuration. Using gdb or dtrace on it might also help.

I'm curious whether Atlas works on Mac when compiled with gcc 4.3. It used to have problems caused by wxwidgets. If you run pyrogenesis_dbg -editor, does it start up and can you interact with it? My guess is that the problem on the mac mini would be the lack of a GPU, but you can also try the gcc 4.3 version there to see if it works.

Arn, what were some of the errors you got under gcc 4.0.1? I was able to build Collada according to the instructions on the wiki and then to go into build/workspaces and make pyrogenesis. There were some errors compiling AtlasUI (if I just type make), were those the ones you saw?

I can confirm that I've managed to build the game on OS X with Collada based on the instructions on Trac. I just used Apple's GCC (4.0.1) and I didn't have to modify the OpenAL header.

I definitely get speedups from make -j 3 on my dual core machine, so I think keeping the option for parallel build would be nice. If SCons really doesn't scale to the size of 0AD though, we can drop it. Many developers will have the option of working in Visual C++, which does parallel builds.

Happy new year guys .

That's hilarious! Good catch by you guys. Poor Ross .

This is great, congratulations! Very well-written article too . I've always enjoyed reading your articles (and those of other historians) for 0 A.D., especially since I don't know too many details about the history of the time period, and it's very nice to get an article in print too. Good luck with other writing in the future!

Achilles, I think I understand your point, but I think that your form of fandom really can't apply to our project. Your attitude is closer to that of a loyal consumer or a sports-fan - you make a commitment to an organization, but you want something back. What we mean by a "fan" is just a friend or supporter. Like it or not, our project really *is* volunteers working on something in their spare time, and if you think it's possible to have people to do that at the same rate and with the same level of commitment as a company, I think you've got yourself a very nice business plan . I don't know, to me this sounds like a reasonable way to run a project, but maybe there is some culture difference between us that makes the idea of running this kind of project for fun seem irresponsible or arrogant to you. Surely you've done some things as a hobby in your spare time? What's wrong with deciding to create a game in this fashion if you can put together a team with the abilities to do it? In the same vein, there really *are* things that are more important to us than this project. I'll talk a bit about my own view, since it may be different from other members'. I personally don't *want* to be a game developer for the rest of my life, but I do like developing games for fun. If I got a job offer from a game development company, I would decline it, because I'd rather work somewhere else. Does this make me a bad game developer? Maybe it means I'm less good than I could be if I dedicated all my time for it, but it doesn't mean I can't develop games, and it doesn't mean I'm not passionate about doing so. Again, I think you're viewing us with the same expectations as a professional sports team or corporation, whereas we're more like your neighborhood basketball team or band. Think about how your neighborhood band would react if you told them you want to see them on Broadway by next year, and that furthermore, you would be disappointed if they don't go there. About making the game public domain, as we've said before, one problem is that this will make cheating in multiplayer trivial. There's simply no way to make a peer-to-peer multiplayer game hack-free while open-sourcing a large portion of it. For example, it literally takes one line of C++ to reveal the map, and maybe a couple of days of work to make an AI play for you. This is a very different situation from something like a Linux kernel or web browser: for us, open-sourcing breaks vital functionality of the product. I think a free game with competitive, fun multiplayer is much more valuable than an open-source game with no community. Our development is far from closed though. If people want to help out, they can simply apply. I don't think we've ever turned down a competent programmer or artist. If you know an open-source programmer who loves games, by all means point them to us! I fully accept your point about monetary donations however. It's a very valid concern. Hopefully that will be fixed when we release some kind of demo version. I also accept that we could be doing more "PR", but there has to be a balance between PR and actual development of the product. If all you want is to play the game, rest assured that you will hear about it when it is playable . So will other people. Hopefully the wait doesn't stop people from downloading a free game and giving it a whirl. And we *do* hope to have something more interesting than screenshots quite soon.

Just another thing, please keep in mind which posters are members of the development team and which aren't. I don't think anyone on the team meant to be disrespectful. I'm sorry if we were that way. Here are my thoughts on your points: - If you wish to see daily progress, look at the Revision Log on the left side of http://www.wildfiregames.com/0ad/. This shows a summary of the changes we make to the game each day. (Highly technical changes aren't listed.) It's updated in real-time as we make them. It's not very detailed and doesn't explain much, but at least it gives an idea of the things we do every day. - We are also releasing a showcase or screenshot each month. These usually reveal new info or new artwork. - We are releasing new history articles every few weeks, often 3-4 per month. - We can't give a fixed schedule for several reasons. First of all, life is unpredictable. As an extreme of this, one of our founding team members passed away about a year ago due to cancer. Similarly, several of us are in their last year of school, graduating, looking for jobs, etc. 0AD is a volunteer project that must fall behind real-life priorities, so we can't reliably estimate how much time we will have available and thus schedule things far ahead. Secondly, game development in general is very complex, as you undoubtedly know. When we say this, we don't just mean "it's hard", we mean "there are parts of the process that may take way longer than we estimate". It's really tempting to write down a schedule and put something like "computer player AI - 6 months" without knowing whether computer player AI can be done in 6 months or even how to best approach that problem (after all, it's not a "standard" problem; there are no books or papers or courses on writing an RTS AI; it requires creative problem-solving in addition to time). In the end, we have a choice between releasing a schedule and taking the risk of not meeting it, or not releasing one but showing things we *have* finished through screenshots, revision logs, videos, etc. We chose the second way because it seemed more honest and less likely to disappoint people.

I modified the cull camera to increase its field of view and hopefully capture more objects, without having to capture absolutely everything. I'm not sure how this affects performance, because my own performance with fancy water is very slow, but maybe someone with a faster computer can try it on the next build and see whether it slows things down. It appears to capture more objects though.

This is very nice. The only problem I noticed is that for some reason, my VLC shows green squares on the first few frames of the videos I make, but QuickTime doesn't. I assume it's VLC's fault.

Well, as discussed before, it's not just that the engine is proprietary. In fact so many different people have contributed to the engine over the years that it would be quite complicated to use it for a non-free game (we'd have to find everyone, get them to agree to some share of profits, etc). A bigger concern is cheating in multiplayer. There just isn't any good way to detect and prevent cheating when you're handing someone the source for the game. Without cheat prevention the multiplayer community will suffer - there are always people who try to ruin others' games by cheating. It may be possible to open-source non-multiplayer code though.

We can probably cheat . A more efficient way to do it might be to just increase the clipping frustum on the reflection and refraction cameras by some fixed amount (one way to do that is with Field of View I think).

That would be pretty cool. With triggers and unit AI we may be able to export some scenes of fighting or gathering from the game (I can work on ways of doing this if you want). Even if we don't do that, a flythrough through one of our maps and maybe through a town would be pretty nice.

Congrats everyone!

Hi Samsonite, Thanks for telling us about this; the application script seems to have been having some problems lately. Please private-message your answers to the application form to me, Wijitmaker and janwas (you can do that by clicking on my name to view my forum profile and choosing Send a Personal Message). Thanks!

Hi Alex, good to see HG people here! I don't think I really met you since I stopped visiting HG forums a few months after AOE3 came out, but I used to be pretty active at AOMH. If you are interested in helping out later, you could talk to us about what's possible (there may be more things as the game comes closer to completion), otherwise feel free to comment on stuff.

OK, this time it went through. Thanks a lot!