Topic: Opinion for Gaming

[[UFP]Exeter]

I would like to know others opinions regarding development of a game, should it me C++ or C# and why.  To avoid an open ended discussion here are some constraints:

1)  This would be a Star Trek based game, 3D graphics etc, like a merger of Bridge Commander with some of the gaming aspects of SFC3
2)  Current technology, performance difference between C++ and C# is less than 5%
3)  Both have the capability to utilize muti core processing
4)  PC based only, so no concern about other OS, yet.
5)  Conversion for C# to c++ is straight forward if the game needed to be ported, but reverse is not so easy.
6)  The development time difference between them is significant, C# is at least twice as fast to develop and deploy code.


Given these items, it would seem to me the decision come down to, 5% better performance or half the time to get the game deployed.  And this is based upon my own experience as I code in both.

Your opinions?

[Javora]

Portability is key and speed of coding is key here.  Because of points 5 and 6, coding in C# should be a no brainer.

[d4v1ks]

In my opinion you stumble in the most fundamental aspect. Since i learned to program i've made some games at basic, pascal, assembler, c++, visual basic, etc etc. The language is a means to an end, not an end in itself.

C# 

[[UFP]Exeter]

A few years back when SFC 4 was being discussed the posts were adamant on c++, with no reason other than faster, and at that time it was.  But improvements in managed languages, C# in particular and the NET framework have reduced this difference significantly.  This is the theory.  To validate I ran my own benchmarks, I build an identical game structure in C++ and C#, which included 3D rendering, the background also 3D and audio.

As for missing the basic tenant, I think one is being missed, the right tool for the job.  Given what I imagine in a 3D game, it is possible to have as many as 60 3D models on the screen.  (Main ships, fighters, torpedoes, planets, asteroids etc) the tool chosen needs to be able to move (physics), detect collisions, and render the scene.  So the choice of a language would also dictate what libraries are available to handle this kind of performance requirement.

I would also add, that if there was some desire to ever port this to any console game, C++ may be required along with the license and sdk neither of which are free or cheap.

But with Mono, and it keeps getting better, there is the possibility to deploy to other platforms like UNIX that can run MONO, provided we use C#.

Of course all of this is mute if I do not have the background to accomplish or lead the effort. 

I am currently an IT Project Manager, but I achieved this goal working my way up as a developer.  My background includes developing programs in the scientific community and business.  I maintain fluency in C++ and C#, although I have developed code in many other languages including assembler, Java, FORTRAN and Ada.

I am currently communicating with Frey, and we are working on finalizing a design to be used in the creation of AFC 4.  A new effort.  Depending on the design I have two different game structures I have been working on over the last year.  One in C# and one in C++ (as mentioned previously).   This has not started before as I was assisting Strat with the EAW conversion that I hope to see released very shortly as we finished the coding.

Which leads to the bottom line of this post.  What do the customers want, customers being those that will play the game.  And the options are simple:

C++ for slightly faster performance.

C# for significantly less development time.

I have posted this poll on a few different sties, without the specifics as to why, and it is interesting.

83% prefer the faster development
32% of those responding have some background in development.

[Starfox1701]

I haven't done any thing like this out side of ODF (A1/A2/ Legacy) moding some python code tinkering (BC) since dos basic. I feel I need more info to give a good answer.  The important questions are as follows.

1. which code is going to allow for the longest lifespan of the game allowing it to make best use of improved hardware, not just today but 5 years from now ect...?

2. which code is going to be the most moder friendly?

3. which code will allow for the best future expansion of the game, new systems and abilities should the developers or moders chose to do so?

[[UFP]Exeter]

Starfox, answer varies but i will try to answer

1.  Greatest lifespan is hard to answer.  Both languages will be around for a long time.  The key is graphics.  The intent is to use a third party graphics library that is much easier than Directx itself.  Currently know good, low cost (free) has fully operational Direct x 11 support.  And for me I will NOT code a game in XAML.  The main library I would use Irrlicht.  For C# we would use the IrrlichtLime wrapper around the Irrlicht library.  I have tested both ways, and works well.  And DX 11 drivers are under development.  Overall the game will REQUIRE at least dual core, but will utilize 4, and I am looking into utilizing the GPU on a DirectX GPU also.  From that aspect this will be probably require Win 7 to play but that is not decided yet.

