project files for topdown, common parsing function and format

[kryton9]

Guys, it is obvious that we are going to need separate project files for topdown. Like, ships, scenes, animations, effects, user settings and even our tool programs auxillary files, like user settings for the tool.

It would be neat agree on a file format that is flexible and can be parsed by one parsing routine.

My preference because it is so easy and flexible is the csv format.
First row contains field names
all other lines are records with fields of data for example:

modelName,modelPosX,modelPosY,modelPosZ
excalibur,-10,0,-25
tesla, 5,10,7

so the comma is the field delimiter and cr$+lf$ is record terminator

This way we can prepre files by hand in excel and sort the fields easilly and reorganize as we like.
The thinBasic parsing functions are made for csv type files and make like easy.

Let me know what you think?

[Michael Hartlef]

Agreed, didn't Petr had implemented something like this for the gamelevels allready?

[Petr Schreiber]

Hi,

yes, I think. But it get lost somewhere :)
Something similar is done in files for ship definition.

Regarding levels ... there should be also lot of dynamic stuff, so maybe some triggers for actions ( radio message, spawn point ? ). This should be thought deepely, I will have a look again at the mission plot to get idea what we will need.


Bye,
Petr

[kryton9]

Ok, sounds good. thanks

[kryton9]

I know we thought this was resolved, but I just have had a feeling there is a better way to handle these support files than what we have now. Right now it seems like we have to write parse subroutines for each outside support file. I think it can be done with one subroutine.

Here is my thoughts:
We have only one parse subroutine, it can read all outside source files. How can this be done?
We setup Types for each type of object the outside support files contain. All similar objects will be in one support file for that type.
Since we only have the ships outside support files now, we can use that for an example.
Instead of having a file for each ship, all ships would be in one tShips.txt file.

Since thinBasic has very powerful commands for dealing with folders, files and data via csv files, we should try to use those.
With these tools here is how it would work:

All support files will be in one folder. This way with one command we can know how many files are in that folder. The filename, well the prefix, will tell the load subroutine what user type to use to assign the values it reads. Then using the powerful csv file handling commands, the subroutine can read all the values and assign them to the proper values.

So first we would have to define carefully thought out user defined type for all support files before we use them.
Then the filename of each support file will reflect the type that it would use. So with the ships, they would all be in one file named tShips.txt

Then with the thinbasic commands we can know how many records there are in that file, it can then dimension the array of ships for us and load all their values.

Again sort of reversing the idea, we would have one save subroutine.

This will help auto dimension our arrays, we can write tools to help create the support files since the format is so easy and we could just copy and paste those load and save subroutines to all tool programs for the game.

We should just think about this for now till the user types being used in other user types is finished. This will give almost the power of class inheritance in a way.

We could define, engine types, then that type can be used is so many different types of vehicles for example.

I hope the idea makes some sense as it sort of came to me as I have been restless with this for weeks, but I think this is quite doable and will be a lot simpler and cut down on code through out our game development code and all the supporting tools we develop.

[Petr Schreiber]

Hi kryton,

very nice!
I would maybe be for individual files for each ship, names would be ( for example ) SHIP_Name_Faction.txt.
This way it will be easier to tune ships individually, which would be harder to patch when all would be in one file.

I would be happy if the engine could be quite basic (only needed hings like physx, AI, ... ), and the game content would be defined from files.

I need to think it more deepely, but now I think about this kind of definition files:
Mission - contains all we need for mission, where player starts, whats the goal, music
Campaign - just list of mission files
Ship - ship definition


Bye,
Petr

[Michael Hartlef]

An event system would be great then. Imagine it like a stack of actions, each triggered at a certain time. The game itself would have one, and each object too.

Each loop, the engine would go through the stack and check if an event has to be activated, triggered, . Each event has an eventtype, starting time, lifetime, n-parameters.

The EventStack could look like this type:

type EventStack
eventtype as long
active as long
stime as long
lifetime as long
parameterlist as long
end type

Events could be something like, FireShoot, load music, load level, update FighterPosition, etc etc. Like I said, the EvenStack could exist for the game and for each object.

I developed such a system one time for a game a friend of mine was working on. This was written in Blitz3D where you could add something like this to each model.

Well, just an idea
Michael

[Petr Schreiber]

Hi Mike,

yes events are must.
I was thinking of some trigger areas too.

Thanks,
Petr

[kryton9]

Glad you guys are excited by the possibilities. Also if you think about it, at least this is my feeling, it is lots of fun working together like this. I will look forward to more such projects. So, it would be great to use TopDown as our first project and develop the foundational systems as thinBasic grows too. I think we can come close to the coolness of OOP, using well thought out user types. And with the user types within user types, that sort of power will really make it neat.

We also should work on our tools. For instance Petr mentioned the backgrounds. That is why I was trying to work on the model viewer as a base, then with those features can use that to setup scenes, with background objects of all sorts. WE should develop the tools for the game and then use the tools to create the game and see how it works.

This also leads to how we will handle skyBox/Dome, will a nebula be part of the that as it is currently in instant action?

I think with all our tests and super progression we have made so far, it shows how powerful thinBasic is with the great modules you guys added. I think we can take our time now and think about formats, how to handle play events (triggers), how paths can be created etc.

