stwf
-
Posts
178 -
Joined
-
Last visited
-
Days Won
2
Posts posted by stwf
-
-
ok, first pass at playlist functionality is in. Let me know if there are any problems.
-
1
-
-
So from a novice point of view the only real strategy they know is flanking someone or coming up from behind. I'm not sure to what degree it is historically accurate, but game wise you expect to really do a number on someone you manage to surround or hit from two sides, especially if they didn't have a 2 sided formation in place, etc..
I think we need to get that working, if only from a gaming aspect, that you get a noticeable advantage there beyond the regular numbers
PS I guess this implies that 'unformed' troops get an overall penalty, since in the end its one unit firing at another, that would be the default case, and any sort of formation either helps him avoid damage or does nothing at the worst
-
Is there a design document on these modes? I must admit I'm not entirely sure what each one means, like Death Match vs Supremacy...
My favorite mode was Rise of Nations Conquer the World, where it played like Risk but then you went in to fight each actual battle. It gives the game infinite playability, especially when you could make an ally who would provide you with a teammate in battle. There are infinite possibilities
For real historic accuracy I think we would need a system where you travelled slower through a swamp or forest than down a road, but I agree fixing the lag is top priority, the game has to be fun to play above all else.
-
Just a reminder that one of the MSVC warnings still exists
1> CBufferItem.cpp
1>e:\devel\ps\source\soundmanager\items\cbufferitem.cpp(88): warning C4702: unreachable codeAny idea how to fix this? I guess its missing the fact that the variable is being passed in by address and can be changed? I tried declaring it volatile, but that conflicts with how OpenAL defines the function...
-
OK, I got rid of most of the warnings in the sound code. No real issues there but it is better to initialize all variables I guess. I left in the two issues with ogg.cpp. THe code there is fin if the macros are unrolled. I guess the analyzer isn't running through the preprocessor.
-
Since some discussions are taking place concerning formationsI thought I would chime in. I'm not especially knowledgeable about ancient war, or really experienced in RTS's so I think my expectations may match what a lot of new users might feel.
The obvious to a casual user advantage of using formations in battle is to give a directionality to the attack or defense.
A group of archers would get a more lethal attack to the front in exchange for weakened defense on the sides. Thus a group of archers in a straight formation would defeat the same number of ungrouped archers that were in front of them.
So my interests are formations for defending a straight on attack, defending against a flank atttack, and maybe one that was pretty good at both.
Conversely on attack I'd want to attack straight on, perform a flanking attack, maybe a balanced one too.
In addition RIse of Nations has a seige formation that would concentrate on defending the catapults while bombarding a town, that was very useful.
As far as movement, it should really just insure that everyone arrives at the same plac eat the same time. Instead of everyone getting somewhere as fast as they can.
[Hijacking this to make it the discussion thread for Formations Review]
-
Keep in mind that there's a config option "pauseonfocusloss" that can be changed, so the game doesn't necessarily pause when it loses focus. Do you play in windowed mode? Try it, and switch from the game quickly to say, a chat window, and back, and listen to what happens
Sometimes there's a tendency to add an option for everything, but maybe time for muteonfocusloss or muteonpause in the config?
I just put in a fade in and out when the app switches focus. It also honors the pauseonfocusloss flag. Otherwise I left the behavior as is. It turns out I can differentiate between being minimized and losing focus. So what ever the consensus for the behavior is I will implement. I don't think that having a set of preferences for background behavior is overdoing it.
If you can provide some API for sound manager to reset sound to default state with nothing playing (all buffers cleared), I or someone else can write some AtlasUI / GameInterface code to use it. Unless you really want to delve into AtlasUI, it's not too bad once you get used to it, but you do have to realize it's running in a separate thread from the game engine and thus custom message passing is used to control and query the engine.
You can turn the sound off using the static function CSoundManager::SetEnabled(false). You can turn it back on by passing true to that function. That completely closes it down and then reinitializes it.
This snippet will pause and unpause it, I could put this into a static function if you like.
if ( g_SoundManager )
g_SoundManager->Pause(g_Game->m_Paused);
At some point I would like to get into the Atlas stuff but it seems like there is plenty to do game wise for the time being ;-)... I did wonder why the actor editor didn't play the units sounds. But otherwise I haven't spent much time in Atlas at all. If you could put this in at some point I'd appreciate it.
-
OK, I will play around with that. I agree that if the action doesn't pause the music shouldn't. I will also smooth out the abrupt cut offs.
I can look into what kind of options we have here, as you said I'm not sure we can tell if we are minimized or not. SI this something the Design Committee might get involved in?
This originally sprang out of http://trac.wildfiregames.com/ticket/1712 . But for some reason this bug still persists. It seems like the Atlas engine doesn't stop or pause through the same mechanism that the regular game does... But it does seem to start the music normally, odd
My one option is to just make Atlas aware of the sound manager and pause the music when the simulation is paused. But that doesn't seem right. Any ideas in how I can best capture Atlas starts and stops?
-
About r13347, the music cuts off abruptly whenever the game window loses focus, even if it's just to tab over to some other window. I think in any case the music should gradually fade to silence, but I'm not convinced losing focus should necessarily pause the music. I think there are multiple cases to consider: fullscreen vs. windowed, minimized vs. lost focus. There's probably a better argument to be made for muting paused games; we could also transition to a quiet music track (Omri is working on one such track I think, to play in the game menus).
OK, I think a quick fade out can be put in pretty easily. It just doesn't seem right that the game action pauses and the music doesn't. Certainly the ambient noises should shut down, so it only seemed logical that the music did too. To me pause means pause, including the music.
But I'll adapt it to be anything thats decided upon. I just noticed it that trying to take a phone call during a game meant I had to quit to get the music to stop!
-
Perhaps some mild deterrent to using the CC as a dropsite? Figure the CC can process and distribute grain, but it can't do it as efficiently as a dedicated farmstead can, so units making full drop offs at a CC might take some time to unload, where it is instant at a dedicated drop zone. So the loss of worker time would prompt people to build farmsteads instead of farms close to the CC.
Just a thought
-
I have been thinking about pathfinding. I know this may not jibe with the way other RTS' handle things, but we are aiming for more historical accuracy, right? I haven't given thought to how this would be implemented, but maybe it is worth investigating.
So normally when someone sent out a large army for attacking, they wouldn't really take the direct route, through rivers and forests, but they would take the roads, right? So if we established roads in the game it wold make pathfinding much easier since most long trips would take the road across the map at least as far as they could.
If someone did want to stage a surprise attack and come a different direction you would expect that to take more interaction from the player, specifically dragging them off of the road, and then directing them how to go.
It seems another inaccuracy we have is how units seem to try and find the shortest path even through the fog of war. In the case where a unit was sent deep into unexplored territory wouldn't that unit only be able to take the best route a tile or two at a time? It would depend on its line of sight. Units in real life entering unexplored territory would be expected to hit dead ends and have to turn around. Maybe scout units could get some more distance due to a sense of knowing the best way to go.
Then we could also make distinctions between fighting on land where the geography is already known (as well as roads and their paths) vs unexplored territory where everything starts as a mystery.
Anyway more food for thought...
-
1
-
-
Maybe this is the page you are searching: http://trac.wildfire...ayFeatureStatus
Thanks! That was the link I was looking for...
You know we could trim quite a few items from there by moving all of the naval issues to version 1.1 (or 1.2)
-
1
-
-
You would need a hefty server since it needs to run the whole simulation for every AI it provides. Letting a player host the AI seems more realistic.
I will spare no expense for my deathbot!
-
Wouldn't the best way to handle this adaptive AI be to make it a stand alone web service.?
Then give it a chance to log in as a regular player and interface with the game the way other remote clients do. Then it could get better and better as people kept playing it. Replay wouldn't be a problem since the host game would just see it as another player. I know this would be a lot of work and not much help to the app, but it could be a cool thing to have.
-
1
-
-
MSVC warnings as of r13266:
9>..\..\..\source\soundmanager\js\SoundGroup.cpp(176): warning C4018: '>' : signed/unsigned mismatch
9>e:\devel\ps\source\soundmanager\items\cbufferitem.cpp(88): warning C4702: unreachable codeThanks!
-
Sorry, but this is absolutely not true. Lots of progress has been made on the AI, but it is still well below the skill level of an average gamer. I know this because even I can beat it
lol I never said you wouldn't beat it, just not crush it. It always gives me an entertaining challenge. I guess I just suck though.
Anyway my contention stands that its good enough for beta and we can focus on addressing some issues with it for 1.0
-
I know in the past I have seen a list in the wiki of the 'must have' items fro a release, but I can't find it now. Anyone have the link? I think the link should also go on the front page of the wiki. In large flashing red letters! OK, maybe not, but prominently.
I also believe this game is much closer to release than most people think. 99% of the people you would get from a release would have a great experience paying the game as is and won't ever get to the point where they can crush the AI.
I see no problem with limiting single player games to 1 vs 1 (to avoid lag) at least in the beta. And then concentrate on optimizing, balancing and bug fixing as we push to 1.0.
It seems many of the complaints I hear could easily wait until a 1.1. BTW even in Rise of Nations (my favorite) I have watched armies of AI run back and forth on the map confused, and they make the AI tough by giving it a huge resource gathering advantage. So there is
Its a shame that on a project this great anyone is downhearted at all! You are all too close to it to see how awesome it is!
-
Interesting. Could you let us know a bit more about how you think this will work?
hmm, I hadn't really gotten in to it too much. But currently the simulation finds all PEACE tracks in a civ's json file, picks a random one and loops that forever. So I'll add a way to upload the whole list and play each song in order, looping forever. Then I can add options for gaps between songs, or random play. This way the simulation can decide exactly what it wants a people can play around with it..
I did think that any changing of the music, say to battle music, would wipe out the playlist.
-
stwf, on an unrelated note, is there a way to play UI sounds for e.g. attack notification? There is a simulation function called PlaySound(), but that is always tied to an in-world entity.
You can play sounds, but at the moment you can't play a sound at a position without a unit. I can put that in though, I was also going to add a playlist capability for the next alpha.
Yes! It seems much improved, but I still think we could do away with all the dying sounds. Not only because they're repetitive and we need more variety.
Preferably we've have a different set of sounds for battles and skirmishes. In a skirmish you might want to hear an individual unit die, but in a battle you want to hear war cries, trumpets sounding, and then trampling feet, stuff like that to make it feel epic. Think of battle scenes in a movie, what do you hear? But even in a battle I suspect there would be a special indicator sound for certain units dying, like a hero for instance, maybe mourning/lamenting sounds?
The battle music is a good first step, but we could do more to enhance the experience, like once(if) we add battle formations, there could be retreat and you'd hear the sound of retreat, or if it turned into a rout you'd hear frantic sounds of fleeing.
Yes the numbers thing is a clear place to improve, having a separate sounds for multiples of the same unit in the same general vicinity. That would let the SoundManager play a lot more sounds too. Is there an easy way to get this info? I don't think having sounds based on formation or state would be too hard either. Although it might be best handled in the simulation.
I'm linking to http://trac.wildfire...ty_%26_Priority here as it's relevant. Even if the old concepts might not be entirely applicable to the new sound system etc/there might be other ways to do it, there's certainly no reason to "reinvent the wheel", so it's at the very least important to know about the old discussion so we don't try and find new solutions to problems which were already solved in theory several years ago
Thanks, this is just what we mean, although they don't seem to consider where to place the sounds, or if cavalry on the far right and far left should be considered the same unless I misunderstand it. The muffling for offscreen stuff is already in there but more more strict than this paper suggests although it can easily be changed.
-
Does anyone think the battles sound better? More full?
The error messages are meant to be removed before alpha 13. I just put them in to test we were getting the expected behavior on all platforms. It sounds like we are so I don't think there is a need to keep them in there at all.
For the record getting the message
ERROR: Sound: Entering distress mode through shortage
Is normal and expected during a moderately sized battle. At this point some sounds are not getting played. A good improvement would be a way to prioritize certain sounds and try and make sure they get played.
Anyway when the battle is over you should exit distress mode with no error (on Win and Linux). It seems MacOS returns 'unknown internal error' at times when in a stressed state. People on the OpenAL mailing list think its some thread contention bug in Apples implementation. Either way it doesn't seem to have too much effect, but I will keep trying to isolate it. If only to report it to Apple.
-
ok, the problem with building in Windows should be fixed now... sorry about that.
-
OK, it is in! I'll be around on IRC in case anything goes wrong.... Hopefully this will improve the sound for people. There are still two log messages included for testing purposes. It will say it is going into distress mode over large battles. Then when the battle subsides it should come out of distress mode, hopefully reporting no errors. I haven't seen errors anywhere but on Mac, and I'm not sure they needed to be worried about.
-
Hello All,I'm back!
Did anyone get a chance to try out the latest patch? Anyway either way I guess I should just commit it to trunk and see what happens, no?
-
OK the new SoundManager code is in a patch attached to its trac ticket (I'll also attach it here)
http://trac.wildfire...com/ticket/1766
This is a diff against the latest svn trunk, so patching should not be a problem. I'll be AFK for a week (so I didn't want to check changes in), hopefully this will work fine and can be incorporated during my absence or when I get back.
Battles should sound much fuller, and should work much better in low resource environments.
Also there is some extra logging here, about going into and out of distress mode. Going into distress mode dues to shortage and coming out with a 0 error count is normal (during large battles) and good behavior. On MacOs there seem to be times the system returns an unknown error when it can't play a sound. So in that case you might go into distress mode on an error and emerge with a big error count. I think this is also not a big problem. It shouldn't happen on non-mac platforms (let me know if it does) and doesn't affect the sound noticeably (also let me know).
I can try and track down the exact cause of the issue in the future.
Enjoy!
-
2
-
New Sound Manager svn patch
in Game Development & Technical Discussion
Posted
ugh
I don't get that on Mac either, obviously or I wouldn't have released the code. oh well I'll try to figure out what is going on. Any good details? In windowed mode or pausing the action somehow else? Sound effects cutting out is strange.