Structure of libbattle

  • Lyakhov

    Lyakhov - 2005-11-07

    File structure of the current libbattle 1.1.3:

    iodata -- contains input and output data types implementation: it must be complitely rewritten.

    unit -- this can be extended, but implementation will be different

    group -- similar to unit

    list -- the list of units in time. Must be complitely rewritten.

    New structure as I see it:

    1. OOP (usage C++ and STL instead of C structures)
    2. Expansibility: this must be planned and projected: libbattle 1.1.1 wasn't released because of awful memory distribution error, which i cannot debug. And this error was created when I tried to add simple expansion. All expansions are to be planned before implementing.
    3. Test system. Do anybody know something about testing big programs(nowadays techs of testing) -- I'm not good in testing, maybe we should ask a professional tester to help us creating autotesting code.

    Objects of new structure:

    class scheduler: controls time and happening of events (instead old list).

    class event: represents all events whose could happen: movement, shot, destruction, spawn(reinforcement) of unit etc.

    class map: contains all geometry (2d surface of battle)

    class unit, class group -- these are similar to current classes.

    class battle: contains everything and organizes interface(battle) between its parts (scheduler, map, groups). For user.

    class iodata (maybe idata and odata) -- new implementation of new data. (e.g. we need format for storing map etc)

    Anybody who is going to work with libbattle, respond and discuss this structure, please.

    • Jing

      Jing - 2005-11-23

      I briefly went through list and dataio. A couple of immature thoughts:
      1. using STL. vector, list, and map.
         Scheduler for sure can use containers.

      2. Do you want different types of units? This actually reflects my lack of knowledge of the system. I think we can make a base (virtual) class then extend it for future use. Same thing can be done to group. I also suggest using containers in group.

      3. battle and event will get complex. I don't have a good idea for this yet. Neither do I know how to define a format to store map (i.e. iodata).

      I will keep reading the rest of the code. ^^

    • Lyakhov

      Lyakhov - 2005-11-24

      1. Agree.
      2. Yes, we need different types of units, so your suggestion is correct and it will be done this way :)
      3. Agree. Class event can be done as unit -- virtual, and then extended to different concrete events. Anyway we need an object for scheduler.
      I don't think battle will be too complex. It will agregate its parts and just runes their public methods. We can go without it, I think -- using just function battle (like now) -- but it breaks OOP.

      What do you think about start point of development? What we should begin from?
      Should we fully understand all classes and write a scheme of their interaction (UML?) or we can start implementing some parts right now(if so, what parts?)

    • Tojo

      Tojo - 2005-12-01

      Is there already someone thinking about the new implementation of the libbattle module ? ( or trying to do it ? )

    • Lyakhov

      Lyakhov - 2005-12-02

      I'm always here :) I'm thinking about creating small tasks so everyone will know what to do.
      I begin from gui, so it will take some time (about a week, I think), when I'll do this work.
      But we can discuss the issue right now.

    • Tojo

      Tojo - 2005-12-02

      Take your time. I am not in a hurry. I had just a few questions :
      1 - is the battle module used in real time ?
      I mean : you enter data (units), you compute next action, then you save data, output on the gui, and so on in an endless loop ?

      2 - How are the actions of the units and the groups determined ?

    • Lyakhov

      Lyakhov - 2005-12-02

      1- I think there are to be two ways (to choose by user): real time and not real time in the libbattle 2.0. In current libbattle 1.1.3 there is only not real time mode. But gui isn't connected with it yet (it is to be done) so it is a task for improving current battle module to 1.2.0:adding support real time mode (it isn't hard work, I think -- just adding a call of function gathering all info about current state of battle in desired moments of time)

      2- Now it is very simple: groups don't do anything, and units just shoot in random moments of time (Poisson distribution).
      In 2.0 I'm not sure about how it can be done. I think that it can be done setting special function for each unit which will determine its actions. For groups it is more difficult.
      After creating visualisation of battle we'll be able to control units in real time (like RTS). You asked really hard question, I think. Current mathematical equations do not take it into account. Maybe it can be taken into account with nonlinear velocities of units and complicated distribution densities for shooting.

    • Tojo

      Tojo - 2005-12-02

      I have seen your paper about Maths in OpsModelling. Yes, so all we can control for now is the moment they shoot and the probability to kill their target. Am I right ?

      I would suggest we begin with discussing the new functionalities we could add to the new version ( if that hasn't been done already )
      That will make things clearer for all I think.
      This will let us also determine an approximate structure.

    • Lyakhov

      Lyakhov - 2005-12-02

      Almost exactly. We can control rate of fire of unit too.
      About functionality: yes, it would be well to discuss this issue, it was never discussed, though many words were said by myself (in different docs).

      I'll write my thoughts about this on Monday, because I won't have free time till then :(
      (very important and interesting seminar about quantum teleportation and quantum computations will be on Monday, I'm to prepare it)

    • Lyakhov

      Lyakhov - 2005-12-05

      Functionality to be "added" (which imply rewriting of the almost all code, so it is hardly can be named addition) to libbattle-2.0:

      1. Support of battle map. --the most important thing. Map should be at least 2d flat, but it would be much better that it would be 2d surface in R^3.

      2. Change unit properties p,l (probability and fire rate) from constants to functions of unit state, enemy unit state, time, map position.

      3. Add a function of distributing fire, which is also like in 2.

      4. Add movement of units with velocities -- functions, like in 2.

      5. Add support of reinforcements: spawning new units.

      6. Add support of different unit types.

      Maybe I have fogot something. Also other improvements can be done in 2.1 etc.

    • Tojo

      Tojo - 2005-12-05

      A lot better. I think we can already begin with map and units.

      1. For map : I thought about a map composed with cells which have different heights : it is not perfect, i know.
      5. Is reinforcement, switching a unit from one group to one another ?

    • Lyakhov

      Lyakhov - 2005-12-07

      1. Choice of map data is important and depends on how we'll manipulate this data. I also thought about cells. Drawing of the surface isn't our primary task, so this representation maybe suit to us. Maybe it will be worth to look into other free projects who are working with maps or geometry.

      2. By reinforcement I mean something like 'creation of new unit', or getting it from a group which isn't involved in battle. Also merging of groups may be good idea. But we need to define what is group. In libbattle 1.x.x there is only two groups, attacking each other.

      P.S.I've finished tasks for gui-1.0 somehow, so I can start working on tasklist for libbattle.

    • Lyakhov

      Lyakhov - 2005-12-08

      I have better idea about map: similar to spline interpolation, but for 2d surfaces.
      We have regular grid on x and y axes containing Nx * Ny points {x[i],y[i]},i=1..Nx*Ny and table of function (x,y)->Z(x,y):  z[i]=Z(x[i], y[i]).
      We want to interpolate Z(x[i], y[i]) to arbitrary Z(x,y).
      'Cells' interpolation is piecewise constant interpolation. It doesn't allow us to calculate velocity (gradient!) on the surface.
      We can make piecewise linear interpolation -- triangulation. This will be enough I think. But we can go further and try to make smooth interpolation. I think we need look through few books about this topic.

    • Tojo

      Tojo - 2005-12-08

      Ok, I am looking for this too on my side.

    • Tojo

      Tojo - 2005-12-14

      I wanted to know how the map will be inputed
      - as a set of points ?
      - as a bitmap describing elevation ?

    • Lyakhov

      Lyakhov - 2005-12-14

      I think that a set (array m*n) of points will be more suitable for mathematical interpolation. What do you mean by a bitmap describing elevation?Is it also a set of points, or not?

    • Tojo

      Tojo - 2005-12-14

      I didn't explain myself well :-o However, that's the answer i expected.
      I said a "set of points" for a "a set of sample points" (i.e. not all of them)
      As opposite to a "bitmap" where for all tuples (a, b) of the map, the z value is given.


    • Lyakhov

      Lyakhov - 2005-12-15

      We cannot store all points (x,y,z(x,y)) of map because this set is continuum :) I suppose we'll be storing z(x[i],y[i])[i] at each point of flat grid x[i],y[i] and also data of interpolation (e.g. coefficients of spline) -- so it is your 'bitmap'.


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

Sign up for the SourceForge newsletter:

No, thanks