rincewind

this forum is the latest work on the topic I'm aware of. Ok, I'll see what I can come up with. About something else: I tried to get some fbx-models exported from Blender. Apparently, the Blender fbx-exporter adds some form of empty Video-Texture to the exported file. Since it's a ascii-file, I just removed it and the model loads (assault rifle). This leaves two "problems": 1) Most models in the assets-directory are .max files which Blender can't import. So either someone exports them to fbx from max or puts them in some intermediate format (3ds for example). No idea what gets lost on the way, though. Maybe someone having access to MAX can post some results on this? 2) Currently, it only shows the diffuse texture, I'll try to investigate how to get a nice bumpmapping shader with per-pixel-lighting on there.

About the country/mission part, I was mostly referring to the definition of country regions and trying to get some progress report on that. As I guess, that would be a feature we'll need for the AI missions. On the other hand, I guess we can still get by with using real random positions for the time being. Nevertheless, anybody working on the country coordinates?

Just committed a fix for (2), so you can use the number keys. I tried to google a little if there's not a simpler solution to it, as I somehow think that there should be a simpler method for stuff like period, hyphen, etc. without resorting to a huge switch statement... I'll try to get a proposal for (1) written and branch it into somewhere (branches are so cheap in SVN, that I think this makes for better discussions). About (3), I'll wait for Zombie to explain the datamodel a little. Concerning (4), I'm wondering if we should actually implement scientists/engineers as "real people" for now. It definitly deviates from the original game mechanics and I think we should go for replicating it for now, as this would probably introduce a whole lot of balancing issues, etc. Also, I think it's easy to later change the simple numeric assign in the ResearchTopic to a linked list of "real people" and a slight modification of the dayPassed handler. One could of course argue that we could still implement the full model and for now, just always add people with full science attribute, but I think this creates a lot of code that for now is not needed which is not really in the KISS-line of development. Tell me what you think, Rincewind

