Possible Future Direction (personal view)

FreeCiv is open source. Is it possible to use that as a base until a more advanced engine can be built?

FreeCiv is based on C++. We would like to build something on C#.
This very fact is a very time consuming one if we would decide to continue on freeciv.
I also hope to create some method of importing all Civ IV graphics asserts, and Koshling hopes to do the same with most of the xml data. Designing things from the start to allow this helps a lot!
The goal of this project would be to start fresh and with no restrictions. Using freeciv as base would again put restrictions on the project.

Note: there cannot, ever, be a discussion about C# and .NET.
C# is the best language for .NET and .NET makes it very easy for modders to add code in different languages. It could happen that a single mod contains python, javascript, ruby, visual basic, and just because it can, some COBOL scripts.
This all, without us, the creators of the initial engine, having to do anything extra for this functionality. It is a given feature of .NET!
 
I also hope to create some method of importing all Civ IV graphics asserts, and Koshling hopes to do the same with most of the xml data. Designing things from the start to allow this helps a lot!
The goal of this project would be to start fresh and with no restrictions.

Now that sounds like a great way to start. Not being a coder, thats all i can say for now, but many many thx to all for helping on this.;)
 
In this post I want to address two things.

1. Help for the graphics engine.
2. Setting up some communications structure for the project.

