Quote: "I think a particle engine like that is a bit beyond me as a programmer , Im good at donkey work and wrapping stuff ,"
We could start with a simple system and expand on it. DGDK supports a majority of the features I 've proposed. We have a Scripting Engine at our disposal and matty halewood is working on physics. The only features that may require some special attention are Rendering optimizations such as Level of Detail. What do you have in mind for a simple Particle Engine?
Quote: "by the way i made another gdk plugin from the dbpro bitmap font tut in an old newsletter , so if you want me to add that in i can , works great in gdk ."
Go for it!!
@Faker1089, Micheal P, sydbod - For S3GE to live upto its claim, I would expect the engine to operate in the capacity of a Server|Host/Client. A Server usually supports a large number of clients and doesnt require UI and rendering, a Host is a Server that supports a small number of clients and requires UI and Rendering. Would developing a Host/Client with option to become a dedicated Server be feasible hybrid?
Quote: "I think that we should be focusing on getting the actual game/rendering engine completed more before we start on the networking."
At a basic level networking is just a means of sending data between computers. Integrating networking can be achieved without any knowledge of rendering and my vote is high for getting it in there now. Why am I so big on networking, because we can use it to download files into the engine. Its safe to assume that most (if not all) of engine's data and content will be stored in external files. These files can be stored on a remote server and doing so will give the engine significant abilities for collaboration at the lowest levels, just as you have seen using SVN.
It may be early, but, I believe we can establish a preliminary goal of simply transmitting and recieving files to/from a HTTP Server and integrate this into the main.cpp. In Client mode, it request files. In Server mode, the Engine can act as a HTTP server sends file request. I anticipate these modes will be selectable in the future via a GUI so we can hardcode a variable for now. For testing purposes, the file will be XML file containing some info for creating a cube and DarkLUA Script for rotating it. So when its all said and done the flow could go like this:
Client Mode
1. Launch S3GE.exe
2. Select network mode = client.
3. Select Server Address.
3. S3GE connects to hpquest.com grabs the cube.xml file.
4. Once the file is recieved, a cube should appear on the screen and rotate until the exe is terminated.
Server Mode
1. Launch S3GE.exe
2. Select network mode = server.
3. Client request cube.xml which sends file cube to clients.
Achieving this goal will accomplish the following:
1. Utilize Script, XML, Network Plugins.
2. Help identify means of using application layer protocols.
3. Help identify means for working with large file Tx/Rx
4. Help identify game server/client protocol and messaging
Once we complete this goal, we can move into the Game Server/Client protocol and messaging. This is where we would start to include rendering etc.