General development issues

Developers
CJP
2002-11-15
2004-01-15
  • CJP

    CJP - 2002-11-15

    I've got some issues that don't fit in the other groups. So I put them here.

     
    • CJP

      CJP - 2002-11-15

      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
      >look "nice".

      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:

      graphics
      network
      sound+GUI
      physics
      AI

      This is approximately the order in the planning-page of the website:
      0.0-0.1
      0.1-0.2
      0.2-0.3
      0.4-0.7
      0.8-0.9

      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.

      CJP

       
      • bones

        bones - 2002-11-17

        >  and for the rest work in the following order:
        > graphics
        > network
        > sound+GUI
        > physics
        > AI

        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.

         
    • bones

      bones - 2002-11-17

      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
      have graphics!

      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
      client.

      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
      using cygwin.

      [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.

       
      • CJP

        CJP - 2002-11-18

        reason
        --------------
        Changed ideas about the future functionality of UltimateStunts. This new layout will (hopefully) better fit the future needs.

        Background information:
        -----------------------------------
        graphics:
        Removed window-system dependent stuff. This now only is the central place for rendering (so it's openGL only code)

        gui:
          A new class for future GUI building
        winsystem
          A wrapper class for windowsystem-functionality
        track
          Track loading and maintaining its data
        thread
          A thread API wrapper
        filectrl
          connection between cfile and automatic downloading
        server
          An interface between the network-and-simulation stuff and the rest of the program, acting like the old "network"-class
        simulation
          Base class for all simulation models

        syntax
        -------------------
        classname [(lib-dependence)]
        [->method[{set_of_methods...}]([..])]
        [->property[{set_of_properties...}]]
        ...

        Old
        ----------------
        callback (glut)
        graphics (glut, GL)
        sound (AL)

        background : graphobj (GL)
        camera
        car : graphobj
        graphobj (GL)
        sndsample (AL)
        soundobj (AL)
        texobj (GL)
        tile

        cfile
        cstring
        fileutil
        matrix
        vector

        cardata
        network (BSDsock)

        New
        -----------------------
        graphics (GL)
        ->set{Options...}(..)
        ->setTrack(..)
        ->setCars(..)
        ->setCamera(..)
        ->Update()

        gui (SDL)
        ->gui(winsystem)
        ->show{Menu..}Menu()
        ->get{Data..}()
        ->set{Data..}(..)

        sound (AL)
        ->setSoundObjs(..)
        ->set{Option..}(..)
        ->Update()

        winsystem (SDL)
        ->winsystem(..)
        ->set{Option..}(..)
        ->set{Callb..}Callback(..)
        ->RunLoop()

        background : graphobj (GL)
        camera
        car
        graphobj (GL)
        sndsample (AL)
        soundobj (AL)
        texobj (GL)
        tile
        track
        ->LoadFromFile(..)
        ->background
        ->tile
        ->...

        cfile
        cstring
        fileutil
        matrix
        thread (SDL)
        [some multithreading-API]

        vector

        approx : simulation
        cardata
        filectrl
        [some interface connecting cfile and server for downloading]

        network (BSDsocket)
        ->network(..)
        ->sendData(..)
        ->receiveData()
        ->..

        server
        ->server(..)
        ->sendInputData(..)
        ->receivePositions()
        ->sendCarChoice(..)
        ->receiveHiscore()
        ->getDownloadStatus()
        ->setDownloadDir(..)
        ->...

        simulation
        ->Update(..)
        ->Synchronise(..)
        ->setInputData(..)

        physics : simulation
        physics-related classes
        [containing collision-data etc.]

         
    • Werner Macho

      Werner Macho - 2004-01-10

      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 ;)

      greetings Werner

       
    • CJP

      CJP - 2004-01-15

      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.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks