I'm always searching for the ultimate Star Wars 4X fix, which led me to two open-source games of interest: Free Orion and Thousand Parsec. Free Orion is the more developed of the two (IMO) and really the only thing it lacks (besides AI) is a combat simulator.

I'm thinking it might be a good idea to focus on developing a strong, accurate (to the source material, i.e. the SW universe and to a lesser extent the Rebellion game) combat simulator to be "plugged in" to much of the existing code from Free Orion.

Then simply add characters and missions, and remove some things like ship design.

I bet that would require far fewer man-hours in the long-run than developing entirely new engines from scratch like the Rebellion community is largely doing now.

Just my 2 credits...

Hmm, hmm, basing your game on 3rd party code will surely give you a nice boost, but it definitely has it's pitfalls. Eg. FreeOrion is pure turn based strategy, you'd have to hack around a lot to make it work realtime (for combat simulator) - don't forget that you'd probably have to hack even the network code. And when you have that, you'll have nightmares from maintaining your code. You'd either have to fix bugs left over by the FreeOrion team, or carefully watch their changelogs and try to merge their patches with your hacked version. And of course your code will be a mess since you'll be basically writing workarounds around their code structure which was designed with slightly different purpose in mind.

But if you really like FreeOrion then perhaps it would be best if you helped it's devs, there's already enough solo Reb2 projects :-/ There's no point in starting another one, unless you could convince people to work together.

Btw. what I really like about FreeOrion is their wiki and design document(s), pity they're stuck on the 0.3 version since I can remember.

I'm not a computer programmer, but wouldn't it be easy to change turn based play into real time. Just write a line of code to advance the game clock one "day" like Rebellion's does now. Then you could use most of the turn based coding.

Just an idea.

Isnt FreeOrion open source anyway?

Yes.



And what if the game server has few second lags between each turn (Ai, networking and stuff)? Or what if the server time per turn isn't capped to a pre-set value and AI can think all the time it wants (in other words time between turns isn't constant)?

Rebellion has fast, yet extremely stupid AI. Similar problem dragged down Ascendancy. Isn't this one of the main reasons for the remake?

Besides as far as networking goes, TBS games might use TCP for their networking layer, which is by it's nature unsuitable for RT games (it actively waits for undelivered packets, while blocking the network stream).

Of course, it would be best to check FO's source before making any assuptions

You bring up a lot of good points. I play single-player exclusively, so issues like networking never even crossed my mind.

I would like to add on multiplayer. Network is important and I have thought about it. Lucky for me there is code inside DarkBasic to make life simple.

The data packets are received ascyncronized, the packets have a the day time stamp for the game (day 100 for example) and it waits for the response. IE both players must wait for both to send and receive data before the next 'day' turn TBS can occur. Thus they are always in sync. This will not work so good for a Real Time Game.

The most simple data exchange is darn near like IM e-mail, the time for delay in TBS would be around say 100 ms which is totally not good for real time shooters. But it is most easy to do, and reliable for TBS.

Combat 3D is real time, but I make the hidden delay of packet sent and up date invisible since in reality your playing 100 ms in the past and both sides. It seems smooth but that is the illusion. Einstein's time dilation

---------------------
Sorry for my spelling, I was forced to go to a public school.

I mentioned multiplayer because FreeOrion has currently no AI (or at least no noticeable AI), so it's basically only a multiplayer game.

About networking. You can basically send packets using TCP or UDP protocol. TCP guarantees that packets arrive (and in the correct order) and UDP doesn't guarantee anything and just shoots packets through (nad thus doesn't lag) and it's up to the programmer to deal with data-loss or incorrect ordering of packets. There are of course some libraries that solve these problems, but most of them are C++ only

Actively waiting for confirmation might work nicely for 2-player TB game, but you'd still have to deal with realtime for the combat simulator. Do you know how is the networking implemented in darkbasic? Does it use TCP or UDP? Or some hybrid system (they might try to prioritize packets and the most important send over TCP while the most time-critical through UDP)?

Yes, you definitely know your programming skill, Moribundus. I appreciate your insights into what can happen and avoid pitfalls to run into. Does DB use TCP or UDP, hybrid? That is a good question which I never looked into to be honest. DB can make a game over the NET or play LAN.