2.  Modder friendly is independent of the code base.  Some for of scripted and other capabilities to be built in.  I would like to make this very modder friendly.  That if you desired to make this a Star Ward game (god forbid) you could, including models, graphics and sounds.   Also missions I hope to have via external mission files that are scripted and will not required a compiler (or at least a fee one) to build or change missions.  Right now under consideration is XML, LUA and C# itself (the free compiler can be used).

3. Future expansion is independent of the code base.  The game itself will be coded in a modular design, to allow changes, upgrades to be done.    In this aspect c# is superior and it uses the main exe and DLL's, allowing for updates to a DLL as required.  C++ can use DLL's also but the versioning to prevent a mix-up of dll's that can prevent the game from running is an issue.

For both many of the key gaming elements such as the combat mechanics etc, will be stored in an encrypted external database to be read outside of combat.  This will allow updates to the combat system without patching the game.

I should mention all third party libraries we use will have source also available to avoid issues we ran into trying to update EAW.

[Captain Adam]

.

[[UFP]Exeter]

Adding new weapons would be difficult as we need to maintain a balanced game.  And avoid god weapons or vessels.  But the combat system such as damage, range etc, is stored in encrypted data, but by a class level, such as a MK VII beam.  You can add your own weapon, the name, the graphics etc, and utilize the MK VII combat specifications. 

This also goes for ships, a Heavy cruiser would have a range of specification.  A limit of total weapons and types.  You can configure exactly what weapons go where.  Ship specification would be the same for each race as far as the class goes, but how you configure it is up to you.   We handle the differences by races with a racial and a relationship bonus.  For example a Romulan system may only be available to those on friendly terms with the Romulans.

But, changing graphics, names, ship designs, all customizable.

[Captain Adam]

.

[Starfox1701]

Sounds like C# is the best option, which would you chose? On the note of things like super weapons and god ships, and for give me if this sounds harsh, but isn't it a bit condescending for the programer to limit a moder's options for tinkering with his personal install just to preserve your own idea of balance? The need for identical instals for multiplayer will prevent these thing from getting in there unless that what all the players want. Balance the game however you want but please don't stop us from being able to re-balance it is we want to try something different or for example the new ships or races require something different. It is not a necessity to hard code the balance.

[Captain Adam]

.

[[UFP]Exeter]

Interesting points.   If I can figure out a way to ensure in a multiplayer game that one person did  not create a "God Ship" the others do not know about I thin that ability to create and modify at will can be arranged.  And the limits will be in a database so it would be possible to easily allow these "set" values to change.   What I am thinking is to allow greater flexibility in the script for missions.  So a "God" ship could be part of the missions.

Oh, I have a model for 2 god ships for multiplayer missions so there will be some God ships in  the game.

C# does appear to be the best option.  But there is a cost.  It cannot use pure C#, so wrappers are required or we learn DirectX 11 and go for it.

The C++ route has a couple hidden advantages.  The network library has multi thread already.  The graphics library is being updated to include DX 11.  And the physics library is being upgraded to use the GPU (Requires DX 11 capable GPU).  So if we make the system requirements higher (dual core minimum and Direct X compatible GPU), we will have as much as 20% performance improvement. 

To get hos improvements in C# would require some extra coding so the advantage of faster coding decreases.

My choice?  As much as I want this done sooner,  I want cutting edge.  I want dual core minimum.  I want DX 11 GPU required (not the drivers).  I want this so fast that we can do better graphics and not worry about slowing things down.  Can we make a good game in C#, yes.  But I want a kick-ass game that players will want a way to slow it down.  And we can make this game that if you have them, it will use the GPU and 4 cores. 

The reason for the opin ion, is the tradeoff.  I mentioned the 3% performance but today I got a hold of a copy of the newer physics coming out and tested.  The physics alone was 22% faster as it ran on my DX 11 compatible GPU.  And this CANNOT be done in C# unless you code in DX 11.

[Captain Adam]

.

[[UFP]Exeter]

we are in the design phase.  So we can make changes.  And I expect once release there will be updates.  We are using third party libraries (why reinvent what works) but we have the source for all.  This means we can change this as we choose going forward.  And as it is a community (literally) and the code (all of it) on Dynaverse SVN, we can change it forever.

Modding is not an afterthought, it is built into the design.   Key data is stored in an encrypted database, and some other is also due to copyright.  But, a modder can build their own databases and literally change anything related to game play.  And details will be released to assist.

To fully mod a knowledge of SQL, XML and possibly LUA may be required.  Not there yet.

