Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

Attempt #2

Here you can find anything related to the Open Source, Freelancer like game project Openlancer.

Post Fri Dec 16, 2005 2:55 pm

Yeah....I have a game engine, but I aint doin anything on TLR.

It still needs work though, a few days and it'll work on other systems than windows 98.

But when Its done, I aint doin ANYTHING to do with openlancer on TLR, I really have HAD IT with this site.

Post Fri Dec 16, 2005 2:55 pm

Which do we use: VB.net or C++?

Alrighty, time for a "megaburnistic" post. As you all know i originally planned for Openlancer to be programmed primarily in VB.net and simply use any other .net language as an add-on. Because of the recent reforms to the project, the question of "which programming language do we use?" is up for grabs once again. In this post i will outline the pros and cons of both languages and give you 4 possible programming scenarios.

VB.net
PROS: Visual Basic is by far one of the easiest languages to learn, and is also rather powerful for a BASIC-based language. It allows for a lot of advanced functions in an easy-to-learn environment. Its also easier to work with, is more forgiving, has better intelli-sense than any other language, and is generally easy and quick to program in. VB.net applications or programs are usually made almost twice as fast as a C++ program is made, with the same functionality. If we are going to get any new programmers, this is the language they will be learning. Also, a recent "VB Express 2005" development environment is availible for FREE! This goes for all .net languages and the day is ripe for new learners! I highly reccomend this series of development environments for professionals as well.

CONS: Lets face it: VB.net is not that fastest thing on earth. C++ is marginally faster, although the .net framework evens out the differences a bit. Visual Basic is also not quite as powerful as C++ and C++ is much better suited to graphics and games in general. Visual Basic was never really meant for making games, although many people have set out, and succeeded, in proving that it can be used in games. OVerall the main disadvantage that we will be looking at is the speed deficit.

C++
PROS: C++ is the fastest language out there and the most powerful language (excluding assembly code, which shouldn't even be classified as human-readable). Its main advantage over Vb is speed. C++ is faster than visual basic and is able to better interface with DirectX. It usually has better graphics engines as well. Um, thats it really. More powerful and Speedier.

CONS: C++ has one big disadvantage: Its difficult to use. It has an enormous learning curve, is confusing, and is a pain in the but to use. It may be faster but it is hindered by its extremely low, or even nonexistant ease-of-use. A large amount of the general community would be cut off from this part. Visual basic is simple enough that you can usually use a bit of common sense to change a few variables. C++ is gibberish.

Possible Setups
1. VB.net engine/C++ combo: With this, the main game engine is programmed in VB.net, although a large majority of modules are written in C++ or VB.net. The advantage to this setup is that normal people or people with little programming experience should be able to edit the main game engine without too much trouble. the disadvantage is, of course, speed.

2. C++ engine/VB.net combo: This setup is a core engine run by C++ with various VB.net modules, although a large portion would probably still be coded in C++. Advantage: Speed and adaptability. With a C++ core we can have very high speeds and a large amount of adaptability while still having modules written in VB. Unfortunatly, this pretty much puts the core of our game off-limits to the casual modder. Plus i'd have to learn C++, and that sucks

3. Total VB.net: This stipulates that the entire game, including modules and add-ons, should be written in VB.net and no other language. This is stupid, becuase we are bound to need a lot of C++ support. Not reccommended

4. Total C++: While this is the most "professional" and speedy of the options, it is also the most limiting. The casual modder would stand no chance of editing the game engine or any of this modules. And i don't want to learn C++ This is a possibility, and its slightly better than choice 3. I still perfer the combos.

Over all, my prefence for these would be 1, 2, 4, 3, in order of how much i like them.

C# Examination
C# is another language thats entering the playfield and i consider it to be another iteration of C that leans more toward Visual Basic. I have learned the basics of it and i believe it is a nice language, one that takes the best from both C++ and Vb.net, although its still very new. The possibility of C# modules should be considered and i see nothing wrong with having some C# modules in out game. A C# game engine, however, is strongly discouraged for the fact that not too many people know C# and i'm not sure of its capabilities.

We should be sure to keep C# on the drawing board, however.

Conclusion
Well, i hope you liked my overview of the programming languages and i hope that we can figure out which one we are going to use.

Post Fri Dec 16, 2005 3:23 pm

REMEMBER! The openlancer forums are open and functional! Register there!

Post Fri Dec 16, 2005 5:13 pm

C# is derived not from C but is a combo language of C++ and VB.NET. It is way more powerfull than VB.NET. Especially when it comes to building components (controls, or function DLL's, Ect ...)

VC++.NET is by far the most powerfull programming language for windows environment (IMHO) and is what 90% of all game development studios/groups use to create thier core engine.

What you could do is this, get ppl on the team that are experienced in the VC++ language. Have your core game engine in C++. ANd when you build up a scripting language for it, use C#. C# works awesome as an interprated language (and is not a large learning curve from VB.NET), where VB.NET may be a bit limiting in it's capabilities.

Just somethign to think about.

Post Fri Dec 16, 2005 5:17 pm

Well, Hobbes, you sort of just restated what i said in my post...

In any case, C++ has the advantage of being fast and powerful, but has the disadvantage of being a pain in the but to use.

EDIT: And i'm already been hard at work on a script engine in VB.net (since its the only language i'm comfortable with). I'm not sure i want to recode the entire thing. On second thought, i CANT recode it in C#, i don't know how.