Hi, I'm back from my ego-trip :-) Seriously, I've been working on and off on the component-branch and I realized that two points: 1) I think there's still a lot of stuff to learn about XNA to use it to its full potential. Nevertheless, it also works with a more traditional programming style. 2) While some serious refactoring could prove beneficial, I don't have the time or motivation to work on this sufficiently. Maybe we can pick this up again when there are more large-scale experiences with xna out there and someone has the time and energy to tackle it. So I decided to rather go back to trunk and implement smaller features that actually result in something on the screen being seen. First I decided to finally get to fixing all the stuff, dteviot mentioned about the Research part. Only to realize he already did most of it (so thanks a lot and I'll fix stuff faster next time ). At least I managed to add comments for the private members that where still missing. There's still the issue about having the entire researchtree in the savegame or splitting it in two. A static part that holds the description from the xml and a dynamic part that holds what is researched (and some form of manager that handles the analysis and modification of the two). Actually this was mostly my first design (with the manager being part of the static-part, but nevertheless). I changed it to the current design because of two major reasons: One is updatability: A new update is not going to change the researchtree in existing savegames resulting in potentially inconsistent state (e.g. some requirements no longer able to be fullfilled, player having weapons that he can no longer produce, etc). Of course this also implies that if there's a bug in the tree, an update won't "fix" old savegames. (So this "advantage" is at the same time a disadvantage, but I still think the benefits outweight the costs) The other point is much more important I think: We can debug errors much more easily if we actually have the research tree in a savegame as we then just need a savegame from the user in order to reproduce his error (and not his current research.xml, etc as well). Anyway, hope to hear some comments. Also: whats next on the wishlist to implement if these arguments prove valid? I could go into the production part as it should have some synergy effects with research. Cheers, Rincewind

Ok, maybe one "solution" to one of the issues I brought up: The updating of references to GameState. Currently I tried to counter this in putting a thin wrapper on top of the actual GameState-Object which acts as the actual service and in turn holds the reference. When the load-method deserializes a GameStateComponent, it injects the Game-object and the Component (GameSTATEComponent, not GameComponent) registers itself with the service, basicly as a datastore and functionality backend. The service-wrapper currently only forwards to the registered component. If you want an example of this, take a look at ResearchService or GeoTimeService (This could probably even be semi-automated using Attributes for all methods that should be exposed in the service from a GameStateComponent and the service reflecting on the GameStateComponent and providing the appropriate wrappers). class GeoTime : GameStateComponent { [ServiceMethod] Time getGeoTime() { ... } } Game.Services.Add(typeof(XenoService<GeoTime>), new XenoService<GeoTime>()); Tell me what you think.

I thought I would open a new thread in order to discuss the concerns about the role of Model in the gamecomponents branch. As dteviot pointed out, having all model-parts be a GameComponent is not the right way of doing things as it makes it all a very heavy component. On the other hand, just having everything hanging as a hierarchical tree off a static reference in the Xenocide-class is probably not the best idea either. So maybe we can use this thread to find some solution. Here's what I have for now in terms of thinking (the points aren't particularly ordered, I just put them here to provide some food for though). * Model currently serves two purposes. It provides a storage container for GameState and thus effectivly everything that needs to be persisted in a savegame. On the other hand, it provides methods and logic to actually update this GameState. I think GeoTime provides a very good example for this. * The Model somehow needs to be able to notify the View/UI of events. This is partly implemented in the trunk through use of GeoEvent. What makes me feel a little uncomfortable with it, is that it basicly reinvents the old-school C-style windows-event loop (ok, we are using Command-Objects, but still, it's a queue that is manually queried, etc). I think dteviot mentioned somewhere that we need it this way (and can't use delegates/.NEt-style events) because of the GUI requires them to be used asynchonously. Maybe we can dig into this a little deeper and see if we might not come up with a more elegant design. * When we load a savegame (and stick to the thought that the Model-Classes actually ARE the gamestate and don't keep their identity when we load a new Game), we have to make sure, that the UI-Components update their references to the GameState-objects (this currently works since they access it by following the tree from the static reference in Xenocide. * If we want to make use of the Services-structure inside the XNA-Framework, we need to give the Model-Objects access to the Game-Object. I tried to make this functionality available in the form of a baseclass GameStateComponent (it's basicly a very stripped down version of GameComponent that just supports the storage of a Game-reference. No Update() or Draw() methods). It has the advantage of being very lightweight and being serializable (which GameComponent is not). the notion of Services leads also to the question whether we can't just make the Model's available as Services to the UI-Components. Which in turn leads back to the question of updating the references when we load a game. * Load/Save in general. We somehow have to serialize the GameState. Red knight hinted at a scheme he'd thought about in that msn discussion I posted. Maybe you can enlarge on it a little? As a final note, what I think is not good about the static approach. First, I think it makes the desing very rigid as I can't move something around inside the hierarchy of GameState without changing code in all places that access that particular object. Take research for example. It's currently in GeoData, what if we need to check from battlescape to see if we can actually use the picked-up plasma gun? Of course, you can argue that then we should have put it into the global state already now, but what about other stuff that might now be quite as easily predicted? As a service, we'd just change it's lifetime to also be available in battlescape and be done with it. Second, I think most of XNA-Framework's idea of having independent GameComponents (whose update-methods should work independently), of separating Update/Draw and of decoupling components through services is related to the fact that the future in performance-demanding computing lies in multicore. I can imagine the framework running several threads that walk through the update-methods, etc. If we have a single entry point to all things GameState (the static reference in Xenocide, again), we have to serialize all access to this object. If we offer the functionality through different services, we can just serialize access per-service. As we are all aware that xeno still has a long way to got, I think this should be put into consideration as well. Ok, I hope we can get some fruitful discussion here. Rincewind

Hi, some reports from the playground: I committed the changes to make the branch compile again. Sorry, TortoiseSVN showed everything as being up to date even when it wasn't. Should be fixed now. Anyway, here's the MSN-Discussion I had with red knight about services/components. It's a little long and we didn't reach a final conclusion, but it should provide some insights:

