The UFO:Aftershock E3 interview is here!

[Slaughter]

Aftershock E3 interview:

The interview you have all been waiting for is here! Mike have finished writing it down, and it is great! 50 questions about Aftershock was answered, and it's you, the fans, that asked them. So thanks to everyone that submitted questions, thanks to Mike for doing the interview and thanks to ALTAR for answering so many questions. The interview can be found here as part of the site, or downloaded here. Here's a quote from the interview:

 

25) In the trailer, it appeared that soldiers can enter buildings in Aftershock. Will there be different levels in Aftershock, so that soldiers can walk under bridges, snipe from the top of buildings, etc.?

 

ALTAR: Yes, there will be multiple levels. Soldiers will be able to climb ladders and snipe from building tops.

 

Model Importer & Exporter for Aftermath:

Fulby is still improving on the Model Importer & Exporter for Milkshape 3d daily. You can read more about it here, and download the beta here. Suggestions and comments are received with thanks.

 

AvP modification and new Rebalance:

With the newly released Model Importer & Exporter for Aftermath, modding is yet again flourishing. BlackAlmaz is working on a Alien versus Predator mod, and you can read more about it and see screens here. The additions are quite stunning! If you have comments or requests, post them in the thread.

 

And with all the new possibilities now available, Aralez have started work on his Rebalance mod again. There is already a new beta out (6.8), and you can find a link and comment on it by going here.

[Aralez]

After reading the interview i have only ONE question: WHERE CAN I PRE-ORDER IT ?! Wow, i mean even if they would only do the half things of what they say the will do, this thing will rock ! gimme-gime-gimme....

[Captain John Ferigad]

Hehe, i have only 1 Question that would intresst me Personly, and that's it:

 

Will be the Mechanical Units like Droids and Robots be countet as Member's from the Team or will be they handled like a "Controlled" None Playing Charakter?

 

