project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - BTAxis

Pages: [1] 2 3
1
Artwork / Alien bestiary
« on: March 02, 2011, 11:14:25 pm »
I'm making this thread because I think it's time we made a clear list of aliens we ultimately want to have in the game, which would be helpful for graphics contributors. I think the discussion about this should be done in two steps:

* First we need to determine what kind of enemies we want to have in the game, in terms of what the role of the enemies is in tactical engagements, what sort of hazard they represent to the player (and by extension, what sort of tactics they entice from the player), how they behave and how they complement the other enemy types.

* Second, we have to fill in the details for the enemies. Once we know what an enemy is supposed to do in the game, we can talk about what it should look like, what sort of innate abilities it should have, etc.

I'm starting off the discussion by first listing what we have, and then by making suggestions for how I think what we have can be extended.


What we have
This section lists the aliens that are either already ingame or are in an advanced stage of planning. What you read here should be considered set in stone.

Taman
* Role: Physically weak enemy with somewhat sub-average combat abilities, but with lots of mental capacity. Serves as a weak enemy for the early game, and a dangerous psionic foe for the later game.
* Implementation: Done.

Ortnok
* Role: Tough and strong, this enemy is a foot soldier fighting at the front. It should be used by the AI as a shock troop, preferring a direct assault over careful tactics.
* Implementation: Done.

Shevaar
* Role: The Shevaar is the aliens' secondary infantry combatant. It is meant to be fast, with a lot of TUs available for moving and firing. It should also have different inherent armour than the Ortnok, so different weaponry works well on it.
* Implementation: Done.

Bloodspider
* Role: The Bloodspider is more or less to UFO:AI what brainsuckers were to X-COM Apocalypse: small, fast and highly dangerous if you let them get too close. They don't have ranged weaponry, but are dangerous in melee. Their primary role is to harvest organic material though, so they aren't meant for combat.
* Implementation: Done.

Hoverbot
* Role: Hoverbots are flying, mechanical units. They have limited firepower compared to ground based units, and they serve mainly as scouts and air support for other aliens.
* Implementation: Done.

Breeder
* Role: Breeders are half-organic, half-mechanical vehicles meant to infuse victims with XVI. In battle their primary role is to find civilians and turn them into alien drones, but when attacked they can retaliate with strong psionic attacks as well.
* Implementation: Rough sketch. Open to improvement or complete redesign. Note: 2x2 unit!

Alien wormhole device
* Role: It's not an alien as such, but it behaves like one in base missions. The wormhole device channels the psionic abilities of the hive mind on the other side of the wormhole, so while it can't move or attack normally, it can use psionic attacks in tactical combat.
* Implementation: Done, I think? Again my knowledge of our artwork fails me. Tell me if you know.


What could come next
This is my personal idea of how the bestiary could be extended. The goal is to provide a number of enemies that require different approaches to beat, without going overboard and making too many similar types.

Alien tank
* Role: The purpose of this unit would be to be very tough and heavily armed. It's an enemy to attack from cover, because a direct engagement would result in almost certain death. It should be a 2x2 unit, so it can't enter confined spaces. It should also be mechanical. Mode of movement could be tracked, wheeled or legged, whatever works. Think ground-based, alien UGV.

Alien flier
* Role: Another aerial unit for the aliens, this time something more combat-oriented. Since the other flier is mechanical, this one should probably be organic.

Combat Bloodspider
* Role: An upgrade of sorts for the Bloodspider. The Bloodspider is a harvesting tool with offensive abilities, but this version is a straight up combat droid. It should be faster, tougher and deadlier than the regular bloodspider, and it should appear somewhere in the mid game.

2
Offtopic / Jedi Knights versus Megatron
« on: August 08, 2010, 12:42:39 pm »
I woke up with that phrase in my head, so it must be important.

3
Discussion / UFO:AI needs you. Yes, you.
« on: March 28, 2010, 12:13:05 pm »
In a FOSS project there are two kinds of people, those who contribute and those who don't. Not to imply that those who don't are in any way unimportant, but those who do are much more useful to the project. To those who are eager to see a new release, I suggest you get involved in contributing game content. There is a lot of things people can do, arguably the easiest being mapping. While not everything will actually speed up the next release, working on the game will at least keep you occupied.

