First release of renewed QGears.

[Akari]

The first release, at last.

It includes only model mechanics. Every thing that model can do at phisics level: move, collide, jump, climb on ladder, turn are now implemented and scriptable (using LUA). You can find documented finctions and methods in test_script.lua file in data directory.

Download:  http://zidane_games.webhost.ru/qgears_engine.rar

Next major step will be extract and implement graphic model, animation and all related things.

and Happy New Year to everyone! =)

 

[obesebear]

Absolutely amazing!  I was a little worried this project had died, but I see it's still in full swing.  Great job!

I do have a question about QGears for those involved in the programming concerning the final official build.  There have been a lot of rumors as to it simply emulating exactly what the game already looks like or allowing more updated models and backgrounds.  Has there been any decision as to which route you guys will be taking in the designing of QGears?

Allowing the models to be easily textured or have a more common design than .p files could really allow this to take off and become wildly popular.  Then again, I'm not even sure if that's possible

 

[yoshi314]

well the game could use multiple model types. just as many doom/quake ports do - you can use sprites as well as quake1/quake2/quake3 *.mdl files with no problems.

there should be support for legacy file formats (meaning - native ff7 file formats), but there should be (in the future) support for other formats that are more easy to create/edit and offer more features.

 

[Cyberman]

well the game could use multiple model types. just as many doom/quake ports do - you can use sprites as well as quake1/quake2/quake3 *.mdl files with no problems.

there should be support for legacy file formats (meaning - native ff7 file formats), but there should be (in the future) support for other formats that are more easy to create/edit and offer more features.

Well it's your idea it's open source go for it

Cyb

 

[_Ombra_]

Hey Akari, what about the change log or the version number? We all curious

 

[Akari]

Hey Akari, what about the change log or the version number? We all curious

This is start of new line of releases, but it just preview, not actual release.

 

[Rixorster]

I got a few questions(Just out of curiosity):

Are you going to use LUA as a main scripting thingy for QQears on later versions(Cause if ya'd use LUA in QQears so that you could change lots of stuff just from the scripts, that would make it easier to customize it for your own likings)?
If you are going to use LUA as a main script that would control the games stuffies, would ya need any help with creating LUA scripts(Self learnt)?

Also, a suggestion(About yoshi314's post):

I also think so that you should use some other model types instead of FF7's original's, 'cause they're easier to create(For example, .mdl used in Quake/Half-Life) and should give less problems to work with than when working with FF7's model files.

 

[Akari]

I got a few questions(Just out of curiosity):

Are you going to use LUA as a main scripting thingy for QQears on later versions(Cause if ya'd use LUA in QQears so that you could change lots of stuff just from the scripts, that would make it easier to customize it for your own likings)?
If you are going to use LUA as a main script that would control the games stuffies, would ya need any help with creating LUA scripts(Self learnt)?

Also, a suggestion(About yoshi314's post):

I also think so that you should use some other model types instead of FF7's original's, 'cause they're easier to create(For example, .mdl used in Quake/Half-Life) and should give less problems to work with than when working with FF7's model files.

Just like you said LUA will be the main scripting language. All models will be converted to OGRE3D format (since we use this render). You can find converters from all popular formats to ogre on their site. The project was changed while ago specificaly to allow more customization and flexibility.

would ya need any help with creating LUA scripts(Self learnt)?

I think we'll need LUA scripters when we start translate ffvii scripts to qgears, but there are a lot of time before that. Though you can test existed functions, it's still far from real since level loading not implemented yet and you can't test game on real enviroment (you can in real, but it's not that easy to do).

 

[yoshi314]

Just like you said LUA will be the main scripting language. All models will be converted to OGRE3D format (since we use this render). You can find converters from all popular formats to ogre on their site. The project was changed while ago specificaly to allow more customization and flexibility.

that cool but will it be fine from legal point of view? - i mean, if you're planning to convert some data into other formats, will the game still rely on native ff7 data files?

 

[Akari]

Just like you said LUA will be the main scripting language. All models will be converted to OGRE3D format (since we use this render). You can find converters from all popular formats to ogre on their site. The project was changed while ago specificaly to allow more customization and flexibility.

that cool but will it be fine from legal point of view? - i mean, if you're planning to convert some data into other formats, will the game still rely on native ff7 data files?

It's not legal, but everyone can see packs of copyrited sprites for different rpg engines. Engine itself will not include this data. I think we will provide demo game with our own models as demonstration of engine posibilities. For now I think about converter that will need PSX disk to convert all models to usable format and install them as game for q-gears engine. Engine will not support native game formats.

 

[Cyberman]

Legal: Converting data you have into an intermediate format. 
Illegal: Distributing the original data, or data created from the copyrighted material.

It's ILLEGAL to distribute it, your license only covers you using it not giving away new formats and copies of it.

Akari:
I'm partial for using SQLlite for a DB engine to pack the data together. It supports BLOB's and is used by several programs on the net. More importantly it's public domain which means it can be freely used for whatever purpose one wants.  It's also quite compact for an SQL engine (256K) it's lousy for large databases in which multiple users have access however for a single user it's more than adequate.

Cyb

 

[yoshi314]

using sqlite for data storage seems pretty inefficient.

maybe implement something on top of physfs ? ( http://icculus.org/physfs/ )

 

[Cyberman]

using sqlite for data storage seems pretty inefficient.

Define what you mean by inefficient? What qualifies efficiency in this case? I'm not sure I follow you. 

maybe implement something on top of physfs ? ( http://icculus.org/physfs/ )

Ummm that's a file system toy.  Sure it's easy to make a data collection using ZIP with it.  I'm not sure why you need to do that really.
Are you thinking this would be good for creating the intermediate data to run the game? (Virtual FS with a cat box directory approach)
SQLlite or PhysicsFS makes no difference really.  One does need to understand what the engine is doing. FF7 does not use the FS most of the time for example (see those archives the PC version uses that should be a REAL BIG clue).  Using file names etc. may not be the most affective method to translate the abstract layer presented to the engine.  What does the game need? Does the data need an RDBMS (it probably doesn't).  However having an SQL engine might be quite handy (just because you don't use most of the features doesn't mean you might not later).  PhysicsFS is a DB that acts like a file system as far as I can tell (and it's a RDBMS because it hierarchically organizes data in subdirectories).  Bottom line what translates the abstract layer (for the Game Engine) that the most people are familiar with (SQL is kind of ubiquitous) is likely the best choice.

As for efficient ... I don't know is that something the current project even need even worry about? I thought working might be more important.
People are also fairly familiar with SQL.

Cyb