EDIT2: After much discussion i have decided against using the Torque game engine because it is not compatible with Visual Basic, and i want our core game engine to be compatible with VB. However, i believe that our core game engine, which would in fact merely load all of the DLLs and not do much more than that, should be in C++. This also gives us the option of upgrading from Truevision to a better graphics engine that runs with C++.

But i must stress that the core game engine should only provide a hub for the dlls and not contain much else. All the real code should be in DLL files so that, if the need arised, we could have a core game engine made in C++ and DLL modules that are Visual Basic, J#, C# and C++.

Of course, i must prepare for the inevitable. You all want to use the Torque game engine, don't you? -_-

Hobbes has also suggested the NovoDex physics engine.

Edited by - Blackhole on 12/16/2005 5:55:12 PM

Post Fri Dec 16, 2005 6:26 pm

NovoDex,

I can't stress enough the power of this physics engine. I won't even bother to try and explain it here, i would not even come close to giving it any justice.

But i will say this:

1) NovoDex is free to use (as of my last look) for none commercial use/

2) it was used in Unreal tournament 2003/2004 (but the game did not use the full potential of the engine.)

3) it provides TRUE rag doll phyisics.

4) it provides TRUE real to life (as much as possible) world physics. (this is something FL lacks in a HUGE WAY).

and this is just scratching the surface of it's power.

-----

Now on to the Torque game engine.

1) no it does not support a Space sim style game 'out of box' but over the last while i have been recoding major parts of the game engine to support space flight and large system exploration.

2) TOrque (refered to here after as: TGE) has a proprietary very powerfull scripting language that is C#/C++ like. WHich is not a huge learnign curve for the VB or C++ programmers out there.

3) I have a Legit license to the TGE Source code. So no worries about lawsuites.

4) there are several full blown IDE software packages available for the scripting language of TGE (some free, some not)

5) TGE has model exporters for the folling Known 3d Modeling applications: Lightwave 3d, Milkshape, BLender, Maya 3d, 3d Studio Max. I think there is one for Truespace but i am not 100% sure, need to look it up.

6) i am working in some changes to TGE that will allow the game engine to directly load STATIC (IE: objects that are non animated like buildings, ect ... ) .3ds models.