We have lots of work to do making these foundation tools.

Petr, the ships would need to be in one file, but if there are very different ship types, then they would have their own user type and hence their own file. So that the support file name reflects the user type those support files will load into.
I think we can have a very simple flexible system. This way the load module know which user type to use with the file and for all the objects within it.

The engines could be their own types, then our ship type can use those types. So we can break things down into components. That is why planning will be important.

Triggers, I have no idea how they work. I have used them for creating maps for other games, but I always used their tools and never understood how it was handled behind the scenes. Am very anxious to see how that works!!

Also, i have been trying to develop a nice onscreen display system and I think TBGL needs more command for this type of work. What I was trying to do is this for the asteroid test version we have now where we shoot it.

The idea is this a nice, as we have seen in many games, a nice translucent radar screen in a corner of the map, usually on the right middle top. It usually has dots for friendly and enemy ships, but in this case we have astroids. So I thought 3 colors on the radar.
Red the asteroid is lower than your position, Yellow you are in the same height range, that is if you turn left or right you should see the asteroid. Green, the asteroid is above your position. As you rotate, the radar rotates to reflect what is ahead of you at the top of the radar screen. I can't get this working with the commands we have now and especially when the resolution changes and if you put text near it.

Maybe as a test you guys can try creating one these week to see what I mean, while I work on the gamepad stuff and some other ideas. That is if you have time to test. But studies and work first as always, this is our fun!!

[kryton9]

Mike, when you have time, can you just put in outline form how you did your triggers. I know you described it above, but I was not sure how it was attached to an object, how it was called and used. Just a worflow diagram to give an overall idea, nothing to detailed. Let me try to understand the overall process, then I can process the details later when you have time. Thanks.

[Michael Hartlef]

Sure Kent, I will try to come up with something over the next days.

[kryton9]

Thanks Mike.

[kryton9]

OH MY, oh my... I might have found the perfect solution for support files. It does support files the way Petr originally wanted, is totally flexible and as simple as can be. I came upon it in working on Remmer tonight. I decided to add one more feature to this version and came upon this really cool class for creating ini files. It is sooooo coool.

If you guys are interested, it would be easy enough to make it a module for thinBasic. Look it over, tell me what you think.
Go to your Turbo Delphi Help, set your filter for Delphi and do a seach on this:
tIniFile

Look at the "Using TIniFile and TMemIniFile" section. As you can see they have 2 very powerful methods.

Here is a page with a great explanation and working sample:
http://delphi.about.com/od/objectpascalide/l/aa120401a.htm

This is the best of all worlds if you ask me. Amazing!!

[Petr Schreiber]

kryton,

we know Eros is not from Earth, but did you know he is also able to travel in time ?
This is why "INI" module already exists in thinBASIC although you requested it now :)

INI_GetKey
INI_SetKey
INI_GetSectionsList
INI_GetSectionKeysList

INI files are quite interesting, and lot of people is used to ... use them :). Maybe it could really be the solution!


Bye,
Petr

[kryton9]

That is amazing Petr, well there we go, that is the solution I think.

Eros we need videos tutorials of you showing us all this unknown power in this wondeful langage of yours!!

I am glad Petr knew about this, as other features he points out that I don't know about.

Thanks again Petr for knowing about that!!

[ErosOlmi]

Ken,

I do my best to keep an help file updated. Many times reading help file in not first option for many people (me included) because it takes a lot of time most of which dedicated to understand how help is organized (every help file has its own organization style). But, believe me, it takes more time to write help file than developing new functionalities.

Regarding INI file, thinBasic has a specific INI module (http://www.thinbasic.com/public/products/thinBasic/help/html/ini.htm) that is quite fast in execution so even big INI files can be handled quite easily and quickly. So far we have developed the following functions but more can be added if needed:

INI_GetKey (http://www.thinbasic.com/public/products/thinBasic/help/html/ini_getkey.htm)
INI_SetKey (http://www.thinbasic.com/public/products/thinBasic/help/html/ini_setkey.htm)
INI_GetSectionsList (http://www.thinbasic.com/public/products/thinBasic/help/html/ini_getsectionslist.htm)
INI_GetSectionKeysList (http://www.thinbasic.com/public/products/thinBasic/help/html/ini_getsectionkeylist.htm)

We like INI files for storing application parameters. XML files are also good but I personally prefer INI because they are easy to handle and to understand if key names are well written.

Let me know.
Eros

[kryton9]

Thanks Eros, this is going to be great to use!!

[kryton9]

I guess with the ini file. We can just add sections to it to allow new features to come into the program, game etc.

I am thinking that each project(scene) will have its own ini file. A level might have more than one scene, probably numerous scenes.
So perhaps we could do something like this?

Game Ini
the sections contain the Level Ini's used.
the level ini's have the scene ini's used to make the levels
the scene ini's have everything that makes that scene

I don't know where the triggers for the game would go? I am sure I am missing some other things, but wanted to get the ball rolling on this thought thread too :)

[Michael Hartlef]

Boy you are active. ;) But that is good, that motivates me to get off my ass and be productive for TopDown!

[kryton9]

Mike, I get excited and have my up and down moments, the mind was clear so thinking of many things the last few days :)