Thats it, the whole framework. I'll start another thread like this for dynamic module concepts/theory, concepts for temp/place-holder module to use until the dynamic modules are developed, some other 'misc' ideas I have, and a expanded repost of the first ten pages I posted on the design doc thread.

Uh, so, well I hope this is helpful, what do you guys thing?


-Burn

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

Edited by - MegaBurn on 12/19/2005 11:16:25 AM

HOLY MOTHER OF GOD!

I'll have to spend like... all day reading through this...

But whatever it is, good job XD

Intro diagnostic: I could read it all and it sounds great, and NO i will not call you insane!

Section 2: GREAT WORK! I was able to read through the entire thing without any trouble at all! Makes perfect sense!

Section 3: Getting a little more technical but i was able to read through without too much trouble. VERY good designs, my friend.

Section 4: Technical x.x Luckily it all makes sense and i'm still managing to follow along.

Section 5: That was short Good job, and like all your other posts, is absolute GENIUS. Excellent work!

Section 6: Lots of advanced stuff here, good thing we don't have to make any of it for a while.

Section 7: "this module will require finding all functions in Realm Forge GDK and all add-on libraries and then compiling them into a single library" could you go into a little more detail? And i figured out a tenative dynamic economy system, except i lost its explanation, damn!

Section 8: oi, that was a lot to read. Makes sense though.

Section 9: Ok, now we are running into problems here. For the translating bit, if we simply included a few lines of code that choose the correct string from a string table, it would be very simple to do. But VB.net does NOT use dll string tables! We would have to make an INI file or whatever that holds the strings and then reference it from there. Additionally, we should NOT use the "nickname" entry for that ship as the name. Why? Because the nickname entry is used as a reference everywhere else and so it is usually different than the actual name of the ship. a simple ids_name = <the name> or something would serve the purpose so much better.

Sectoin 10: Logic prevails! Awesome!

Section 11: Ok, i skimmed a bit here and there, was very very in-depth and difficult to read through, but it does make sense. However, everything you want to be OS-dependent has to be programmed by someone else, not me.

Section 12: Same as section 11

Section 13: DAmn useful, i'll be referencing this quite a lot

Section 14: I see...

Response: Amazing work. Currently my main concern is how to get the framework built. What should the main engine core be in, how do these fit together, should i make them seperate VB.net projects, in other words, how am i going to get the framework built if i need to rely on different languages?

Edited by - Blackhole on 12/19/2005 12:51:20 PM

Well I'm happy this will be helpful. I fixed the two duplicate posts and updated section 7 with a better script functions module description. I'm not sure about what the VS.net compiler includes but I think a good code optimizer would sort out most of these extra references if the script library were compiled with the main game engine code instead of being in its own DLL. That will eliminate most of the performance slowdowns. Same goes for the OS and Low Level Access Modules, they're basically the same thing, collections of references/includes to other things that should be streamlined by a decent code optimizer and most compilers come with one.

On the Name Data Module, right, a set of INI files would replace the old IDS system with INI nickname-like references instead of the old IDS numbers. Sorry that description was written late last night and its kind of poorly written. For the nicknames, point taken. So how's something like this...

