Here goes nuttin. In order to get this project off the ground, I suggest we start with the bare basics, code and design wise, and then modify and add to that base system. Here is a sample base system:
Client - v0.01 - Draws one kritter and moves it around, with or without a terrain map. This would get us a Client base code to work with.
Server - v0.01 - Base set of scripts that logs the player into and out of the database with IP and Port numbers (easy to do), and replies with IP and port numbers of everyone else in the lobby. Encryption would not be needed for v0.01 so that can be added later. A 'New Player Name with Password' script would also be needed in preparation for v0.02.
Map Editor - v0.01 - Do we really need more than one type of view? I suggest a top down isometric view with mapping tiles as a starting point. 3-d rendering may be nice, but if the player has more than one kritter, the view changing will be nasty and confusing. Also, selecting multiple kritters to do things like 'move in a direction as a group' would be insane. Enough said about that. So, for v0.01, we would need a tile definition and some sample tiles to play with in the Map Editor while a full tile set is being developed.
Client - v0.02 - Add lobby 'chat' feature running as virtual p2p server. As a suggestion, client would open 'chat' connections with the last 4 player logins, for a maximum of 8 connects (4 downlinks and 4 from new players logging in and connecting to the player client)
Server - v0.02 - Add chat logging support if it isn't done already. Get kritter data structure from v0.01 Client and add definitions to the server side database. Prepare simple encryption and keep it optional until v0.03 Client supports it, then make it enforced in the next version of the server.
Map Editor - v0.02 - Once a sample tile set is done, the definition of a map file should be developed and a basic editor coded. The code for the map display should be relatively easy to port to the client.
Interim - v0.03 - Review progress and issues from the first two versions and decide what the next two versions will contain.
Does this sound like a good plan?
"The IMF disavows all knowledge of my having written this post."
OK - one thing about the versions - let these be builds of the alpha (Roadmap says Nov 2001-May 2002 is alpha cycle) then we can go to beta if we have enough. The Interim could be the build going from alpha to beta, etc.
Don't forget that singleplayer (w/AI) and splitscreen support should be available in the basic client package, with the multiplayer part being perhaps a net_client package.
We will probably use the 3D engine to view both maps and games. If we can't get a 3D engine ready by the time the editor and client code is ready, maybe we can patch Crystal Space or Genesis 3D in to test it.
Selecting kritters could be done by having a Kritter Roster sidebar available. Seems like using "Task Panes" would be a good thing for this type of game. I know that is Microsoftish but it would help streamline the interface.
Servers should be more in the background, I suggest having a lobby (MSN-zone type thing) and using a script to detect what servers are available to use for actual game stuff, and use P2P for chat. That way there can be a "table" for each game, and the lobby allows people to connect to a server that already has people (a table), start their own game using a detected server (which could be running on a website or an online system) or start their own game creating their own server. The lobby would just be a list of available servers and their status.
do you get what he is saying? we dont start with everything at once. we get it working first. THEN we add all the silly little features, maps, kritters, gameplay, singleplayer, galleries, split-screen, 3D, textures, etc.
Yes I know. I really would like to do an AI mode first, or at least have it workable so you could run clients side-by-side on screen with a server too. Multiplayer over the web, I think, should be slightly later, maybe alpha build 2 or later. That way we can test it without having to have another person ready.
I guess AI would be harder to program than a multiplayer mode, and we can always run two clients on the same computer to test if we don't want to do it over the web, or can't get a server working on the first try. That will be workable, correct? I want to be able to test it without connecting to the Web if I want to, that is just what I wanted to make clear.
ya. you don't have to have multiple people to test such a thing. You just run a server and a client on one machine (or two localy). That is fine. As for which is easier, I think the network code might be easier but I haven't done much with AI as of yet so your guess is as good as mine.
Yes, and basically multisingle (2 clients) would work for splitscreen if we had a geometry tag that would let you tell each client how much of the screen to take up, and different player controls. You'd probably need two keyboards and mice or something to do it best... hmmm. OK about AI - but that will need to be done of course.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.