I know of these basic commands. Now the TB messaging I was going to do is going to run into a problem in the 3D real time combat. I was going to send very basic messages between only two people to start, so that lossy packets will not be a problem, since there really is not a whole lot of data going through. I need to look into this!

It can handle both TCP and UDP. I seen this plugin that seems to go more for the TCP route. Says its easy to use. I can trust this persons free code or make my own.

Sadly, I think the company is going to ditch DX9 of DB pro and go with DX10 Pro integrated with Microsoft's method of changing every five years (rather annoying). MS seems to lend alot of free support to DB. It is on their website for making games, MS seems to promote this Dark Basic stuff. It is where I found it years ago.
------------------------
Multisync
Multisync is a multiplayer plugin designed for DarkBASIC Professional, utilizing the TCP protocol and the client/server networking model. It is best used in games where it is important that data isn't lost, as the TCP protocol makes sure data is always delivered to its recipient. This means that the range of games it is useful for is large, ranging from simple card games to complex RTS games. It is very easy to use, and requires minimum networking knowledge.

Features:
Windows Firewall integration.
Easy client/server setup.
Easily manageable client ID's.
Supports most standard datatypes: byte, word, long(dword), integer, float, string.
Informative error reporting.
Stable and robust.
------------------------------

SEND NET MESSAGE FLOAT Player Number, Float Value
SEND NET MESSAGE INTEGER Player Number, Integer Value
SEND NET MESSAGE MEMBLOCK Player Number, Memblock Number
SEND NET MESSAGE MEMBLOCK Player Number, Memblock Number, Guarentee Packet
SEND NET MESSAGE STRING Player Number, String
Return Value = NET MESSAGE INTEGER()
Return Value = NET MESSAGE FLOAT()
Return Value = NET MESSAGE STRING$()
NET MESSAGE MEMBLOCK Memblock Number
PERFORM CHECKLIST FOR NET CONNECTIONS
PERFORM CHECKLIST FOR NET SESSIONS
CREATE NET GAME Gamename, Playername, Number Of Players
CREATE NET GAME Gamename, Playername, Number Of Players, Flag
FREE NET GAME
JOIN NET GAME Session Number, Playername
SET NET CONNECTION Connection Number
SET NET CONNECTION Connection Number, Address Data
PERFORM CHECKLIST FOR NET PLAYERS
FREE NET PLAYER Player Number
GET NET MESSAGE
Return Value = NET GAME EXISTS()
Return Value = NET GAME NOW HOSTING()
Return Value = NET GAME LOST()
CREATE NET PLAYER Playername
Return Value = CREATE NET PLAYER(Playername)
Return Value = NET MESSAGE EXISTS()
Return Value = NET MESSAGE PLAYER FROM()
Return Value = NET MESSAGE PLAYER TO()
Return Value = NET MESSAGE TYPE()
Return Value = NET PLAYER DESTROYED()
Return Value = NET PLAYER CREATED()
SEND NET MESSAGE BITMAP Player Number, Bitmap Number, Guarentee Packet
SEND NET MESSAGE SOUND Player Number, Sound Number, Guarentee Packet
SEND NET MESSAGE MESH Player Number, Mesh Number, Guarentee Packet
NET MESSAGE SOUND Sound Number
NET MESSAGE BITMAP Bitmap Number
NET MESSAGE IMAGE Image Number
NET MESSAGE MESH Mesh Number
SEND NET MESSAGE IMAGE Player Number, Image Number, Guarentee Packet

Well try it and see how it works. It might also help to send all messages at once in a single packet (compressed if possible). Microsoft recommends to keep your bandwidth under 64 kbps, which isn't that much (depends on your desired network framerate). But I'm sure you'll make it work

It's sad with DB going to be Vista only. I have recently downgraded to WinXP, since Vista managed to destroy themselves through some auto-update (I suspect .NET service pack being the culprit). I hope they keep DX9 though.

OK the previous post is a bit long (who needs to know the commands?). I read on the forum of Game Creators alot fo stuff about Network gaming. I read real life examples used in games, article on packets size, loss, checking, error if packets are loss, throttle control etc.