If they would be like NPC`s, that would cool, a Team of 7 Soldiers with 30 Robotic Soldiers , armed with G-36's and ready to rumble , muahahahhaah

 

The Interview is very good....but this one question would just intresst me still :devil:

 

Oh and hello again by the way, long time ago that i was here ^^

[Slaughter]

Welcome back Captain! I don't know the answer to that question, but I'm sure we'll find out soon enough.

[sigget]

42) Aftermath's main files consisted of hundreds of small files. Will you instead use a database this time?

 

ALTAR: It will remain as it was in Aftermath.

 

Then its probably worthwhile to still develop tools for Aftermath, since they're likely to be customizable to support Aftershock aswell later. So keep up the good work on model editors and such =)

[Slaughter]

Indeed sigget . I would still have preferred a database, but I guess you can't have everything...

[Accounting Troll]

(Salivates Homer Simpson style)

 

I'm glad they're putting in a more political aspect. I loved the politics in X-COM Acopalypse, and the way you could hire hybrid and android soldiers if you were on good terms with their communities.

[sigget]

I wouldnt =) I just cracked the formats of War of the Ring and they was in the form of a database. I dont think there'll ever by mods for that game since inserting into the database would be very difficult and time consuming to code. And text files are faster to read than database tables. I'd go with designing weapons, units and so on in excel and wrinting to textfiles just as they did with Aftermath but instead write them into several files. One for each weapon/unit/etc so that extra weapons and so on are easy to add for modders. Makes the game a bit more dynamic.

[Slaughter]

Hmm, why is that? I mean, I get the part about faster, but easier? Isn't it easier to add a new entry to a database table for a new weapon than modifying several textfiles? (guess that wouldn't be a problem if there were one textfile for each weapon though)

[Fulby]

Adding to a database is easier if you're sending commands to a server running on a computer, but with a game you'd be editing the database files on the HD which will be the same as editing text files but much less transparent than plain text.

 

Fulby

[Slaughter]

So tools like MySQL-Front (Silent Storm use MySQL) and Access (not that I'd recommend it for games ) does not work locally? It's as easy to edit a database locally as it is on a server. How hard can it be to make a tool for editing a local database?

[Lurker]

Other Aftershock Interview discussions:

 

https://forum.ufo-aftermath.com/index.php?showtopic=104#

[BlackAlmaz]

its not to bad...i will mis the chance to fly..

but it seems great!

 

as long as i add my models there...and maybe even make a better AVP mod for that game.

cause the weapons still look the same in the trailer..so my m4 will be a welcomed change

 

i cant wait for that game and you guys next year..i hope we will have lots of fun fixinf bugs "features"

[Lurker]

I too think it will be fun to have more of the same and better of the same.

 

Still, I know that there will be a bunch of people, including me, who will complain that you can fly in XCom and fly in Apocalypse, yet you still can't fly all these decades later in Aftershock!

 

As they get the soldiers moving through different levels, hopefully Altar will eventually cave in and make the soldiers so that they can fly through the different levels.

 

But, if I understood any of the original process with UFO:AM, I believe that it is going to be a lot of work for Altar to deal with multiple levels and get it all to work right.

 

I imagine that right now, Altar is having a hard time trying to figure out how to extend SAS into three dimensions. Altar had enough problems handling two dimensions with SAS.

[Fulby]

So tools like MySQL-Front (Silent Storm use MySQL) and Access (not that I'd recommend it for games ) does not work locally? It's as easy to edit a database locally as it is on a server. How hard can it be to make a tool for editing a local database?

You can set up a local server, which is what Silent Storm does using Microsoft SQL Server 2000, but that in itself doesn't allow you to mix mods from different people. You have to send/publish/distribute the mod in such a way that it can be added to the other player's local database instead of replacing it.

 

Silent Storm does it by comparing the mod's database to the original and storing the difference in a file using a custom format. You publish the file which the game can interpret into what changes need to be made to another player's DB.

 

This was the reason I wrote ALPine, instead of modifying and sending the entire (for example) weapon file - which there could only be one of so only one weapon mod works at a time - you send just the new weapon data and instructions to let ALPine add it to another game's existing weapon file.

 

Using separate files for each item can avoid this. If all the items are placed within one directory (or all weapons in \weapons, etc), and the game scans the directory when it starts and loads every item file it finds. This only works if the game scans the directory, if each item is referenced in an index file and the game looks in there then you still have a similar (but simpler) problem.

 

Fulby

[Slaughter]

But can't you make a system where every mod made uses it's own database? If mod X is active, check the reference database for mod X and use the values there instead of the ones in the normal database.

 

And what about databases similar to Access? They don't need something like MySQL server installed...

[Pete]

My experience with Access in the real world has presented its many limitations and many annoying bugs (such as constantly corrupting databases).

 

I'd much prefer a system that doesn't rely on Microsoft's half-baked coding to work.

[Slaughter]

Yeah, but there are good alternatives similar to Access (in that it doesn't need a server running).

[sigget]

Exactly. Using an SQL-server is very flexible, but what overkill. Especially for the typical game that only reads in its configuration files once or once per level. If the data is so massive that it cant be held entirely in ram, then the sql-server starts making sense again, since it could then perform quiries on the data.

 

And ALTAR wouldnt have to be editing several files, as i said, the text files are generated from excel spread sheets, generating to multiple files shouldnt be much harder. Excel is very customizable and exports functionality for external applications to read and process excel spreadsheats.

 

I think the: "scan directory and parse all files"-approach would be great. Its been used by countless games and is great for modding. For example take the .shader-files in Q3.

 

Slaughter, would you pass this on to ALTAR?

[Fulby]

But can't you make a system where every mod made uses it's own database? If mod X is active, check the reference database for mod X and use the values there instead of the ones in the normal database.

 

And what about databases similar to Access? They don't need something like MySQL server installed...

Each mod having its own database isn't really different from each having its own copy of listofweapon.txt, listofarmor.txt, etc. They both store the game data, just in different formats and you use different editors (Notepad vs. Access) to modify the data. It still doesn't address the problem of merging data from multiple mods.

 

If each mod's data store (database or directory with files in) only holds the modified data then the game could scan available mods (say in a \mods or \plugins directory) and add the data from ones the player selects. You still have a problem of changing existing items - it's easy to add new items to the game data but changing existing items could lead to conflicts between mods.

 

Fulby

[martin]

In Aftershock, our approach to configuration data is slightly different. We still use Excel for editing data, but we export them in a sort of pseudo-XML and then import them in a database (Postgres) and check them for internal consistency (this was a nightmare in Aftermath, to make sure that identifiers in one file match those in other files). The database then exports the data in a format quite similar to the one we had in Aftermath and these are in turn read by the game.

 

We would be probably willing to publish the SQL data from the database once the game is released if it was felt that it can help modding (from the preceding discussion I get the feeling it wouldn't); to store the data for one weapon in one file is an idea we can consider but I am afraid it will run into difficulties. The configuration data is interconnected: a weapon is referred in one table, where it is defined what it costs to produce, which building it is produced in, etc. (economic data, pertains to all equipment items), another table defines its caliber, reload time, etc. (unique information for each missile weapon), yet another table defines its range, accuracy, etc. for various modes of fire (multiple information for each missile weapon) -- it is difficult to isolate it. Take for example the relationship item-factory: we cannot have a single file for each weapon and single file for each building, because they are referring to each other. We could of course have a single file for what is now a single line in a table, but this would mean thousands of tiny files.

[sigget]

It doesnt necessarily require thousands of files. Again, take Q3, it has something like 3000 shaders (in q3 these define materials). They're stored in files named .shader and can contain several definitions in each file. For example goth_base.shader contains the materials for the old-looking bases. In Aftershock you could in a directory named weapons have a file called 'human_weapons.txt' containing:

 

uzi

{

reload_delay 0.25

fire_accuracy 0.0001

...

}

 

shotgun

{

reload_delay 0.45

fire_accuracy 0.05

...

}

 

and so on.

 

when a mod is installed it adds a file in the weapons-directory perhaps called avp.txt containing:

 

predator_nuke

{

reload_delay 5.0

fire_accuracy 1.0

...

}

 

 

Passing it through postgres sounds like a good idea. And it would remove the problem of incorrect references. Im not sure if you mean that it was a nightmare keeping the excel files in sync or if you're talking about coding integrity verfication into the game. Anyhow, the more independent a mod becomes, the more easy it will be for the creator to keep his files in sync, so he might not need the postgres-solution. And this way expansion packs are easier to make! *wink*

 

 

I borrowed the syntax from q3 .shader -files, in Aftershock they would of course be in the pseudo-XML format.

[Captain John Ferigad]

Predator Nuke....hmmm..

 

You know what i missed in ufo Enemy Unkown and X-Com Terror from the Deep and in Aftermath?

 

Nuclear Weapon Handling.

 

You got a big Alien Thread in your Home Terretory, it must be destroyed, and you civilisation got allready devoloped a mass destruction weapon..so why not use it, grab a Nuke and eradicate the whole Base?

 

You know, in Aftermath had it been get a cool effekt like the Nuke Use destroy a whole Alien base, but the Radiatation stimulate the Growing of Biomass.... that had been cool ^^

 

I just miss this Kind of Missions...like..."GO in, Place the nuke, get out, Blow the enemy Base Up"

 

That was the coolest thing in X-Com Interceptor, nova nuke, if you see that system is important for the Alien, grab a Big Bomber, fit a Noca Nuke, and Blow up the Sun

[Slaughter]

Okay, Martin just cleared up quite a few questions concerning Aftershock in this post. Go read it!