4
Artwork / World maps
« on: January 15, 2009, 05:19:47 pm »
For a while now I've been playing with the idea of having alternative world maps, which I think could make the game more interesting to (re)play. So I set out to make such a map. The result I've attached to this post. I basically took a fractal generated map, cleaned it up a bit and then inexpertly cloned on Earth's texture. The result is... Well, not that awesome. Painting the terrain is harder than it sounds, and a lot of it doesn't really make much sense (for example there's rainforest closer to the polar area than some ice fields). Also, the map is still too fractaly. I should have redrawn the coastlines first and eliminated the smaller islands.

It's currently just a texture. I didn't make maps for terrain, population etc yet because I'm not sure I want to continue with it. Still, I hope this will inspire people to make more maps like it.

[attachment deleted by admin]

5
Coding / Small Code::Blocks package update
« on: January 08, 2009, 03:45:19 pm »
I've updated the C::B package with a newer version of gettext. This should get rid of any gettext related errors that have popped up in recent revisions. The package is available here.

6
Artwork / Needed: new starmap texture
« on: December 20, 2008, 01:59:18 pm »
As of current trunk (r20965) we have a rotating starmap for the 3D geoscape. However, our current texture doesn't look that good. This post is a call of artists to create a new texture. Requirements:
  • The texture must be square and the dimensions must be a power of two.
  • The texture must seamlessly repeat on itself (obviously)
  • The texture must be mostly dark, and the stars shouldn't be too colorful. This is a background starmap, so it shouldn't divert attention away from the globe.

Alternatively, we could use six textures, one for each side of the skybox.

7
Artwork / Needed: background image for campaign victory message
« on: December 18, 2008, 10:13:37 pm »
We are in need of a new image for use as a background when the player wins the campaign. We already have an image, but it looks more like the background for a "game over" screen. I have attached that image to this post. We're looking for something similar, but using a PHALANX craft. A good candidate would be the Starchaser model Sitters made recently, or the Stingray interceptor. These craft are not actually in 2.3, so they would make good teasers for the end of the campaign.

[attachment deleted by admin]

8
Linux / Read this before posting a bug report
« on: December 01, 2008, 04:20:54 pm »
Read our wiki article on reporting bugs for information on what to do.

Important: You should not post any bugs about the latest stable release. Such reports are generally not helpful because the stable release is a snapshot of an ongoing development process. If you want to report a bug, you should first verify it still exists in the latest development version. You can find instructions for getting the latest development release on the wiki, starting with the article about getting the source.

Alternatively, you can drop by our IRC channel (#ufoai on irc.freenode.net) and discuss the problem there.

9
Mac / Read this before posting a bug report
« on: December 01, 2008, 04:20:30 pm »
Read our wiki article on reporting bugs for information on what to do.

Important: You should not post any bugs about the latest stable release. Such reports are generally not helpful because the stable release is a snapshot of an ongoing development process. If you want to report a bug, you should first verify it still exists in the latest development version. You can find instructions for getting the latest development release on the wiki, starting with the article about getting the source.

Alternatively, you can drop by our IRC channel (#ufoai on irc.freenode.net) and discuss the problem there.

10
Windows / Read this before posting a bug report
« on: December 01, 2008, 04:20:05 pm »
Read our wiki article on reporting bugs for information on what to do.

Important: You should not post any bugs about the latest stable release. Such reports are generally not helpful because the stable release is a snapshot of an ongoing development process. If you want to report a bug, you should first verify it still exists in the latest development version. You can find instructions for getting the latest development release on the wiki, starting with the article about getting the source.

Alternatively, you can drop by our IRC channel (#ufoai on irc.freenode.net) and discuss the problem there.

11
Bugs prior to release 2.3 / Read this before you post a bug report
« on: November 21, 2008, 09:34:00 pm »
Read our wiki article on reporting bugs for information on what to do.

Important: If you want to report a bug, you should first verify it still exists in the latest development version. You can find instructions for getting the latest development release on the wiki, starting with the article about getting the source.

Alternatively, you can drop by our IRC channel (#ufoai on irc.freenode.net) and discuss the problem there.

12
Windows / UFORadiant vs GTKRadiant
« on: September 14, 2008, 05:54:41 pm »
This is for Destructavator and anyone else who's compiling UFORadiant from the UFOAI SVN.

I have noticed that for me, radiant is vere, very slow. Rendering is slow. Loading maps is slow. Doing anything to the map is slow. For reference, let's take the frame rate for dam.map. Disable the far clip place in the preferences and move the camera in the 3D view so the entire mpa is visible. For me, each frame takes 81 msec to render. Selecting the entire map and dragging it somewhere takes several seconds.

Compare this with the old GTKRadiant which I have installed separately. dam.map has a rendering rate of about 7 msec per frame. Dragging the whole map is a lot more responsive too.

Can anyone try this and report back here? You can obtain the old GTKRadiant from here:
http://zerowing.idsoftware.com/files/radiant/GtkRadiant-1.5.0.msi
It includes the ufo:ai plugin, though the definitions are outdated.

13
Artwork / Artist required for UFOPaedia images
« on: August 18, 2008, 02:21:38 pm »
As per the topic. We need people to create images for use in the UFOpaedia.

Currently the focus is on the images we need for version 2.3, as written down on the 2.3 TODO.

Images we need:
  • Bloodspider dead
  • Bloodspider autopsy
  • UFO Theory
  • The Alien Strategy
  • Orbital UFO Activity
  • Alien Infiltration
  • Odd Behaviour
  • The Alien Mind
  • Alien Communication
  • The Enemy On Earth
  • XVI Census
  • The Universal Serum
  • Alien Materials
  • Alien Body Armour & Alien Medium Armour
  • Continuous Wave Laser Operation
  • Anti-Alien Gas

For reference, take a look at our existing images.

Dimensions of the images: 438x1000

edit
Use the autospy images as a reference. Also please keep in mind, that you have to agree to release your work under GPL2.0 or later.

14
Coding / gtkradiant and plugin
« on: February 24, 2008, 02:26:03 pm »
The Windows version of gtkradiant, which can be downloaded from the development page, is getting old. In particular, the game plugin is rather behind when it comes to filters and flag labels. Unfortunately, I lack the skill to compile it myself, so I'd like to ask if someone can do this for me. If possible, it would be great if we could just update the installer.

15
Discussion / New soldier stat increase system
« on: February 12, 2008, 12:53:05 pm »
This thread is meant for me to present the new soldier stat increase system and for everyone else to discuss it.

BASICS
The new system is an implementation of this wiki proposal. Soldiers gain "experience" in combat vor performing various actions. As a result, their stats will rise, at an increasingly slower rate. Experience is gained and stored for every individual stat.

ASSUMPTIONS
These are the assumptions I made when writing the proposal and the code. Important to note is that these assumptions ar of the finished version of the game - not 2.2! So if an assumption clearly conflicts with 2.2, don't go off telling me I'm wrong, because I'm not talking about 2.2 here.

- Soldiers have an expected career length of 100 missions. That is to say, a soldier that is in active service, going on a majority of the missions, is expected to participate in about 100 of them over the course of the game, without being killed.
- There will be missions with less than or more than 8 aliens.
- XP will increase even outside missions, as a result of training facilities. Most XP should be earned in combat, however.

CAPS
These are the XP caps. A soldier can never gain more XP on a mission than the XP cap, no matter how much XP he earns from his actions. The caps are based around a "target" increase for the skill over 100 missions. For example, speed is set to increase by 15 points. To find the amount of XP x the soldier must earn to increase by 15 points the calculation is:
log 15 / log x = 0.6
log x = log 15 / 0.6
x = 10 ^ (log 15 / 0.6)
x = 91 (rounded)

This would mean an average of 0.91 per mission. Unfortunately, code limitations disallowed me from using floating point numbers for the XP values, so I do the division by 100 internally, and work with the calculated value.

Laziness, so here's the switch from the code (comments added here only):
Code: [Select]
case ABILITY_POWER:
return 46; //target 10
case ABILITY_SPEED:
return 91; //target 15
case ABILITY_ACCURACY:
return 290; //target 30
case ABILITY_MIND:
return 290; //target 30
case SKILL_CLOSE:
return 680; //target 50
case SKILL_HEAVY:
return 680; //target 50
case SKILL_ASSAULT:
return 680; //target 50
case SKILL_SNIPER:
return 680; //target 50
case SKILL_EXPLOSIVE:
return 680; //target 50
case SKILL_NUM_TYPES: /* This is health. */
return 2154; //target 100

USABLE STATISTICS
In an attempt to prevent people from suggesting unworkable alternatives, here is the struct of statistics that is used to calculate the XP values. If it isn't in here, it isn't counted. I took the liberty of removing a few lines for stuff that can't be used, for the sake of brevity.
Code: [Select]
/* Movement counts. */
int movedNormal;
int movedCrouched;

/** Kills & stuns @todo use existing code */
int kills[KILLED_NUM_TYPES]; /**< Count of kills (aliens, civilians, teammates) */
int stuns[KILLED_NUM_TYPES]; /**< Count of stuns(aliens, civilians, teammates) */

/**
* Hits/Misses @sa g_combat.c:G_UpdateHitScore. */
int fired[SKILL_NUM_TYPES]; /**< Count of fired "firemodes" (i.e. the count of how many times the soldeir started shooting) */
int firedTUs[SKILL_NUM_TYPES]; /**< Count of TUs used for the fired "firemodes". (direct hits only)*/
int hits[SKILL_NUM_TYPES][KILLED_NUM_TYPES]; /**< Count of hits (aliens, civilians or, teammates) per skill.
* It is a sub-count of "fired".
* It's planned to be increased by 1 for each series fo shots that dealt _some_ damage. */
int firedSplash[SKILL_NUM_TYPES]; /**< Count of fired splash "firemodes". */
int firedSplashTUs[SKILL_NUM_TYPES]; /**< Count of TUs used for the fired "firemodes" (splash damage only). */
int hitsSplash[SKILL_NUM_TYPES][KILLED_NUM_TYPES]; /**< Count of splash hits. */
int hitsSplashDamage[SKILL_NUM_TYPES][KILLED_NUM_TYPES]; /**< Count of dealt splash damage (aliens, civilians or, teammates).
* This is counted in overall damage (healthpoint).*/
int skillKills[SKILL_NUM_TYPES]; /**< Number of kills related to each skill. */

int heal; /**< How many hitpoints has this soldier received trough healing in battlescape. */

FORMULAS
Power: Currently fixed at 46. I didn't see a point in coming up with a formula as long as power is unused.
Speed: 1 point for every space moved. 2 points for every space moved while crouched. 1 point for every 10 TUs spent using weapons.
Accuracy: 20 points for every hit scored on an enemy. Only one hit can be scored per use of a weapon, except for splash weapons. 30 points for hits with sniper weapons.
Mind: 100 points for every enemy kill.
Close: 150 points for every hit on an enemy. One hit per weapon use, except splash.
Heavy: 200 points for every hit on an enemy. One hit per weapon use, except splash.
Assault: 100 points for every hit on an enemy. One hit per weapon use, except splash.
Sniper: 200 points for every hit on an enemy. One hit per weapon use, except splash.
Explosive: 200 points for every hit on an enemy. One hit per weapon use, except splash.
Health: The sum of all other experience gained (after caps), divided by two.

CALCULATION
After a mission, the XP counts are calculated as follows. The soldier then receives XP equal to to the earned value or the cap, whichever is smallest. Then the stats are updated as follows:
new value = start value + (total XP / 100) ^ 0.6
Where "start value" is the value the soldier had when he was recruited.

NOTES
- The system is not intended to force the player into action or into a specific strategy. The XP cap is there to prevent "training abuse", and the formulas are intended to allow any soldier who pulls his weight to reach the cap easily. In short, if the player plays normally, his soldiers should grow at an optimal rate. But soldiers sitting around in the dropship will not get free buffs.
- I will not get away from the XP system or the power of 0.6. I like the system, it's flexible and I think it's a good game mechanic. The power of 0.6 makes sure no veteran soldier will ever be surpassed by a newer soldier, even if the newer one had better initial stats, as long as the veteran keeps training.
- I will, however, adjust the formulas according to suggestions made in this thread, if I think it's an improvement. If I do not, no amount of arguing will convince me, so please don't keep hammering on the same idea.
- There is discussion about changing the actual set of abilities. I am aware of this, so please don't bring that into this discussion if possible. If such a change comes to pass, the relevant formulas will be added or removed.

Pages: [1] 2 3