Edit: Outdated: see my next post.
Edit 2: Not Outdated anymore
1. Help with the graphics engine.
While going though the tutorials of MOgre I found out that MOgre supports only a single 3D object defining filetype: the Ogre .mesh type. Civ IV uses the Gamebryo .nif type (and possibly several associated types, but I'm not an expert on the .nif type). This means that if we want to use the extensive databse of existing models for Civ, we need to convert the models. Either runtime (allow reading of the nif files) or create a conversion tool. While I keep myself busy with the code to generate the map and stuff, it would be helpfull if someone can take a look into these filetypes and see what is possible.

2. Setting up some communication structure for the project.
If we are starting this project up, then I suggest we create some webpage/forum where we can put all things related to this project, rather than a single thread in the C2C forum. I own a home server with more than enough bandwith and no data restrictions, so I can host a webpage if needed. It is a window 7 platform, so any linux related software would need to run in on a virtual machine.
I have plenty of ideas on how to do this, but no time/interest/experience to set something up. So start your discussions on how to do this. Once you guys agree and find a victim that is going to create/manage this, he/she can send me a PM to get access to my server (if needed).
Some examples that would be on this page/forum:
- Design decisions (C#, the structure, networking options, etc)
- Feature discussions (e.g. tiling).
- Technical discussions (like the stuff I and Koshling posted in last few posts).
- Status of the project.
- etc.
 
In this post I want to address two things.

1. Help for the graphics engine.
2. Setting up some communications structure for the project.

1. Help with the graphics engine.
While going though the tutorials of MOgre I found out that MOgre supports only a single 3D object defining filetype: the Ogre .mesh type. Civ IV uses the Gamebryo .nif type (and possibly several associated types, but I'm not an expert on the .nif type). This means that if we want to use the extensive databse of existing models for Civ, we need to convert the models. Either runtime (allow reading of the nif files) or create a conversion tool. While I keep myself busy with the code to generate the map and stuff, it would be helpfull if someone can take a look into these filetypes and see what is possible.

2. Setting up some communication structure for the project.
If we are starting this project up, then I suggest we create some webpage/forum where we can put all things related to this project, rather than a single thread in the C2C forum. I own a home server with more than enough bandwith and no data restrictions, so I can host a webpage if needed. It is a window 7 platform, so any linux related software would need to run in on a virtual machine.
I have plenty of ideas on how to do this, but no time/interest/experience to set something up. So start your discussions on how to do this. Once you guys agree and find a victim that is going to create/manage this, he/she can send me a PM to get access to my server (if needed).
Some examples that would be on this page/forum:
- Design decisions (C#, the structure, networking options, etc)
- Feature discussions (e.g. tiling).
- Technical discussions (like the stuff I and Koshling posted in last few posts).
- Status of the project.
- etc.

We should probably start a Sourceforge project and use the project-related discussion facilities there, as well as use I as a document repository.

On the asset format issue, I don't think we have anyone that can help you with that - graphics experience was what we were utterly missing, which is why your offer was so welcome (but it does mean you're a bit on your own on the that side of things I'm afraid, at least currently)
 
If this were to happen how much of C2C would be portable without a lot of work?

None legally. You can only use assets in civ mods with the civ engine, under the terms of the EULA. That would also apply to the art, so we would have to get entirely new art for AXXXXE.
 
as stated here
http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=14645
mogre can be built for x86 and x64.
atleast there is some test builds available.

MANY THANKS!

Not only does that post have a 64 bit build, but after some more struggeling I can now set up my own MOgre project. The tutorial project, tutorials and release all differ in or provide horrible ways of setting up a project. The guy who build those 64 bit versions is a lot more consistant.

So after an entire day of struggeling I now see a console window pop up and disappear after 0.5 sec :P

As for other options, I would have to use Horde3D, which also has a good C# wrapper (maintained by the devs of Horde3D!)
 
i dont see much progress from 2011

on russian gamedev forum i see many good references about http://www.panda3d.org/

and maybe you should instead of horde3d look at https://code.google.com/p/urho3d/

Panda doesnt have proper C# bindings. So I have to stick to MOgre or Horde3D.
MOgre has a more mature community with more active users, while Horse seems to have a more devoted core developper team.

I'm going to see which of the two is easier to use when we keep in mind that we need to convert all the asserts from Civ. This means it will take some time before I get something simple working, but we will end up with a better result.
Also important will be the possibilities for GUI elements and text. Most games written in these engines did not make intensive use of text, unlike Civ. I have already seen that MOgre can handle true type fonts without any effort on my side and has a build in system for GUI's, and several libraries that allow advanced GUI's.
I think that if I find a reasonable way to get Civ assets into MOgre, I'll stick to MOgre. I'm also gonna stick to the current version of MOgre since the next batch of features they are porting from Ogre mainly concert drawing/generating terain, something I think we won't need and this build was custom made by someone who applied several optimizations and neat tricks.
 
<snip>
I'm going to see which of the two is easier to use when we keep in mind that we need to convert all the asserts from Civ.

As I said above, we can't legally do that. Every code and art asset will have to be new (or at least not connected to civ).
 
As I said above, we can't legally do that. Every code and art asset will have to be new (or at least not connected to civ).

Are you sure?? I thought as LONG a person/consumer does NOT get any money WHAT SO EVER, it would be ok??
 
Are you sure?? I thought as LONG a person/consumer does NOT get any money WHAT SO EVER, it would be ok??

Here is the relavent section of the BtS EULA.
USER CREATED CONTENT: The Software may allow you to create content, including but not limited to a gameplay map, a scenario, screenshot of a car design or a video of your game play. In exchange for use of the Software, and to the extent that your contributions through use of the Software give rise to any copyright interest, you hereby grant Licensor an exclusive, perpetual, irrevocable, fully transferable and sub-licensable worldwide right and license to use your contributions in any way and for any purpose in connection with the Software and related goods and services, including the rights to reproduce, copy, adapt, modify, perform, display, publish, broadcast, transmit, or otherwise communicate to the public by any means whether now known or unknown and distribute your contributions without any further notice or compensation to you of any kind for the whole duration of protection granted to intellectual property rights by applicable laws and international conventions. You hereby waive any moral rights of paternity, publication, reputation, or attribution with respect to Licensor&#8217;s and other players&#8217; use and enjoyment of such assets in connection with the Software and related goods and services under applicable law. This license grant to Licensor, and the above waiver of any applicable moral rights, survives any termination of this License.

There is no reason why the CFC modders couldn't help us with new art assets (that was my plan, once we got something going to promote it and get attention here), but we can't recycle assets.

Edit: We also couldn't use NIF, because IIRC that is a proprietary format of the Gamebryo engine. That however doesn't make me sad, the civ graphics look horribly old compared to modern games.
 
Here is the relevant section of the BtS EULA.


There is no reason why the CFC modders couldn't help us with new art assets (that was my plan, once we got something going to promote it and get attention here), but we can't recycle assets.

Edit: We also couldn't use NIF, because IIRC that is a proprietary format of the Gamebryo engine. That however doesn't make me sad, the civ graphics look horribly old compared to modern games.

I still dont see where it says we cant do what we intend to do, it just says that the Asset that you put here on CFC, from what i interpret?? I think your reading in-between the lines?? Let me as Thunderfall. He's good at legal stuff.

EDIT:

I just PM'ed him.
 
I still dont see where it says we cant do what we intend to do, it just says that the Asset that you put here on CFC, from what i interpret?? I think your reading in-between the lines?? Let me as Thunderfalls. He's good at legal stuff.

It says any content, not limited to what is listed in the first sentence. Also, the original and Warlords licenses were even more strict than that, and lots of art was created in those days, so it seems to me like we should just avoid reusing assets. Also, see my edit about the NIF format and why we can't use that either.
 
Here is the relavent section of the BtS EULA.


There is no reason why the CFC modders couldn't help us with new art assets (that was my plan, once we got something going to promote it and get attention here), but we can't recycle assets.

Edit: We also couldn't use NIF, because IIRC that is a proprietary format of the Gamebryo engine. That however doesn't make me sad, the civ graphics look horribly old compared to modern games.

True. We will need a lot of new models and such, but modders have made tons of models that are not a property of fireaxis (unless fireaxis turns out to be really evil).
Now I think of it; These models are most likely not made with .nif as working file type. Given that there are various exporting tools for the Ogre file types, it must be possible to export them directly to the Ogre files (if the source models are available or if the modelers want to help us).

Now to tell you guys what I came here for: A small status update:
I managed to convert a frost giant .nif from FFH to the Ogre .mesh type and display it.
This has given me an insight in the problems with converting .nif files:
- The result looks discustingly bad, (partially because it aint animated, hence in the default, gliched pose).
- I don't know how to import/export the animations. It should be possible, both on the side of Blender import scripts and Blender export scripts, but it aint working with the default settings.
- The work flow is horrible: Import a .nif, export to geometry, skeleton and material files (since I'm not used to blender this takes some time), manually edit the material files and sometimes the file names (remove lighting, etc), find the right texture (I have not yet found a concrete way of knowing 100% sure which one is the right texture: swordsman.nif does not use swordsman.dds, but is actually a frost giant which uses the berserker.dds all three files are in the same folder of FFH?! ) and finally convert all exported .mesh.xml data to binary .mesh data.
At this point I have not seen a file which describes the animations yet! The skeleton.xml export only contains the bones of the model...

But this shows it is possible to convert the .nif files!

I think I would end up with the same hell if I try Horde3D, so this leads to the conclusion that new assets would be a great improvement.
Exporting scripts exist for Blender, Maya, MilkShape and Houdini. Possibly even more, but these are the ones I found pretty fast on the Ogre site.
Besides these exporters it is a piece of cake to transform static models from the wavefront obj format to the Ogre .mesh.xml format and then use a tool to convert it to the binary .mesh format. (I think it takes about 1-5 minutes per model if done by hand, or 30-90 minutes to write a script/program to do so.)

Please note that creating an engine and the assets that create an ambiance as rich as that of Civ will take a lot of time. Although the graphics may be technically better, they will feel horrible for a long time. Examples of stuff that simply takes time to implement: Battle cam, unit view in civelopedia, civilopedia itself, all GUI elements of Civ (unit pics of units on tile, little nobs that tell whether they have movement left (in C2C they even display health), etc).

So all this leads to an important question that I need answered to continue:
Can I assume we have assets in the Ogre file formats (in the future)? If so I can continue creating the engine that can uses them. Otherwise we need to discuss on how to solve this problem. I don't have the time to create a graphics engine and keep myself busy with all the assets at the same time.

A frost giant in MOgre: (large image)
Spoiler :
1360885407379.jpg
 
True. We will need a lot of new models and such, but modders have made tons of models that are not a property of fireaxis (unless fireaxis turns out to be really evil).
Now I think of it; These models are most likely not made with .nif as working file type. Given that there are various exporting tools for the Ogre file types, it must be possible to export them directly to the Ogre files (if the source models are available or if the modelers want to help us).

<snip>

Almost every model on CFC uses a stock animation, and/or is based off of a firaxis model. So, combined with the EULA I'd be very leery of using civ content for this. 2K (who owns Firaxis now) would probably be within their rights to come after us for that and I want to preempt that by making sure AXXXXE is a clean break from any BtS stuff. It does also as you said create conversion issues technically, so that would be another reason not to do that.

As for engines, I'd suggest staying with mogre, as the core engine is still the C++ OGRE engine, and that will give us performance gains.
 
Yeh, just assume that models will be developed. To get things functionally working we just need crude stand-in models, and can simply color a small set of those to distinguish a few units while we work on engine development.
 
Yeh, just assume that models will be developed. To get things functionally working we just need crude stand-in models, and can simply color a small set of those to distinguish a few units while we work on engine development.

I figure once we have an engine the graphics people on CFC will come and help. Sort of "if you build it they will come". Let's focus on getting a graphics and data engine going for now.

Do you intend to write any more blog posts about the data handling part of the engine (which we can discuss and hash out in abstract while xanhou is working on graphics)?
 
Back
Top Bottom