7) TGE has a very powerfull, highly recognized Networking engine. out of box, the TNL (TOrque Network Library) supports 128 player servers easily. but with tweaks here and there, the limit is possibly enless (my goal is to allow it to support user created server farms [ALA Ultima Online, True MMORPG)
----

DOwnfalls:

1) it is proving interesting working the source code for th eengine to support a space environment, but good fun and good experience.

2) Unless anyone else on the OL dev team has a legit license for TGE I am the only one here making the offer to use it for OL to be able to make the Game Engine changes (And no, before you ask i WILL NOT VIOLATE my License).

The offer has been put on the table to Blackhole.

I am currently using TGE to develop a game that is now having it's first mission being developed as we speak. but will not say what the game is at this point, as i do not want to hijack the OL forums or threads. I chose TGE because it is cheap enough to get a License for ($100 US dollars per seat for Indie license ,$495 dollar per seat un-restricted license).

On top of that there is a SHader engine under development that i plan on buying (from the same developers as TGE) and intigrating into TGE. Which will provide massive support for graphics rendering, bringing TGE into the next gen Game Engines, even though it is pretty much there now.

Post Fri Dec 16, 2005 6:35 pm

I hate it when people say "scratching the surface of <something>"

Don't ask me why

Post Fri Dec 16, 2005 6:58 pm

