- Written by kharnov
Read on for what we've been up to over the past week, and what we're in the process of working on.
We've been very active with coding lately. After fixing rim lighting last week, we've gone on to other things. For instance, gimhael has fixed the strange lighting that appears on our creep texture, so it will no longer constantly be strongly lit, but will rather follow ambient lighting conditions. In addition, we are looking into the possibility of adding blur as a post-processing effect for certain things. When it comes to a state where it's workable, we'll see where it goes. At some point, we will get to fixing HDR on the renderer, but it's lower priority compared to other things, such as fixing the shadows in our engine. To that end, EmperorJack has been collaborating with others on the team in testing out various lighting conditions on maps. Shadows have been time-consuming, but they're definitely something that we will be fixing in the near future. After all, blob shadows look horrendous, and don't exactly fit in with the art style of our game. However, you should be able to see shadows generated from light sources such as the flamethrower.
In regards to bots, we've made some nice progress on them, especially in meeting the aims of our goals for this quarter. As you might recall, a sort of tutorial mode has been planned, and we're to finish the groundwork for it by the end of March. At the moment, Fuma has been working on a behavior tree system for the bots. Essentially, instead of defining all of bot behavior in the code, you do it via textfiles that are built with nodes. These nodes are bot decisions, and can be thought of as a flowchart for the bots to follow. Thus, this system can be used to define any sort of arbitrary bot behavior, and the uses should be readily apparent in regards to training players, not to mention a future single player mode. Once he's done with the system, Fuma will likely go back to working on implementing libRocket, which he has made quite a bit of progress on.
Plenty of assorted code work has also been done, which you can follow on our Git repository. For one, Darren Salt has fixed the behavior of the flamethrower, which had an unfortunate tendency to not deal any significant damage at close range, despite flamer particles clearly hitting models. On a side note, the flamethrower will also now do splash damage to things adjacent to the stream of fire, which one would expect would happen when standing near a source of intense flame. He has also adjusted the shotgun's spread, so that instead of firing in a square, it instead fires in a circular pattern, better fitting what the crosshairs indicate. Also, danmal has been working on the scripts used with our installer, so that you won't experience some of the annoying behavior that has been plaguing users for some time now. There is now MD5 verification of assets, and the installer will detect if assets are corrupted for any reason. Old vm files will be deleted from the data directory, which has been a source of problems in the past. Lastly, the download progress window should no longer be obscured.
Now, for this final paragraph, I'd like to go into detail on what we've been accomplishing with gameplay. A week or two ago, we finally came to a consensus on how we'd be handling resources. Norfenstein directed and summarized the internal discussion, and `Ishq will be coding it. To put it simply, we are abandoning the system of build points seen in Tremulous. One of our fundamental shifts in gameplay is going to be in regards to how build points are obtained. In Tremulous, you had a static pool of build points that regenerated slowly after losing a structure. We'll be doing something different. Build points in Unvanquished will instead be generated by the usage of resource extraction structures. Of course, we're still working on what the resources themselves are, but that isn't entirely important. What is important, however, is that we will be testing out several ways in the coming weeks of how we'd like to implement this. We will be deciding between four possibilities: fixed resource sites with a global build point pool, free placement of extraction structures with a global build point pool, free placement with a resource map, and fixed resource sites with local build point pools.
Stay tuned for next week's article, in which I'll go over what to expect in our twelfth alpha release.
@Flamer: Someone fix the muzzle particle system (I've already done it), because it uses all the inertia from the user rather than partial, as the code says. At high speeds, the positions of the flame"balls" are different to the fire stream that the visuals emit.
@Resources: +"Fixed positions where you build resource extraction structures"
Also, I'm wondering, what if it was like this:
-Global resource fuel = 50'000 or similar greater
-Or, local resource pools with limitied fuel of about 5'000, where the closer you build the "power" structure to these areas, the more it absorbs from the particular area in comparison to other areas (hence encourages not spamming in one area, but to expand base)
-Overmind/rc/"egg??"/repeater takes up 2-50 "fuel units" per "second/x unit of time", where the amount it absorbs is based on how many structures are built within its reach
-Like our current tremulous gpp (except aliens), there are limited structures to build around a power structure
-Instead of "Sudden Death" there's "No resource fuel remaining" (except structures shut off and alien buildables slowly die)
-Add a generator, which recycles... erm.... some unknown source, CO2? which replenishes resources for that local pool
-I think local pools are better than global ones, as it prevents building in areas such as... well outside the map, if there's a bug that allows it...