I've got some issues that don't fit in the other groups. So I put them here.
This is a reply to a mail sent by Martin. He discussed some design issues:
>* Client/server communication: The server must return also: speed of the car
>in each direction (x,y,z), acceleration (x,y,z), rotation speed and agle
>(x,y,z) (maybe also the axis, but thats to far..). If we just update the car
>position only when getting a new position data from the server, we will never
>get a smooth animation.
Well, I've never seen the current set of network-data as THE set we should always use. I agree that some things should be added, but I think it's relatively easy and it doesn't matter if we do either graphics or this first.
>* Make a good networking design that supports playing without server (see my
>previos email), by implementing the same physics code into the client.
This seems to be quite independent of the graphics, so, again: the order in which we do things does not matter.
>* The tree projecs in ustunts (client, server, tedit) currently use independet
>files, but some of them are equa (eg. cstring). In my opinion we should
>desing the source structure that it can be used by all projects if it makes
>sense. eg. networking, physics, fileutil, cstring, cfile, car, vector.h ...
>Having duplicates really sucks if you change them, you have to change them
>twice or copy them around.
I agree that it would be nicer if we had a system to share these things. I think this requires all programs to be in a single kdevelop project, and to share the configure-stuff. The first thing seems to be possible if (the source of) every program is located in a separate directory. Anyway, this needs some research (unless you already know a detailed solution).
>I would suggest to clarify these design issues first, before making the game
With what arguments? Of course it's better to first clean up things, and then go on with making other things. The reason for the last issue is that I didn't have a detailed idea of how to solve the problem, and that I didn't want to search for it. The reason for the first two is that development at these points hasn't been finished yet.
If you do either graphics first, or network first, seems quite arbitrary to me. But there are area's in which development has to be done in a specific order. For example, we should do physics first, and then AI, because developing the AI needs the natural environment in which it will function. I've listed the following dependencies, where I put code in the groups graphics, sound, network, physics, GUI and AI:
graphics needs nothing
sound needs nothing
network needs nothing (but graphics is preferred)
physics needs graphics (for debugging) and network
GUI needs network
AI needs physics and network (for developing)
I suggest to get working on the source-sharing as soon as you know how to do it, and for the rest work in the following order:
This is approximately the order in the planning-page of the website:
I'm calling the current version 0.2, but both graphics and network aren't finished completely. I just made what I need for the current version, and I am still adding functionality to these.
Of course I keep in mind what the future needs of these interfaces will be, or else things would be completely messed op in the source.
> and for the rest work in the following order:
I would follow this order:
1. Primitive graphics so that we can see something (already there)
2. Create a good game concept (see my other comments)
3.1. Physics (without physics the game is useless)
3.2 Network (Because we want to have a network game, so it is important to solve all problems on that)
From that point I would do all the minor things like sound, good graphics, AI clients, Gui.
My email to CJP:
For the issue "who should calculate the physics":
Lets be reallistic. I think a modern computer should be able to do the
graphics AND the physics (collistion detection etc.) at least for the own
car. I am quiet sure that every multiplayer game follows more or less the
method we both already agreed on. So in my opinion we should implement this
method no matter if we play on a LAN or internet. On modern network games
(like unreal tournament) you can choose your internet connection speed. I
think this just controll the update frequency to the server (send the
information 5 times/sec or 20/times ...). But nevertheless, the client MUST
calculate it as well to insure a smooth animation without delays! So I
totally agree on your "last remarks", see quoted below.
From some experiences in the past, now when starting a project I always try to
solve the design of the most important parts, before spending time to write
not-so-important "add-on's" like building user friendly interfaces.
It makes much more sense because you never know how the core api will look
like (and all other "not-so-important-things" will depend on it). And in
addition (in a pessimistic view) we do not even know if this game will be
finished at all, and it would be a waste of time if we concentrate on add-ons
that we might never need... The network and the server code (the physics,
too) are core feature of the game IMO so I would give it a higher priority
that the graphics or the gui. I do not care if the game looks stupid now, we
can make it nicer if the important other issues are solved
> BTW, I think that the requirements for the server program are so
> complicated, that it makes no sense to fully integrate server-functionality
> into the graphical client. Integrating the sound-, graphics-, input- and
> client-functionality of the client with the fileserver-, distribution- and
> server-functionality of the server seems to me like integrating a complete
> office-package and an operating-system into a single executable. And I
> still want to have a non-graphical server in the UltimateStunts-project, so
> why not simply use that one?
I think it just a design question. If we write nice independent classes that
do a specific job, and specify a clear interfaces to them, we can easily
share this code in the client and the server. On a very high level then for
example we would have one signle class that is able to do all the server
functionallity and the client and the server can use it. The _remote_ server
then will just be needed for network games, because the server class is
integrated in the client as well. And of course the remote server will not
Just a design example how I might implemnt this:
Write a class "usserver" (ultimates stunts server), that (as it is right now)
has input with "cardata_in" and it fires "cardata_out", but it should will do
all the server functionallity in the future. We can setup the usserver to
fire the cardata_out in a specific interval. If usserver is a local instance
of the client we would set it very high, but if it is on a slow internet
connection we would set it to 5 times /sec for example.
Create one instance if usserver on the client with a very high update
frequency to ensure a smooth animation. Then we could already play local
games. A remote server does have the same instance of usstunts, too, and if
we play on a internet game the client will send the cardata_in as well to the
server and will receive cardata_out in a lower frequency as the local
instance of it (because of the limited bandwidth). As soon as the client
receives again the package it must compare it and if needed adjust the car
position ... and-so-on.
The additional server code would just be the network functions, but both use
the same class that is doing the calculations.
Then it is not complicated at all to integrate the "server code" into the
The other questions: Yes, you can use SDL without the graphics functionallity,
so we could use just the SDL threads and timers in the server. The SDL
library is not so large, it does not matter in my point of view if it is
compiled with or without the graphic code. But also, you can compile SDL and
disabling all the features you do not want. If you compile the executble with
static SDL I think it will include anyway just the code you are using.
But you are right, the windows version will still depend on cygwin.. I did not
see the network code.. But anyway.. more native code is better than less :)
With native code I mean code that is written for the operating system it is
running on. The socket code for example is not native on windows, but runs
[Join a game while other players are racing]
Yes, I meant a new-comer to an existing race can download all files and joint
the next race. Of course the server could be setted up not to allow other
player to join a game, but if the admin want this, why not?!
As you probably have noticed I am an unreal tournament player, if you know
this game, there it is also possible to join existing games, and it is really
a good feature. It also allows you to download maps while a game is running.
[combine source files for client/server]
I have no solution for that right now, because I am not a automake/autoconf
expert. But I will ask a friend this weekend, he really knows about that.
Changed ideas about the future functionality of UltimateStunts. This new layout will (hopefully) better fit the future needs.
Removed window-system dependent stuff. This now only is the central place for rendering (so it's openGL only code)
A new class for future GUI building
A wrapper class for windowsystem-functionality
Track loading and maintaining its data
A thread API wrapper
connection between cfile and automatic downloading
An interface between the network-and-simulation stuff and the rest of the program, acting like the old "network"-class
Base class for all simulation models
graphics (glut, GL)
background : graphobj (GL)
car : graphobj
background : graphobj (GL)
approx : simulation
[some interface connecting cfile and server for downloading]
physics : simulation
[containing collision-data etc.]
anything new on the client/server front ?
is it decided which part will be sent over network and what the server has to do with it - or what the client has to do with it?
just asking cause i'm very curious about the next release ;)
This discussion was stopped on the forum & continued on e-mail some time ago, and the result was version 0.3. Networked multiplaying is not a priority, but the versions > 0.3.0 have a very flexible simulation system in which almost any network configuration is possible once the network code is finished. Currently I'm working on the physics engine, where progress is going very slow. I think I'll release a version 0.4.2 with unfinished rotation code.
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.