Jump to content
XCOMUFO & Xenocide

Project: Fishbowl


dteviot

Recommended Posts

Based on discussion in this thread with Red Knight, I'm working on a terrain model that will work for the prototype, and provide everything it needs to, and I've also been looking at all the info I can find on rendering with XNA.

 

Question for the GUI experts out there (or anyone else who wants to answer) - how difficult is it to get CeGui working? We'll need a minimal menu system for the prototype, and I'm trying to decide whether to just put it in a separate window and use WindowsForms for it, or to actually use CeGui in the same window as the prototype rendering. Right now, I'm leaning towards a separate window for a menu. Anybody have a suggestion?

Link to comment
Share on other sites

Yes, go with a second standard WinForm :) if possible to the UI. Dont remember if it is posible right away, but could be very useful to test if it is posible.

 

Greetings

Red Knight

 

I've done a little checking ... yes, it is possible ... no, it isn't pretty. The Xna Game class likes to be the controlling application. You can use Xna stuff in a WinForms app, but you have to create the GraphicsDevice and ContentManager yourself ... for this prototype, that might not be a big deal, though ... I'll look into it some more, and see what I can do.

 

Travis

Link to comment
Share on other sites

Yes, go with a second standard WinForm :) if possible to the UI. Dont remember if it is posible right away, but could be very useful to test if it is posible.

 

Greetings

Red Knight

 

I've done a little checking ... yes, it is possible ... no, it isn't pretty. The Xna Game class likes to be the controlling application. You can use Xna stuff in a WinForms app, but you have to create the GraphicsDevice and ContentManager yourself ... for this prototype, that might not be a big deal, though ... I'll look into it some more, and see what I can do.

 

Travis

Check the forum I mentioned back in post #51, someone's posted the code to do it.

Or we can wait for XNA 2.0 to come out.

Link to comment
Share on other sites

Yes, go with a second standard WinForm :) if possible to the UI. Dont remember if it is posible right away, but could be very useful to test if it is posible.

 

Greetings

Red Knight

 

I've done a little checking ... yes, it is possible ... no, it isn't pretty. The Xna Game class likes to be the controlling application. You can use Xna stuff in a WinForms app, but you have to create the GraphicsDevice and ContentManager yourself ... for this prototype, that might not be a big deal, though ... I'll look into it some more, and see what I can do.

 

Travis

Check the forum I mentioned back in post #51, someone's posted the code to do it.

Or we can wait for XNA 2.0 to come out.

Here we are:

http://forums.xna.com/thread/16288.aspx

http://forums.xna.com/thread/20217.aspx

 

Now, time for some heresy.

X-Com1, 2 and 3 had multilevel (3D) battlescapes.

But UFO:Aftermath only had 2D battlescapes. (Yes, they had a hight map, so the field went up and down, but conceptually the battlescape was still 2D) It wasn't until Afterlight that 3D battlescapes arrived.

So, my thought is, what if we focus on a 2D (single level) battlescape. And leave moving to 3D until the final stages (Possibly even post v1.0)

  • how much development effort do we save?
  • how much game playablility do we loose?

Link to comment
Share on other sites

Now, time for some heresy.

X-Com1, 2 and 3 had multilevel (3D) battlescapes.

But UFO:Aftermath only had 2D battlescapes. (Yes, they had a hight map, so the field went up and down, but conceptually the battlescape was still 2D) It wasn't until Afterlight that 3D battlescapes arrived.

So, my thought is, what if we focus on a 2D (single level) battlescape. And leave moving to 3D until the final stages (Possibly even post v1.0)

  • how much development effort do we save?
  • how much game playablility do we loose?

For the fishbowl, I have no problems with a single level in the battlescape. It's easier to test and to get everything working properly and would save a lot of time. (You wouldn't need to bother artwork much). I wouldn't wait till post 1.0 to at least start work on a multi-level battlescape though.

 

That said, you lose the ability to use the Flying Suits or to see aliens floating. Those are the biggest drawbacks. Don't know how far you could throw objects with a capped ceiling height of 1 tile - there wouldn't be much of a trajectory to allow a long distance toss, everything would have to be a sidearm throw. Also, UFO sites would be rather strange with a ton of aliens showing up on the lower floor rather than spread out across multiple levels. But here again, it doesn't pay to set up the lowest level perfectly, as we would need to completely overhaul it when multiple levels are added (maybe not the graphics, but the mechanics). ^_^

 

- Zombie

Edited by Zombie
Spelling.
Link to comment
Share on other sites

Guest Azrael Strife
Yes, go with a second standard WinForm :) if possible to the UI. Dont remember if it is posible right away, but could be very useful to test if it is posible.

 

Greetings

Red Knight

 

I've done a little checking ... yes, it is possible ... no, it isn't pretty. The Xna Game class likes to be the controlling application. You can use Xna stuff in a WinForms app, but you have to create the GraphicsDevice and ContentManager yourself ... for this prototype, that might not be a big deal, though ... I'll look into it some more, and see what I can do.

 

Travis

Check the forum I mentioned back in post #51, someone's posted the code to do it.

Or we can wait for XNA 2.0 to come out.

Here we are:

http://forums.xna.com/thread/16288.aspx

http://forums.xna.com/thread/20217.aspx

 

Now, time for some heresy.

X-Com1, 2 and 3 had multilevel (3D) battlescapes.

But UFO:Aftermath only had 2D battlescapes. (Yes, they had a hight map, so the field went up and down, but conceptually the battlescape was still 2D) It wasn't until Afterlight that 3D battlescapes arrived.