To build your own missions, probably LUA

[[UFP]Exeter]

Except this will be a community effort.  I could handle all the programming (15+ years programming in C++) but I do not have the skills to create the models or the graphics we need.

So I ask others opinions. 

There is alot of work.  And something we need 100's of is storylines to build missions from.

[Captain Adam]

.

[Starfox1701]

Is it possible that a file system similar to Armada's ODF/Classlable system could be used to simplify the process? I am uncertain how difficult that is to code from the ground up but from experience know it within it's constraints it is very flexible and functions very much as a plug and play system. Lines of code can be left in a single file and later files can reference back to it. Whole strings of files can be used to define variants of ships with the individual ships only requiring the new or altered information. Also Classlables can be stacked to provide some interesting effects or vary abilities. If you are unfamiliar with this setup I can add that ODF stand for Object data file. Classlables are tags that refer to specific hard coded AI behaviors or effects. Examples include Starbase, constructionrig, cannon, launcher, and phaser. An example of stacking would be cannon in the base weapon odf and phaser in the ordinance odf. Between the to files you could code anything from various to hit modifiers, sound effects, the sprite used, damage ect.. The weapon was very customizable.

On the not of model format it might be worth while to upgrade that. But if that is done we will need new importers and exporters for our various modeling software. Also with the processing power you plan to rig into this game the models might endup being of a quality that is to high for milkshape to handle. anything with more then 60,000 polies, 30 mesh groups or more then 1 2048X2048 texture or 230 joints is beyond the program's design limits. It will not render anything beyond the poly limit, those parts are lost, and tends to crash when dealing with to many joints.

[Javora]

the creation of AFC 4.  A new effort.

AFC 4 ???  Was that a typo or a new name?

Which leads to the bottom line of this post.  What do the customers want, customers being those that will play the game.  And the options are simple:

C++ for slightly faster performance.

C# for significantly less development time.

I have posted this poll on a few different sties, without the specifics as to why, and it is interesting.

83% prefer the faster development
32% of those responding have some background in development.

While it's been 20 years or more since I took Assemblers, let alone Fortran, Pascal, Basic etc.  I do understand the idea of speed, portability and performance...  I also understand the idea of maintenance as well.  How much time are you willing to spend on maintenance after the game is released and are you willing to spend more of that maintenance time with C++ ?  Ok let me ask this, how long would it take to convert a full game from C# into C++ ?  What's stopping you from coding the game in C# and then making a conversion copy in C++ as soon as your are finished?

I also think you might want to consider other platforms as well.  These other platforms, Android based tablets for example might not have the horsepower of a PC but might bring in more of a fan base.  I'm throwing this in only because of how many people are moving away from PC's toward other platforms.  But if you do consider other platforms, what language will you need then?

Oh and one more thing, of the 32% that had some background in development, how many preferred faster development?

[[UFP]Exeter]

Adan,
The currenly supported Model formats are:
    3D Studio meshes (.3ds, r)
    Alias Wavefront Maya (.obj, r/w)
    Lightwave Objects (.lwo, r)
    COLLADA 1.4 (.xml, .dae, r/w)
    OGRE meshes (.mesh, r)
    My3DTools 3 (.my3D, r)
    Pulsar LMTools (.lmts, r)
    Quake 3 levels (.bsp, r)
    DeleD (.dmf, r)
    FSRad oct (.oct, r)
    Cartography shop 4 (.csm, r)
    STL 3D files (.stl, r/w)
    PLY 3D files (.ply, r/w)
    B3D files (.b3d, r, skeleton)
    Microsoft DirectX (.x, r) (binary & text, skeleton)
    Milkshape (.ms3d, r, skeleton)
    Quake 3 models (.md3, r, morph)
    Quake 2 models (.md2, r, morph)

Because we are not using any of the original codebase from previous games, it is unlikely we will be able to use mods from those games.

[[UFP]Exeter]

StarFox

I am unfamiliar with Armada's ODF/Classlable file system.  Is this a Mod method used?  Although how SFC4 will be modded is uncertain I am leaning toward LUA for scripting for mods and missions.  XML is also under consideration, and that is used for base configuration data.

From reading your post it seems it is very similar to the capability of LUA.  LUA adds the capability to actually run code from the script.

As for the models, I am not planning on designing our own custom format.  I will use standard formats.  I currently have tested using .3DS, .ms3d and .OBJ formats.  Blender formats are not supported but it can export into supported formats.