MP opens up a whole new game theory on how to send enough data to keep the game going and not enough. I check for lag, packet size and control. If I have up to around 1000 objects going on, most of thestuff does not need updated every frame. I would use the HOST to keep track and send out the data packs below the MTU of around 1300 bytes to about 4 per second should be good. The ships and projectiles willl keep flying and moving to their logic, every so seconds make sure the action keystoke inputs coming back from the CLIENT computers are actually matching the true ShipLocation () data and stuff to make sure they are staying on course. If a command to move your ship to x,y,z location the ship will by itself try to make it there on its own, the actual path is predictive if packets are lost (which will accur) to show a smooth motion.

I think this game is simple enough in physics that I can keep track of alot of stuff (inputs form the client players) and then making sure things are going the way it should every so often so to speak.

There are alot of articles on this Network theory, and thankfully I have some experience with 'Information Theory' on getting what is important back and forth to all the players. I suppose it means you can have more than one verse one player (you could have two players controling two Imperial fleets against two Rebel fleets within the same game battle). Or just let the AI fill in. I was going to keep it simple for the initial game to one vs one or vs the AI.

DB seems to be a bit buggy they claim to Network games (more likely its other upgrade GDK has the problem). BD pro is using DirectPlay form DX 8.1 it seems. I think MS wants to drop that. But it should still work just fine on XP and Vista using up to DX9 libraries. Heck, are not people still able to play Rebellion 1998 over the Net without problems?

I think peeps may be having trouble due to the physical hardware physics going on with transmitting packets over a crappy internet connection which is inherent. Lucky I learned electronics hardware so I understand very well what is going on there. I do not expect to have any probelms writing in a MP component. I hope. I am a n00b to MP software coding since I never done it before. I guess I will be in for an exciting lesson of Network Packet transmission Theory and Design.

Sorry, I just posted. Thanks for some info on maximum data rate. I think i can do it since this game is not that complicated for a RTS part. Even though they may go DX10, I think the DX9 stuff will still run for a long time I hope. There are alot of games made in the last 10 years I do wish to keep playing, so I want to stay with XP. Eventually in the future, the code can be upgraded as needed without too much effort. I hope too, since that is what I know.

As long as people can run XP and normal Vista, I have the DX9 DarkBasic Pro edition and I can keep gong for quite awhile. Maybe MS wants us all to go XBOX>

The fellow did say the same, try to keep it in one packet (instead of a whole bunch of smaller ones), he gives alot of tips and tricks in a tutorial.

Another trick you mention is compression. According to encoding theory, I can take the data for hull health and shield strength and combine it into one number for example using a codec. Thus that one number is only half the size to transmit the same data. It does require the PC game program to encode and decode, but the computer CPU is much faster than the net connection. The use this for streaming video and audio. I can compress say a WAV file from 2 megs down to only a tiny 50 kb OOG file. Same for video. By using the same techniques, I can cram a whole lotta data into that one packet to the limit of the Shannon Bandwidth Theory limit. The PC game has the key to compress it, send it down the internet, then decompress it at the receiving computer. Of course redundacy error checking must be in place, but generally you can get alot of data through (depending and how much error the gmae can stand).

I mustt hurry to school, so I will keep it short.



I think you're on the right track. Unless you're using physics based damage model, the "server" (or the other player) doesn't need to have all objects in sync (particles and missiles for instance). Even if it would be physics based, you'd simply display fancy explosions on the client, but the health bar wouldn't move unless the server said so. I think you only need to send player's messages (or "keystrokes") and the other side will figure whatever they mean.

You're right about the compression, but you don't have to check the packets for integrity if youre using TCP, since the protocol itself guerantees error-free transmission.

Might it not be easier to use Space Empires? They already have a combat simulation system set up, and while it's not open source, they are very good about making things very MOD friendly. They've also got an AI set up, and they've taken care of all the multiplayer issues. It is turn based, including the combat simulator, which could be a problem I suppose...

You'd have to do something about the custom-design ship element, though I suppose you could just modify the systems researched to allow each ship class to only access systems available to that class in SW cannon. Which can be done; I did some work with that in Space Empires IV, using a Star Trek total conversion mod as a base. In fact, that could be a handy game element; if you want your Mon Cal to have more powerful sensors, you can research sensors, or even just Mon Cal sensors, and then upgrade your ships accordingly, while still maintaining things in balance with source material; i.e. you can still limit it so that your Mon Cal can only have so many turbolasers, while controlling what kinds of missile systems can be mounted, etc.

Basically the only problem I can see is the turn based simulator. If you want to take a look, it's at www.malfador.com Great games overall.