wraitii
-
Posts
3.395 -
Joined
-
Last visited
-
Days Won
75
Posts posted by wraitii
-
-
There 's a weirder issue though... On Lion, when I play 0AD, there's a weird issue with the desktop that becomes "translated"... it's hard to explain really but it's like everything in the desktop was 200px higher than it really is (clicks are wrong and so on). Restarting the Finder fixes it, changing a few stuffs fixes it too, but it's fairly weird.
-
Tried it out on OSX 10.7, no luck...put the file in the 3 folders you said then tried running it, and it opened a blank window, then crashed...is the error report helpful? not sure which part to post if it is..it's huge compared to the ones in the last page.
It should be helpful anyway.
I'm not sure which version I've posted where, but this is the latest version. Just download it and start the application without changing anything, it ought to work.
-
Yeah, I didn't include AtlasUI.dylib because I couldn't get it to compile, but I didn't really try either because I focused myself on getting the game to work first.
-
I'm going to be away for a week, so won't be able to help much during this time, but the Idea is that you need to add a "copy file" phase and a "run script" phase to your Xcode projects. In the copy file phase, you'd copy every single dylib needed (I record 25). In the run script, you'll have to change the links so that it works.
You may want to take a look at this. I don't think it can compile as such, and it's not a perfectly up-to-date project, but it'll give you the idea.
-
I just finished uploading a bundle that might already be deployable. Could you try downloading this and starting the game? It should work.
-
Note that the Collada loading problem can be fixed in a more "convergent" way by simply adding a bit of platform-dependant code. I did so in my release: I Changed the DLL loader function LoadAnyVariant to this
static void* LoadAnyVariant(const CStr& name, std::stringstream& errors)
{
for(size_t idxSuffix = 0; idxSuffix < ARRAY_SIZE(suffixes); idxSuffix++)
{
for(size_t idxExtension = 0; idxExtension < ARRAY_SIZE(extensions); idxExtension++)
{
CStr filename = GenerateFilename(name, suffixes[idxSuffix], extensions[idxExtension]);
// Here's what I added
// this should ensure Collada is properly loaded.
#if OS_MACOSX
if (name == "Collada" || name == "AtlasUI")
filename = "@executable_path/../Frameworks/" + filename;
#endif
// we don't really care when relocations take place, but one of
// {RTLD_NOW, RTLD_LAZY} must be specified. go with the former because
// it is safer and matches the Windows load behavior.
const int flags = RTLD_LOCAL|RTLD_NOW;
void* handle = dlopen(filename.c_str(), flags);
if(handle)
return handle;
else
errors << "dlopen(" << filename << ") failed: " << dlerror() << "; ";
}
}
return 0; // none worked
}(note that I link to "Frameworks" because I copied there every library needed for the game.
Linking even the Data in it can be done too, but requires slightly greater changes.
I also report the fact that going from FS to windowed mode crashes. Though the fullscreen mode works correctly.
As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).
Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.
-
Do you plan on improving the military aspect of qBot?
Additional question to anyone: is there any way to simulate LOS for the AI?
-
I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.
-
Doesn't work with Snow Leopard 10.6.8, try to create a window but the app closes throwing a window with error messages.
Could you "report the problem to Apple" and paste the error code?
And have you downloaded the data? If not, download the data, and put the application in the same folder as the "mods", "config" and "tools" folder.
In case there is still a problem and it appears you have done everything right, could you open the console and paste the error messages appearing?
-
I'm fairly sure a Mac OS X deployment is not that hard... I've got fairly basic knowledge and could get it to work starting with the Xcode workspaces.
-
Can anybody try this version? I'm not sure which it is, but it should fairly work.
-
Hmmm. Shouldn't do that...
I'm actually going to have Christmas now, so I won't be able to update for a few hours. Merry Christmas all.
I get it... There's indeed a problem, I'll fix it as soon as possible
-
No, afaik the Data should be kept zipped (but the developers will answer that better)...
That's a weird problem, it looks like you have an outdated version of libpng in your X11 folder... I suggest you download the latest version of X11 and retry.
OpenGL should already be in your HD/Library/Frameworks.
You're likely trying to use the former version of my precompiled 0A.D. , which has bugs with Collada and some libraries, I'm uploading a newer one which should work independently.
edit: Okay, try replacing the application (only the application) by this one. Normally, you don't even have to update X11 as this version should rely on the one bundled with it (which means that it should simply work).
-
Okay, so this is the basic core of my Xcode project. It's not brand new, it's only an improved version of the workspaces that the game creates when following the instructions on the wiki.
You'll need two things, I think: the data (downloadable here) and the "libraries" folder, with compiled libraries. I have included the basic one, but I don't think it'll work with it... So you might have to go though the "normal" installation process as described on the wiki once, and then replace the files with mine (but the "libraries" folder). (Note that I have included a "Libraries" folder in /system , this one is not the one I'm talking about. I'm talking about the one in the root folder.)
If you're having any trouble, please report.
This includes the fixed Collada thing, but Atlas doesn't work. I'm compressing a new "precompiled" executable and am going to upload it later today, this one should actually be deployable.
-
I'm straightening it out and then uploading. I think I won't upload the data to save space, nor the compiled app, so you'll have to put it in the right folder, I'll indicate which.
Edit: Okay... Still trying to get the raw minimum, but at the very least I fixed the Collada issue. In fact, because it's loaded at runtime, the game couldn't find the dylib. I've added a little fix in "DLLloader.cpp" which should not conflict ( I used a "IFDEF mac os X") which solves the issue, you'll see when I'm over.
-
Darn, I wrote Alpha 9, I'm getting a bit carried away.
I didn't really troubleshoot this, so it's likely fairly buggy even if it starts but i uploaded it to see... I'm going to release my source code tomorrow, which will hopefully be more useful.
edit: apparently the Collada problem that was encountered with the former version still happens on Lion... I'd like to know if anybody can confirm or infirm.
-
I've got a version of the Alpha 8 that should be deployable for Mac os X. It works on 10.6 and 10.7 on the two computers I tried at home, and it should have no particular dependencies other than OpenAl, OpenGL and the basic libraries that come with OSX. If anybody can report, download it here. It should work, but I can't guarantee it 100%. At least it worked on the computer where I went through the whole "compiling", and on another computer which is basically "vanilla".
Btw, I encountered few compilation problems, mainly linking problems. In fact, using dynamic libraries on OSX is a real pain, there needs to be copying and script running. I have not included the source in this file, but I can tell you how to fix the Xcode Project for the most part. It's basically allright, but there are a few things to fix here and there, and libraries are a -real- pain.
Thing is, a shell script that downloads every library necessary and puts them in the right folders could really straighten out the installing process on Mac OS X, but I think my knowledge is a bit lacking on the matter.
-
I think, even if you keep a fairly basic combat system, that doing different damage depending on where the shot comes from is an -absolute- necessity. This is something I've never actually seen done... Perhaps it was, perhaps it was not. Anyway, this should be in the game, and it should be documented.
-
Adding my two cents about formations and formation movement and gameplay addition. Something I remember from Rise Of Nations was that unit got "entrenched" after standing still for some time. This allowed for one thing that I have found in no other RTS: actual flanking. Now while entrenching is likely out of scope for 0 AD, the formation system, if it is kept fairly robust, à la R:TW can simulate such a thing: formations should get a bonus against "front attack", "side defense" or whatever, so it makes sense to use them, and should remain fairly consistent: breaking them up should not be instant ( since this would negate "flanking" ).
A way to implement this would be to have some sort of trigger for each unit which would have different states: "Free", ie not in a formation, "in a formation", and "making/breaking formation".
Now I'm not sure how the combat system works in 0 AD, but I don't think units individually receive differentiated damage depending on where it's coming (flank/front/rear)... If so, then very well. If not, then it would be a really cool thing to implement.
Anyway, units "free" would behave normally, units "in a formation" would get damage depending on what the strong/weak points of the formation are, and basic combat. Units forming or breaking, on the other hand, would be fairly defenseless and would receive much bigger damage.
As for how this relates to pathfinding: formations should be a bit slower than normal walking (which would help the pathfinding too), and remain fairly tight when moving forward. I think it should absolutely remain so until it has to "break". The specifics of when it has to break are tricky to choose... I think the most straightforward way to do it is that if keeping the formation deviates the path from more than X degrees from the optimal path, the formation will break (something like 30° seems reasonable). Breaking can be handled in two ways... The ugly one is simply to make each unit behave individually, but this is a nightmare and really not nice.
A much better way to "break" a formation is to divide it into smaller "sub-formations", until the sub-formation can go through the obstacles (I'm taking the corridor example here). SO a 8x8 turtle formation could break into 4 4x4 smaller formations, and each would go through one at a time and then reform. This would be the optimal way to manage such a thing, methinks.
Of course, with the problem of an object getting partly in the way (such as what was drawn on page 1), a simpler solution of "moving away from the obstacle" should be adopted.
-
Do you plan on having "wounded" units inflict less damage? It's something that as always bugged me in most RTS: while a unit is alive, it will inflict maximum damage, even if it has 1HP. It's also why it's better to focus on one unit than to "average" damage.
-
I don't know if you've already read it, but this article might give you some insight about formation pathfinding.
-
I can't really help you with the coding (well, I could, but I'm on a mac and unable to start the game (I really don't have the skills required), so it would'nt be fun), but here are some guidances:
-It's not a bad thing to give the AI a specific to-do list early on(such as : until 2 minutes, food, until 4 minutes, food and wood, and do this and that). The human players usually do just that, and it might make it easier to code the AI.
-If the AI is to build towers (and walls if there are in-game), it should know where to properly place them. For walls, it's really a matter of determining what is important and what to protect and build a nice circle around it, but towers are a more strategic matter. It should not clutter more than 2 towers in one area (2 towers are more efficient than one at keeping at bay attacks, but 3 usually is overkill). It should spread the towers so that they share less than 25% of firing range, but there is no hole in "tower coverage" (otherwise it's just too easy for the player to go through).
Ultimately, it should try to learn where enemy attacks are coming from and build one or two more towers there. That's not that hard to do, I think, and it's a pretty great AI response.
Some graphics to illustrate the towers issue:
Bad positioning ( red is the "tower coverage", stars are towers, blue is the sea, sand is ground )
-Giving the ai some "soft-coded" behaviours depending on the map is pretty useful too, along with giving the AI rush/boom/turtling strategies.
Some other topics that you might consider adding:
-Clever AI, if a lot of space is available, could build houses scarcely. It makes it harder to destroy them all and crash the AI population cap. Or it could build small clutters of 3/4 houses.
-Military buildings should be built in priority closer to the enemy position. Economic buildings should be built farther to protect them.
-On the same topic, the AI could build "outlooks", that is a single tower far toward the enemy to know about attacks earlier.
-For AI attacks, the shortest path is rarely the best. It is much better to alternate between "straight line" attacks and attacks from the side or even the rear if possible.
-AI soldiers could be divided into categories. A "guard" section with some solid defensive units, a "raid" section that harasses the enemy (though they must have some clever attack strategies to work), etc.
-Micromanagement of units during attack can be the difference between success and failure, I dunno if it already does that but it could be a good improvement far harder AIs.
-Again on the "AI response to the player": if the AI attacks, and it sees the player has built numerous towers and walls, it should try to find another attack path, and if there is none, it should note that for further attacks siege engines are required.
That's all I can think of right now.
-
Edit:
Well, I think water distribution is way off for an RTS game. It is more of a City Builder feature - Caesar III comes in my mind.
True that. But primary management might be a fun thing to have, such as only building farms near water holes or stuff like that.
-
There is actually the concept of "settlement sites", that are represented by wells. Only there you will be able to build new Civic Centres.
Oh, right, I forgot about that. It's not an Idea I love, but I can see why it's practical.
As for the "near water", it was more of the "not in the middle of nowhere" Idea. Water is really important, but may be a lot of micromanagement.
Of course, I think it would be just great to have a true water management.
When farms run out...
in General Discussion
Posted
I like that. Something that, as long as you have the resources, ensures you have at least one "queued" farm for reseeding.