Alright, here we go: first of all, the current commits are heavily work in progress. I committed for two reasons, one is that those interested can already see some progress, the other is that I can go back to defined points in my changes if I mess something up. Thats what branches are for. I think the EnabledChanged issue is one of the points. What it allows us to do is use the facilities provided by GameComponents (e.g. have a unified concept of stopping the "Update-Pump" on an object and being able to react on it). Before, there was the Enable-Method that basicly did the same thing and replicated much of this logic. Since I'm in the process(!) of changing the code, I just kept the method and hooked up its logic to the EnabledChanged (if I remember correctly, I even made it private). As you correctly pointed out, the naming is no longer exaclty right, but again, we are work in progress here. The comment about reusablity of GameComponents, reusability requires decoupling of components, which is exaclty what GameComponent/Services provide (and static "globals" do not). As you said, most of those GameComponents are not going to be reusable in other projects. Nevertheless, having less coupling also benefits the development process for a single project especially if you have several people working on it. So I'm advocating this Service based architecture not on the grounds of reusability but on the grounds of reduced coupling. The question of whether the code structure is understandable, I again refer to the work in progress and experimental nature of the branch. The current state is not my proposal for a new "trunk", I'm still trying out stuff and have rewritten some parts of it already several times. So I really love to get comments about what it good, and especially what is not and questions about how stuff works, but please refrain from taking it as a final proposal of how the code is supposed to be structured. Rather take it as an opportunity to challenge ways of thinking and lets see what we can learn from it, maybe it will turn out just as a playground to try out ideas that could incrementally improve trunk. The current code not compiling is something I'm really sorry about and I'm curious as to the why, as SVN shows no pending changes here, and it compiles fine for me. Could you post the compile errors? Anyway, I would really like to get back to a productive discussion, as I think we all still have to learn a lot about the xna-way of doing things and I think we should try to get familiar with that in order to use the framework to its full potential. (Sorry if I sound a little pissed, but I think most of what is provided in terms of examples and documentation is more toy-examples and doesn't help with big projects, so we should try to figure it out together and not see it as a contest as to whoose way of thinking is the right one). Cheers, Rincewind

Hopefully next week.

And some more progress: I gave the GameState part of the game some refactoring. We needed to get a Game-reference into all things gamestate in order for them to use services. Since GameComponent is not serializable, we needed to introduce a way to inject the Game-object after a saved state has been loaded. This works now thanks to the GameStateComponent-class Additionally, since we don't want to remove and add Services in between, GameState data is now accessed through Services. I implemented this already for HumanBases, Research and GeoTime. One could argue that we could just have a single GameState-Service that returns the entire current GameState, but I think it makes it clearer what UI part uses what part of GameState if we keep it this way. Also, I refactored the Load/Save logic into a Service that is now being used by LoadSaveScreen. As always, this is work in progress, so expect quite a lot of stuff to be broken :-) (But don't hesitate to report those broken things here). Cheers, Rincewind P.S: This way a prerequisite to implementing the GeoTime Scheduler as I needed Research and Co. to have access to Services before they could actually schedule something. So this is next on my plate. (As well as GeoEvents as they got mostly disabled for now during this refactoring).

Update: - I fixed the BaseScreen to correctly show the floorplan. Some leftover fields from EmbeddedScene-Refactoring messed it up - Showing a dialog now stops the Frame's that are below it. By the way, this allowed to make Frame's Enable() method private and just hook it up to the GameComponents EnabledChanged-event. I guess we should really try to look towards XNA for solutions when trying to tackle a problem as most of it is already in there. About the push vs. pull, I think I have something even better, that combines the two approaches. We enlarge on the Event-Scheduling idea. What this means is moving the logic about counting down a particular time into the Event/GameTime-Parts of the game. This poses that problem that we have to tell the user how long a particular project is going to take, so we could just keep a reference to the scheduled event and a UI-Component could then ask it for the amount of time left. GameTime automatically counts it down. We could even have GameTime keep these events in a sortedqueue (kinda like the facility-building code currently does) and have it only count down the first one on a regular basis and the rest only if it's asked for its time left. What do you guys think? This would at least remove that millis-to-second conversion and custom handling of "things" to update inside each part of the model that needs it. Edit: this makes something else possible: we could then stop gametime to have the clock stop and still keep the "screen" running (e.g. to show a rotating model in xnet, would be nice to have that running even while we are in a dialog).