So, my thought is, what if we focus on a 2D (single level) battlescape. And leave moving to 3D until the final stages (Possibly even post v1.0)

  • how much development effort do we save?
  • how much game playablility do we loose?

I think I remember multi-level missions in AM, the base capture missions? actually UFO: Aftershock does have multiple levels (specifically the UFO and base capture missions, maybe others).

 

I agree with Zombie 100% :)

Link to comment
Share on other sites

Yes, go with a second standard WinForm :) if possible to the UI. Dont remember if it is posible right away, but could be very useful to test if it is posible.

 

Greetings

Red Knight

 

Here's a version of ProjectFishBowl talking to a very simple WinForm. I went with the solution that loads a windows form as a child of the game form, so that they share the same message pump, to avoid threading weirdness.

ProjectFishBowl.zip

Link to comment
Share on other sites

For fishbowl go with single level, but multilevel is a planned feature for V1.0

 

Greetings

Red Knight

 

I think there's a fairly simple way to handle this for now - I can easily put in support for multi-level, but just disable it (by not allowing movement to any other level, or placing walls on any other level). That way, if we decide we need multi-level in the fishbowl, it's there, but if not, we don't have to mess with it.

 

Travis

Link to comment
Share on other sites

I had been looking over the code for a minute and I see a C++ way of thinking in it ;) ... I suggest to change all GetXXX style with Properties, Callback style objects with delegates, single cast, multicast and events :) ... And unify some interfaces, we can speak on MSN if you want about all that.

 

BTW take a look about the new features in C# 3.0 (.Net 3.5) it supports something named Lambda expressions, they can be implemented in .Net 2.0 (XNA version) using anonymous delegates and are very useful to decouple commands from mechanisms ;)

 

Greetings

Red Knight

Link to comment
Share on other sites

I had been looking over the code for a minute and I see a C++ way of thinking in it ;) ... I suggest to change all GetXXX style with Properties, Callback style objects with delegates, single cast, multicast and events :) ... And unify some interfaces, we can speak on MSN if you want about all that.

 

BTW take a look about the new features in C# 3.0 (.Net 3.5) it supports something named Lambda expressions, they can be implemented in .Net 2.0 (XNA version) using anonymous delegates and are very useful to decouple commands from mechanisms ;)

 

Greetings

Red Knight

 

This all sounds very cool, but complex. Is it something we can refactor in later?

Link to comment
Share on other sites

For ease of development, I think integrating scripting (Lua?) into the battlescape would make AI development *MUCH* easier. Each element of the battlescape could export a defined interface to the scripting system, and the scripts could handle behavior. Computation intensive tasks could be programmed into the battlescape in C#, and called from scripts. I would prefer scripting for AI and object behavior, over .NET DLLs because it would expand the pool of potential developers, and reduce some of the risks/vulnerabilities associated with using plugin .DLLs. That being said, I'm not 100% against plugin .DLLs, as personally I could probably develop something faster in C# than in Lua, but I think on the whole, using a script language would be a better choice.

I have to strongly disagree with you on scripting.

So far as I am aware, there are only three good reasons for using scripting. And none of them apply to the XNA version of Xenocide

  • With many modern games, it can take 30 to 120 minutes (or more) to build the main game engine. This means that it's not possible to quickly "tweak" the main game logic and see the effect. So interpreted scripts are used to allow fast experimental iterations. With our current XNA Xenocide, this isn't an issue. Incremental builds take less than 10 seconds (at least on my PC.)
  • The C and C++ languages have brutal learning curves and are intolerant of mistakes. Making them unsuited for the relatively unskilled users. C# is much nicer in this regard.
  • LUA/Python are more productive. Well, they are more productive than C, and to a lesser extent C++ (although good libraries e.g. boost helps to lower the difference) But the productivity difference between Python and C# is not that great.

And some other thoughts.

  • Usng .Net DLLs would increase the pool of potential developers, as they could write the DLLs in any .Net language. Including Python or Visual Basic.
  • Do NOT underestimate the cost of building an interface that would allow LUA to call into the C# engine. From what I've seen, it's ever more work than doing the job for Python. And in the old Python code, the python interfaces were a considerable effort.
  • Actually, if we really wanted, with XNA we could write Xenocide entirely in Iron Python. (Or C++/CLI)

Link to comment
Share on other sites

I had been looking over the code for a minute and I see a C++ way of thinking in it ;) ... I suggest to change all GetXXX style with Properties, Callback style objects with delegates, single cast, multicast and events :) ... And unify some interfaces, we can speak on MSN if you want about all that.

 

BTW take a look about the new features in C# 3.0 (.Net 3.5) it supports something named Lambda expressions, they can be implemented in .Net 2.0 (XNA version) using anonymous delegates and are very useful to decouple commands from mechanisms ;)

 

Greetings

Red Knight

 

This all sounds very cool, but complex. Is it something we can refactor in later?

You are trading in your design Interfaces bindings with methods calls. So you have to design up front using that method, it is a quite different way of thinking. For instance, your design motto have to be: "I can only make one decition, I cannot decide at all". It is sort of a Template Method pattern without the inheritance. You inheritance will only take care of "data" and "state" trough interfaces, methods "commands" are on the implementors hand. It is difficult to understand at first but when you try it out you will find out how powerful and mantenible is the code you end up writting.

 

Greetings

Red Knight

Link to comment
Share on other sites

×
×
  • Create New...