Actually, C# and VB.net are almost entirely the same -- neither is more powerful than the other, they just look different. There's very little that you can do in C# that can't be done in VB .net.
The big technical explanation is that they both compile down to something called Microsoft Intermediate Language (MSIL), which is then interpreted by the Common Language Runtime (the 26 MB thing you need in order to run VB.net/C# programs). Or something like that. You can probably find something on the Internet somewhere that explains this far better.

Post Fri Dec 16, 2005 7:23 pm

well aegis, that is your opinion and your welcome to it.

but C#, yes closely related to VB, but jsut as closely realted to C++. C# provides most fo the power of C++, with the ease of use of VB all packaged into a Interpated engine like VB, meaning it can be used on webpages, ect ... like VB, but with the power (or a good chunk of it) from C++. That was the goal of Microsoft when the developed the language, and they succeeded in a major way.

C# is powerfull, with roots going equally in both directions of VB and C++.

Post Fri Dec 16, 2005 8:51 pm

Well, doing further research suggests that C# supports pointers, while VB.net does not. Of course, when using pointers, you lose the advantages of managed code anyway. (other than that, Microsoft has an enormous list of comparisons between the two.)

Either way, as Blackhole has pointed out, the advantage of using .net is that it's fairly easy to use both languages at once.

Post Sat Dec 17, 2005 3:49 am

I'm still working on that framework model but as I was looking at different engines on DevMaster.net it kind of hit me that theres little sense in developing your own framework until your settled on the middleware you want to use because it all has massive development and framework implications.

How do you guys feel about dropping TV3D in favor of using Realm Forge GDK?


The RealmForge GDK is a true next-generation toolset for developing cutting edge 3D games and visual simulations. This open-source and cross-platform middleware is written entirely in C# and combines the power and portability of the .NET Framework with numerous productivity-boosting features and an innovative run-time development toolset (In-Game Editor) which integrates directly into the engine, allowing design, development, and modding within the game itself.


Heres a rough feature list:
EDIT: Read its description on DevMaster.net too.
Development:
- License: LGPL
- Based on .NET
- Includes an editor in the engine.
- Bulk of the middle-ware framework is there, just have to fill in some gaps.
- OS independent (care about it or not, its still a very attractive feature to have)
- Lots of code available to use as examples
- Includes support for multiple scripting languages
- Its in development, so as long as you build on top of it and not modify it too heavily this stuff can be upgraded in the future.

Engines:
- Graphics: Axiom (the C# port of Ogre with some added features)
- Audio: OpenAL (they built on to that a little)
- Physics: basic physics, rag doll, and ODE, with a OOP plug-in system.
- Network/MP: Appears to be a custom client/server, straight TCP/IP.
- AI: Neural networking, genetic AI typing, few path finding systems, FSM, scripted.

Suggestions for stuff to add to Realm Forge GDK:
- Upgrade the physics engine to Newton Dynamics engine.
- Take a look at Hawk Software , their HawkNLL network library to add a network wrapper with extra MP features and HawkVoice voice MP comm API looks good (both are free, open source, LGPL). They have a thread system thats worth a look too, all 4 are under “Free software” on their site.

Realm Forge GDK looks petty damn good to me. It's highly “pluggable”/modular, flexible, and is built on professional/commercial quality middle ware. Doesn't lock you into any proprietary crap but seems to support adding some if you really want to. It has a active development community both building on it and building stuff with it. If you like it I'll cut about 5 pages of technical psychobabble out of my suggested framework and build suggestions around Realm Forge. This will narrow it to two parts: filling in the gaps in Realm Forge and development theory on how the different dynamic systems could work based on other open source systems.

Then again I have about 15 pages of stuff here I can post but its not finished yet, I ran into a few design issues but I'm still working on it. I'm trying to find and layout the easiest to develop but most powerful system possible. It is still all just suggestions and you can do what you want but I've been reading about this stuff for years. Just never found the time to really get into building an engine myself. I'm also a computer technician, I've worked on everything from fixing cellphones to midrange systems (IBM AS400's and Linux clusters), so I know the power of a well designed modular system regardless of its size. If this project can benefit from that knowledge I would be more than happy to share as much of it as...well I'm able to type at least.

So take a look at Realm Forge GDK, if you like it I'll research different systems that should work with it and then try to outline a streamlined development process. If you don't like it I'll try to find something else to build my “fastest alpha build” suggestion around. Then I'll try to design some of the dynamic systems you can use in the future or that I might very well be developing in the future for you. I need to relearn C++ and learn C#, and given what Hobbes78 said probably relearn VB/learn VB.NET too. Shouldn't take too long, I'm only 5 years out of practice and C++ couldn't have changed that much!


-Burn

"Only the dead have seen the end of war"-Plato

Edited by - MegaBurn on 12/17/2005 4:03:33 AM

Post Sat Dec 17, 2005 7:58 am

Nice to see you people working together again. gives hope to humanity.

Anyway, i'm not a programmer. I can't get my head around it without having to dig at my brain with an icepick.

So anyway: music and sound engineering services still on offer.

Just a question on these game engines: what's the deal with audio support, what formats are supported? just so i know what to work in.

I did suggest this in a previous post, but was part of the deleted comment:

A suggestion to the musicians working on OpenLancer: each of you take a set of systems and do all the calm/danger/battle sequences for it. much easier that way.

-:-
I'm Rick James, *****.

Post Sat Dec 17, 2005 8:36 am

In short: Both the True Vision 3D SDK (the engine their using now) and the Realm Forge GDK can use DirectSound which uses the codec's installed on the player's computer. It can pretty much use anything windows can use.

Long version:
True Vision 3D SDK (from DevMaster) :

2D Sound, 3D Sound, Streaming Sound:
• DirectSound, DirectMusic, DirectShow support
• Allows to make unique sound atmosphere for your games
• Hardware/Software Sound mixing
• Unlimited simultaneous sounds
• MP3, WAV, MOD, SM3, IT, MID, RMI, SGT support
• 3D Sound support that can be linked easily to a 3d world
• Effects (reverb, echo, etc.) to give more depth to your sounds
• Movie playing (all formats) for cut-scenes


Realm Forge GDK (from DevMaster) :

3D Sound, Streaming Sound:
• OpenAL for excelent cross-platform sound
• 3D sound with panning, volume, doppler, and cones
• Implemented in an OOP fashion with the use of scriptable Sound entities

Note: This supports DirectSound so on windows it will support the same stuff TV3D does but since it also has room for other codecs it can technically support any sound format the PC has the ability to process.

Suggestion: For music use Ogg in the 192kbps range for the best quality to file size ratio and the simple fact its open source. That way you can include a audio recording system if you want to without having to worry about licensing issues. For sound effects any standard wave format is probably the best bet but you could use anything that doesn't use a high level encoder or compression, like some of those "pure sound" lossless formats. That boils down to file size more than anything else.


So, Jask, back on the team now? Thanks for what you said on the other thread, after working on those huge posts for so many hours it was kind of unnerving to have it all be reduced to the "ramblings of a madman". The possibilities are indeed vast and I'm here to try to make sure at least some of them are fully realized into the best game possible. Being a little detail obsessed isn't always a bad thing...


EDIT: Correction: OpenAL requires extensions for processing different formats and it seems not all formats are supported on all operating systems, however Ogg is fuly supported so you could use that for sound effects too. Also keep in mind OpenAL was developed by Creative and has native hardware support for all/most recent Creative Labs based audio hardware. Links: OpenAL Project site, OpenAL Extension List, OpenAL Platforms. Also, on windows with the right hardware and right drivers OpenAL has full EAX support too. I heard about a lot of people having problems with both OpenAL and EAX support in Quake 4, it may or may not be a problem, just keep it in mind.

EDIT: Clarification: You can use Ogg for both music and special effects. Ogg is more memory and bandwidth efficient than wave but less processor efficient. MP3 is actually the most efficient on systems with hardware MP3 decoding (which most sonuds cards and drivers have now) but systems without MP3 hardware decoding will see a significant performance hit. Some drivers now have Ogg support for hardware assisted decoding but not full native decoding. This is a hard choice to make because it will directly impact the minimum system requirement of the game, the download size, and other things.

Suggestion: Split the special effects up into two groups: long and short tracks (or big and small file sizes) and then use Ogg for the long/big files and wave for the short/small files. Then use Ogg for music.

Note 1: MP player to player voice chat uses a different extremely low bitrate format but it should be possible to stnadardize that via an abstraction layer such that you can reroute it through OpenAL with minimal lag (e.g. that allows players to yap with each other and have the sound come from an 3D sourced in game object or an equalized channel, like the center channel in a multi-channel sound system).

Note 2: Audio recordings, like player voice mail, will require the server to have the same MP voice communication system and a audio recording system. So if you include voice or even video mail in the game campaigns/missions keep that in mind. It would be jarring for the player to go from listening to the extremely low bitrate yapping of their friend's voice mail to a pre-recorded mission voice mail thats at much higher quality. So the audio from any pre-recorded/rendered voice/video mail needs to have the bitrate cut to something like 10kbps.

If you like I can move these edits to another thread on the audio systems in both Realm Forge GDK and that I'm suggesting in the framework. They're the kind of stuff like "you want a really cool nex-gen feature thats easy to implement? here ya go!" I can turn down the pyschobabble to a more understandable level too, just ask me to explain something...
/EDIT

EDIT: Added link, fixed typo. Add something then removed it and fixed a typo. I need to stop editing these damn posts and put the stuff in the framework text as notes or something.


-Burn




"Only the dead have seen the end of war"-Plato

Edited by - MegaBurn on 12/17/2005 2:18:30 PM

Post Sat Dec 17, 2005 9:00 am

Realmforge looks great, and a group of friends at my school are making their own game using realmforge, so its bound to be good. Since its written in C# it should be ok and it sounds like it can work with Visual Basic, is that right?

If so, go ahead and build a framework around it. I am just waiting for you to finish.

Post Sat Dec 17, 2005 9:12 am

Cool, I was just waiting for your reply, I'll get back to work on that.
*deletes 5 pages of psychobabble*

You do realize that by using Realm Forge GDK the game is already better than Freelancer in a purely technological sense, right? Case in point, OpenAL is the same 3D sound system used in Quake 4 and since its created by Creative is has special support for Creative hardware. The game is going to be awesome from the first beta build!


-Burn

"Only the dead have seen the end of war"-Plato

Return to Openlancer