Not wanting to change the order of implementation, but what about having the buy/sell system first? As there's not much point in getting monthly funding if you can't spend it. And for now, just keep a fixed amound of cash coming in every month (so you can buy all those nifty Laser Rifles and have them sitting in stores ;-) ) On the other hand, the stats would allow us to actually map alien activity to countrys and adjust funding, so the player would actually get a reward for shooting down the ufos. As you can see, I don't know either... About the requirements, I think you pretty much summed it up. You could try to fit it into the Service/Component-Way of thinking already, even if you do it in trunk and not make it an actual Service. That way, moving it over shouldn't be that hard. Rincewind

That command stuff is kinda like the GeoEvent-System dteviot has introduced. It's currently not working as I need to refactor it, so the events keep a game-reference or get it passed into the Execute-Method (or Process, thats how it's called with GeoEvents), as they open up dialogs, etc where we need the Game reference. Will try to get some of that implemented this week. Rincewind

Isn't there an "Enabled" property in GameComponent that stops the calls to Update? I guess ScreenManager could then just "disable" GameTime once a dialog is up. About push vs. pull and the game ticks. I initially updated the ResearchTopics from the update method, but ran into the following problem: due to the limited accuracy of even "double", the research time was significantly off when using higher simulation speeds. On the 60 seconds speed, it was only a quarter of an hour per day, on the fastest, it just dropped several days for each gameday. Thats how the push concept with larger time steps came up. I still think that the AI needs to be run by Update (which possible also involves investigating if it holds up for higher game speeds), but for research, purchasing, etc. the pushmodel is more intuitive to code and we don't have to duplicate the code necessary to deal with the rounding errors. We could also introduce a timer-concept, so a component could register with GameTime to receive an event once a particular date is reached. Passing in the Game-object into each Component allows the Game-Property in the base class and access to the Game-Object from all components, after this initial refactoring is done, I don't think it's that much of a hassle and I really, really dislike having global variables (and static-members are just a nicer way of declaring them). I really like the way, you can "yield return", didn't know this existed and will change the code accordingly. I'll also look into the filtered topics method. I will take a look at the BasesScreen, I guess I missed something there as getting the Scene-based screens working was the last thing I did and I just wanted to finish it to a demoable state :-) Anyway, thanks for all the feedback, I might be able to come on irc tonight (tonight being in GMT -2), so if there's someone there, we could discuss this further. Cheers, Rincewind

[*]Issues with Strings.Designer.cs file into svn. It's autogenerated, which means it gets completely mugged when switching between english and deutch versions of VS. True, any ideas for a workaround? [*]I think you didn't see the Research classes that Red Knight provided. Yeah, I realized that a little too late. I now have my design changed a to resemble his. Discussed it with him on msn as well. [*]Remove Utils.LoadString(string resourceName, string fallback). If the resource string is not there, it needs to be added, not worked around. Hmm, I would rather have a game that falls back on the symbolic names than explode :-) Also, this way, CTD can easily add the "real names" step by step and we still have a working version. But I'm open to suggestions. [*]Add Copyright notice to files. Will do! [*]In GeoscapeScreen, when a topic has been researched, do NOT call TopicResearched() in Geoscape and then put up a dialog. The correct pattern is to define a new GeoEvent, and put the event into the Event queue for handling. Reason for this, is the Research dialog may involve going to diferent screens (e.g. XNet) Hmmm, I agree that there may be different actions required when something is researched. Nevertheless, I think a delegate/.NET event is the right approach for this. GeoEvent just reinvents a .NET-event system, I think. With my approach, handlers can be registered with ResearchGraph. The current dialog that pops up is just one way of handling that event. Again, just my two cents. Maybe we can discuss this a little on irc? [*]Please make sure all code you add has no warnings, and all functions have XML comments. So far, I added XML-Comments to all public functions. I didn't see any warnings left. Will check now, though. On a more general note, I think we have to change away from the c++ way of thinking. The xna-design is fundamentally different. Especially all the components/services stuff makes some things a whole lot easier. I branched to have a playground for the gui stuff. I will report what I find out here. (So far, all existing GUI-libs still seem to be either very limited (and not focussed on what we need) or rather incomplete). I'll keep working on it, though. Rincewind