game folder -> data -> ships -> shiparch.ini
[ship
nickname = li_elite
trans_info = info_li_elite

game folder -> data -> text -> en_trans_shiparch.ini
[translation
nickname = info_li_elite
name = Liberty Defender
info = Liberty's heavy fighter blah blah...
info1 = string...
info2 = string...
info3 = string...
(then game folder -> data -> text -> es_trans_shiparch.ini would have the Spanish version)
(and game folder -> data -> text -> fr_trans_shiparch.ini would have the French version)

That way the info would be like anything else defined in the INI's, just lump the string values under a nickname and add a new section in a new INI file to define the nickname. Another option would be to add multiple translation nicknames each with a new section in a new INI file...but that makes it rather complicated. Honestly I have no idea if it really makes any difference, maybe someone could comment on if anyone is interested in translating all of this to another language (not to mention the audio). I'm guessing it will be important but too I'm use to seeing stuff like that in almost all open source projects so its half expected. Making it work in the game engine would require a user profile setting (another INI) with a language selection option, then that would become a global variable. Yet another option is just release different versions of the entire game data folder in different languages.

On how to build this framework, that is what I'm researching now. Problem is I just don't know enough about .NET or Realm Forge GDK. I don't have time to research either one much less both, but I am reading over the help files and other stuff on the Realm Forge site. I haven't downloaded the GDK yet because I don't have VS.net and I don't get the feeling VS6 is going to help. I should have a better idea of how to tackle this project tomorrow though. Should have more links for this thread and the rest of the stuff for the other new thread ready to post tomorrow too.

Despite the massive amounts of design theory I posted your best bet is to ask someone with more development experience and specifically someone who knows these m$ .NET languages well. I don't know how portable .NET languages really are or if it will work right with the GDK. I should have said this earlier but most of my C++ experience is with Linux and the only game engine source code I've messed with is the Linux port of Quake, an extremely old version of Crystal Space, a half dozen extremely simple engines that came with the game programming books I have, and an open source engine replacement for Fallout. All of that except the Fallout engine and one of the simple demo engines was on Linux. I never learned visual studio or much about windows programming, and all of this was over 5 years ago. All I know about VB is basic itself, I had to take a basic programming class in my freshman year of high school and I haven't used it since (about a decade ago), I wrote a few very simple programs with VB in VB4. So I can spit out design theory all day long but you know more about windows programming than I do. Still, I'm always eager to learn so I'll try to research this stuff as much as time permits before I move on back to my clan's mod, then I'll have to learn C# before I come back to work on this project.

So to answer your questions, all I can do is make an educated guess but I don't feel I'm educated enough to risk guessing. If I find a definitive answer tonight or tomorrow I'll post it with full details, links and anything else I find. Aside from that. if you've downloaded the GDK documentation you probably have more details about it than what's listed on the Realm Forge wiki. Sorry I won't 'hazard a guess', yet.


-Burn

Alright, then we will hold off on designing the framework for now. Does anyone else here have anything to say, possibly someone experienced at VS.net?

Jesus crominy! Thats alot of good stuff to absorb. Too bad I cant meld it into my brain. Gonna take alot of reading for me.

Well the one thing to keep in mind with all of these bloated development tools is you don't need them. I started coding C++ in VIM, quite possibly one of the ugliest and hardest to use text editors ever conceived, a real UNIX relic thats almost as old as I am (I think Vi was “spawned from evil” in the late 80's and became VIM in the early 90's). Point being you could code this on windows notepad or download Notepad++ (one of the best free open source text editors available for windows) and then use the compiler included with the .NET framework. For most of these middle-ware libraries/packages there are plenty of code examples, snippets, tutorials, and demos available, plus the documentation. Just a matter of going one by one and figuring out how it all fits together. For me the major unknown is still Realm Forge, I'm going to start downloading it before I go to sleep and skim through it tomorrow.

Another option is put out an ad for someone with more programming experience or a professional to volunteer. Too, if TLR will put another ad on the front page news it would pull in a little more attention to the project. In that case there is still a lot of design work left to do while your waiting for someone to help. The Realm Forge forums also have a lot of very useful information that might help. I'm not sure what else to say, be resourceful. I'm still researching this stuff but there is so little information on the Realm Forge wiki that I really won't know where to start with it either.


-Burn

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

Well i want to get to work on a framework, but i want this project ot succeed and for that to happen we need a very solid and adaptable framework to build off of. The less programming i need to do, the better. I'm not lazy or anything, but i'm quite certain that the more people help out with this, the better the game will be, and a solid framework will make that easy.

A sad story that is similar to us is the story of Descent IV: Invasion, a truly wonderful game that would have been the first fan-made sequal to a game. Sadly, they were shut down by copyright reasons.

I myself am a descent 3 fan and the event is very, very sad. But it also serves as a warning for us to keep our project out of the eyes of M$. Aside from our storyline though, Openlancer is legal.

Let us become the first ever fan-made sequal in history. Let us break past the barriers set my M$. let us band together and make OPENLANCER!

And if any of you Descent 3 fans are interested, it would be possible to use the OL engine to make Descent 4.

Ok, i've been trying to figure out a way to dynamically handle new DLLs as needed in VB.net, and right now i'm having difficulty trying to do it. My current plan is to create an interface class that would serve as an interface between DLL files. There would be an array of these DLLinterfaces, each having the name of their DLL and path. Each class would call the "info" function from their assigned DLL file, which is the one required function in all DLL files. This would accept 2 arguments, Mode and Data, which would serve to retrieve information about the DLL such as the number of functions it has and to retrieve a certain function name. The class would build an array of functions that any other DLL could access. This would allow the DLL files to change and add functions but would minimalize the amount of recoding the other DLL files need to do. Unfortunatly, there is no way to do this in Visual Basic.net, and i'm running out of ideas on how to dynamically load DLL files.

An alternate plan is to simply reference all of the DLL files beforehand, but give them all a universal "Access" function, with a varying amount of arguments (depending on the DLL). This function would read what information is being requested or what task is being ordered and then syphon the order into the correct area of the DLL. with THIS method, its fully doable and it allows for DLLs to change their anotomy's completely without affecting any of the other game. Example:

The physics engine needs the result of an equation for the gravitational pull on a ship, so it sends a call to the access method of the math module with the correct variables for the equation in an array (or however the math module is set up, it would have to be unique in its arguments since equations vary in size by a vast amount) thats sent to its Data argument. The "Mode" argument is assigned "Gravity" (and any other needed arguments, can't think of any right now). The math module recieves this information. It reads the Mode and finds that its Gravity, so it calls up its gravity function and then sends the information back. But then the programmer splits up the gravity equation into 3 parts. Catastrophy? No! he also changes that part of the code to instead call the 3 seperate functions and add them together (or whatever he does), and then return that. No changes were nessecary to the other module. What if he renames the equation to "gravityeq"? Well then he has to take into consideration that other modules would not be aware of this change and he would simply put in a line of code that would change the mode from "gravity" to "gravityeq", and voila, no fuss.

To me, the alternate option sounds extremely promising. What do you think?

If we want to allow for additional morphability, the arguments could be limited to a Mode and an Data() array, allowing any DLL to call any other DLL without worries of if it will work or not.

EDIT: the mode "help" should be included in all DLLs and it should return a function based on the number given in Data. This allows DLLs to analize each other if nessacary.

Wow, it looks like Megaburns detail obsession is rubbing off on me

Edited by - Blackhole on 12/20/2005 12:21:29 AM

my dad is a expert at programing he knows c++ and assambly code
he can learn from a book vs.net.if my father and mega burn work together it will work my dads a real tech wiz

but he will be able after chritmas

i am nobody nobody is perfect so i am perfect



Edited by - silverlook on 12/20/2005 7:05:16 AM

Blackhole, you must compete with som fan made sequels that are far more into production than OL, so I doubt it'll be the first (which is not a bad thing at all, since the more fan-made stuff is surfacing the better).

I wasn't aware of any, oh well, i don't care.

Well the Realm Forge documentation is vague but now I have a feel for the scope of the GDK. It covers damn near everything but parts of it need work. My suggested framework isn't going to help you much, you have to learn the GDK framework and go from there. That means most of my work here was a waste directly but I think the effort had an overall indirect positive effect. It might take you a couple months to fully learn how to use the GDK but after that it should only take a few weeks to create an alpha build. Then maybe a few months to extend the alpha build into a full game.

My mistake was and normally is thinking that these middle-ware systems come without a learning curve. Thinking that everything you need to know can be summed up to a few dozen pages and then you can just make it work. Problem is the Realm Forge GDK is an extremely complex system and goes well beyond the scope of normal middle ware. There is a vast amount of stuff the must be learned before you can use the GDK. Thats true of most things like this and its a mistake I've repeated often, I tend to markedly under or over estimate things.

I'm going to rewrite large parts of my suggested framework in this thread such that it can still be helpful to you, post the other stuff I have, and then go back to the mods I was working on. After that I'll learn C# and the GDK before I come back to work on this project (otherwise I won't be much help).

Bottom line is this: You already have a framework in the Realm Forge GDK and now is the time to learn how to use the GDK which probably means learning C# at the same time. Even a professional programmer won't be able to help you unless they know how to use the GDK. Then in a couple months when you have a firm understanding of the GDK you can come back to writing the technical details behind the Openlancer game design.


-Burn

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

Argh.

Ok, so am i the only one who can program this, AGAIN? I can't do this by myself, damn it! I have half a mind to just drop it again. This is insane.

Edited by - Blackhole on 12/20/2005 3:03:25 PM

Whoa... I only just saw this. Awesome work.

A few comments (I haven't completely finished reading it yet, so excuse me if there's anything that's already been addressed):

Section 5: Instead of a DirectX module, Open Library, Prop. Library, et cetera, might I suggest:
Graphics Library (of which we have derived classes for DirectX, OpenGL and whatever else)
Audio Library (of which we have derived classes for all the various sound libraries)
And so forth (anything else I've forgotten)

Section 9: I'd like to add a "data access" library that abstracts away the actually loading the data from a file (so we can replace it with a database, or XML, or with carrier pigeons or whatever) (or is this already handled in one of the "Low Level" modules?)

VB.net can be made to load DLLs from a directory based on an interface they implement. I have a code sample somewhere that I'll dig out.

I think the best way to get this around everyone's head is to whip up a diagram (as MegaBurn suggested). And finally, MegaBurn, how dare you insult Most Noble and Glorious Vim?