Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
@pac, on Mar 11 2007, 02:14 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
Precisely. Processing power is not the limiting factor. Availability of skilled programmer man hours is. Thank you.
It is a limiting factor. I never said it was the only one, nor did I say it was the biggest one. Like I said, the AI was good relative to the processing power available back then, but since it hasn't changed much, whereas the developers in the world have increased AI abilities as processing capabilities increased. Therefore, we have a new benchmark for what AI should be. Yes, the developers have made big strides in the abilities of AI over the past 12-14 years, but they couldn't make those strides if the hardware hadn't changed. It's the exact same progress as graphics. It's not just the increase in the abilities and knowledge of graphic designers, it's also the increase in what they CAN do with more powerful hardware.
I would love to see some great developers take the time to make an AI in EV capable of taking advantage of the power of new machines. They could probably come up with opponents that used hybrid tactics, maybe even learning from the players fighting style instantly and adapting. Hey, maybe they'll surprise us with a new version for Nova's fifth birthday that's coming up in just over a week.
I don't think you understand the meaning of the term "limiting factor".
Say you're baking a cake. Cakes require flour, eggs, and sugar in our simplified world. Each cake requires 2 cups of flour, a half-cup of sugar, and one egg. If you happen to have on-hand 20 cups of flour, 8 cups of sugar, and 4 eggs, then you can only make 4 cakes. You have enough flour and sugar to make more cakes, but not enough eggs. Thus, eggs are your limiting factor. Certainly flour and sugar are required to make cakes, but as a lack of eggs is the current thing preventing you from making cakes, they are the only limiting factor. There can be only one limiting factor at a time (barring some edge cases where you have equal relative quantities of ingredients).
In terms of AI, what Pac is saying is that for the EV series, processing power is not and has never been the limiting factor; rather, the time and expertise of the one developer has been. If making the AI 1 arbitrary unit more intelligent requires 1 week of development time from Matt Burch and a 5% faster computer, and Matt Burch only has 1 month of time to spend on the AI, then we're going to run out of Matt Burch before we get a program that uses all of our processing power. This is why processing power is not a limiting factor on AI in EV. In the case of Deep Blue, the developers had years of highly-skilled Matt Burch available, so they were able to push the program to the limits of the hardware. In that case, processing power was the limiting factor, not development time.
Did my analogies make sense?
Quote
Yes.
And I'll have my Matt Burch scrambled with bacon please.
@derakon, on Mar 11 2007, 03:53 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
You can very easily have multiple limiting factors. If you have 20 cups of flour, but only 2 cups of sugar and 4 eggs, then you have two limiting factors: eggs and sugar. Hell, let's say you also only have four pans, so that is also a limiting factor.
It's not that I don't know the meaning of limiting factor, it's that I have a different perception. Here's an example.
Let's say you're on a plane (in the geometric sense, not the flying sense). You can move any direction you want. Then you put up four walls to make a rectangular box (say 2 units on the x and 4 on the y).
(Your box would look roughly like this:) _ _ | | | . | | | |_ _|
EDIT: The box does not appear correctly when the post is submitted.
Now, if you perceive X and Y movement separately, then you have two limits (1 unit from center in one direction and 2 from center in the other). However, if you perceive it as movement in general, like you do, you only have one (an absolute max of ?5 units from center diagonally). I personally perceive the limit(s) as both existing independently and existing singly (you have both 2 limits and one limit simultaneously--note that for simplicity's sake in this example, I am ignoring other limits, say Z, time, etc.). Ignoring that it is both two and one is adhering to only one of those perceptions, and is like saying the glass is either half-empty or half-full, while discounting the fact that it is both simultaneuously.
Then, let's say you are actually in a cart that only goes forwards and backwards (on the y). Now, you have eliminated your walls that run parallel the y as a limiting factor (1 unit from center on the x axis), but you have replaced them with the limiting factor of going 0 from center along the x (which also eliminated ?5 as a limit), while still retaining your walls at a distance of 2y. Now, those walls don't need length, but for demonstrative purposes, I will include them (remember, you can't move on the x):
_ _
.
In addition to 0, you still have your limit of 2 from center, as well. You could possibly argue that you only have one limit, that is 2 along the y, but that would be ignoring the 0 (something done all too much in life, including math).
Since I perceive the situation as both having one and multiple limits, I think of the processing power as a limiting factor. (One could put it as a potential limiting factor, if you'd like). To demonstrate, let's move back to the plane. You may only be able move 1 unit/sec and only have 1 second to move. Then, you can only move 1 unit in any given direction from center, despite the fact that your space goes on forever. However, since processors aren't infinite, it's like being in a box, in which case you still have the existing (though not reached) limits of your four walls, not to mention that time and speed are individual limits when covering a distance. If you change your rate (in the case of developing, maybe that entails adding another worker, or perhaps improving your own skill), change the amount of time, or increase the size of the box, then you create new limits (again, if you'd like, you can call them potential limits, I'll still think of them as limits). The point is, as long as you are within a box, you are still in a box.
Are my analogies clear?
This post has been edited by erikthered : 11 March 2007 - 08:42 PM
I had a little trouble with your analogies, I have to admit. But what you were saying about the recipes falls under the caveat I had inserted into my post (specifically because I suspected you'd bring this up):
"Derakon" said:
There can be only one limiting factor at a time (barring some edge cases where you have equal relative quantities of ingredients).
What is meant by that is precisely the situation you outlined where you have 2 cups of sugar and 4 eggs. In that situation, the quantities of sugar and eggs are relatively equal (that is, for purposes of making cakes, each allows for four cakes to be made).
The point of a limiting factor is that it is the factor that you are going to run out of first. It doesn't matter how much of the other factors you could have; without the limiting factor, you can do nothing. If I have 2 million cups of flour, it doesn't help me make cakes one bit, because I still have only four eggs.
You are using the term "limiting factor" to refer to factors of all kinds, which is at best misleading and at worst disingenuous. I'm not trying to imply any malice on your part, but you are using terms sloppily.
@derakon, on Mar 11 2007, 08:57 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
I had a little trouble with your analogies, I have to admit. But what you were saying about the recipes falls under the caveat I had inserted into my post (specifically because I suspected you'd bring this up): What is meant by that is precisely the situation you outlined where you have 2 cups of sugar and 4 eggs. In that situation, the quantities of sugar and eggs are relatively equal (that is, for purposes of making cakes, each allows for four cakes to be made).
Yes, I realize my first example fell under your exception.
My example is perfectly logical, though it may be complex.
No, there is nothing wrong with my use of the word "limiting factor." I always try to be careful and deliberate in my choice of words. The whole point of my post was that you can have multiple limiting factors, while simultaneously perceiving it as one. For instance you say, "Developers not having enough time is the limiting factor," whereas I say, "The speed at which a developer works and the time in which developers have, as well as the tools available are limiting factors," because if you change any of those variables, it will have an effect on what you can do. Hell, if you drop the tools part, by your logic, you're still left with the question, "Which do you encounter first: the speed at which the developers work or the time the developers have?" Sure, you could do what you said and lump it all together into "Developers don't have enough time," but then you are failing to look at the fact that that can be both a single factor and multiple factors.
So, discounting tools (processing power), I ask you, is the 'limiting factor' time or speed?
Remember, by your definition, you can only have one limiting factor, so you can only choose one.
This post has been edited by erikthered : 11 March 2007 - 10:00 PM
Wow, we're getting off-topic.
Anyway, to go back to the cooking example, I'm presupposing that the 4 eggs are all the eggs I can get, whereas it sounds to me like you're suggesting that eggs are a product of chickens combined with corn; thus, why aren't my limiting factors taking into account the chickens and corn factors? If this isn't what you're saying, then feel free to correct me. If it is, though, the problem I have with that argument is that it doesn't actually change things; at that point, my limiting factor for cakes is still the eggs I have right now, not the eggs that I could potentially have in the future. The assumption is that the time it takes to make a cake is significantly less than the time it takes chickens combined with corn to make eggs, and thus, the potential eggs from the chickens aren't worth considering.
Even if they were worth considering - say it takes me 2 hours to make a cake, and 4 hours for a chicken to make an egg (that I can then use immediately) - then, based on our cake recipe (2 cups flour + .5 cups sugar + 1 egg), after I've made 2 cakes, I now have a fifth egg, so now I can make five cakes total. Then I make two more, and I now have 6 eggs; two more, and another, then one more, and now I've made seven cakes, there's a half-completed egg in the chicken, and I'm out of eggs right now, while still having some sugar (4.5 cups) and flour (6 cups) left. What I need is eggs, and there aren't any more; thus, my limiting factor is eggs.
Having the developer's productivity be a factor of his working speed and how much time he has is a different matter; you don't "use up" working speed as you get work done; working speed is just a matter of who you are and how you work. It's not a consumable commodity; thus, it's not a limiting factor. Now, developer productivity could be a factor of available time and pizza, since both are necessary to get work done. But again you aren't really changing anything at the "what does it take to get good AI done" level. You consume the time and the pizza to generate productivity, which then gets channeled into making AI. Once you're out of time or pizza, you're also out of productivity (say you ran out of time, because there's a $PIZZA_PARLOR right around the corner), and thus out of AI improvements. This is probably going to happen before you run out of CPU; thus, processing power is not a limiting factor, while developer productivity is (because development time was a limiting factor on developer productivity).
For what it's worth, this is the definition I'm using for "limiting factor": http://en.wikipedia....imiting_reagent
@derakon, on Mar 12 2007, 12:59 AM, said in Should Fighters Be Able to Kill Capitol Ships?:
Yeah. AI was a COOL off topic, but now you ladies are talking about baking cakes!
I'll leave the cake baking to you, I just want to eat the result if you happen to be good at it.
@pac, on Mar 11 2007, 09:48 AM, said in Should Fighters Be Able to Kill Capitol Ships?:
My question was, 'what game ever got great sales based on having a highly sophisticated AI which could compete with the player?' And your example is Warcraft …? I don't remember there being anything especially smart about it. Basic, but certainly unable to compete with the player without massive superiority in resources. RTS AIs can occasionally seem good because they're better at the micromanagement - ie, they react faster when their peasants have nothing to do, etc, but I've never seen one do anything clever. Certainly not a key selling point.
Haha. This sorta reminds me of this one multiplayer game I played where all I did was build towers and siege engines. When the other player finally came to attack my base they ran into a wall of fire and their army had to retreat and bring up catapults to deal with all my towers. So then I break out of the trees on the other side of my base and I send all of my 30-40 siege engines at the other guy's base, destroying it all without the having to fight his army.
That's kind of a long example, but I've never really seen the AI deal well with a tower wall, or invent tactics like siege engine rushes. The AI is not so good in Warcraft III, and it pretty much does the same thing every time unless you script it yourself.
Anyway, the rest of the topic has gotten me hungry, hehe.
@derakon, on Mar 11 2007, 11:59 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
This is the first you have mentioned of chemical "limiting reagents." That means two things: a) You used the term "limiting factor" assuming that everyone would equate it to "limiting reagent;" This discussion is not about chemistry, therefore there is no need to discuss reagents. Yes, in a chemical reaction, there does exist the distinct possibility of a single limiting reagent. However, then you may also need take into consideration of other conditions, such as temperature, pressure, etc. Either way, your example is much more appropriate for chemical reactions than it is for work productivity. Even in your "Pizza+time=AI" example, you are looking at it as chemistry. I was using the term factor to mean "one of the elements contributing to a particular result or situation" (the first definition for factor from dictionary.com), not necessarily as a material to be used up.
Now, as you pointed out, people don't use up speed, and I never said that anyone did. What I did say is that the speed at which a you can work, and the time you have do so, as well as the materials needed to do the work are the limits. That's why my example works well. It takes into account what your maximum boundaries are (the box; aka, the processor), the rate at which you can work (speed; perhaps how many lines of code per hour, which may be affected by the number of developers), and the time limit in which you can work (um, aka, the time in which you can work). The key is not to look at worker productivity in the sense of a "this much A + this much B = this much AB and some leftover A" chemical reaction. It's more than just putting materials together and coming out with a new product. You could possibly look at it in kind of a chemistry way like this:
You have 10 units of A, and 20 units of B. When A and B combine, you get AB. They combine at a 1:1 ratio, therefore, for every unit of A and every unit of B, you get one AB. This is were your example stops: with us having 10 AB and 10 leftover B. That may wind up being our end product, but what about how quickly the reaction between A and B occurs, or the time we have to allow the reaction to occur, or the limitations of what we can fit into the space we're given? Those are the factors I am talking about. Let's say that they combine at 2 units/minute at 70ÅŸ (rate/speed), but they combine at 5 units/minute at 80ÅŸ and 10 units/minute at 90ÅŸ (increased rate/speed). So, if we throw our 10A and 20B in at 70ÅŸ, it will take 5 minutes to get our 10AB and 10B. Also, it takes 1 box of space to store 50AB.
Here's the important part: We have to keep in mind our goal production.
Let's say we want 150AB. (To make the analogy, that's the AI we want; 75AB--the old AI--just won't cut it anymore.) Well, we need to make sure than we have enough material. We have 200A and 250B, so we're set with the material limits. We even know that if we put it all together we'll end up with 50 extra AB and 50 leftover B. (I'm not sure how to equate those individual materials to AI, but really they only serve as the connection from your example to mine.) Next, we know that the person we are shipping this AB to has 6 boxes of space (processing power). Thankfully, we are only sending enough to fill up three, so that's not a worry. It might be a factor in the future if your customer asks for 500AB, but right now, he's not. But there's a catch: we have to have the 150 AB in 15 minutes, otherwise we lose funding. (The game has to be done by a certain day, otherwise you're fired and the game doesn't get published.) Now, if time wasn't a limiting factor, we can sit around for however long and wait for A and B to combine, but it is a factor. Also, since 200A and 250B doesn't make 200AB (our goal is only 150AB) instantly, the rate is another factor we must account for. Furthermore, your boss will only pay for one heater, which can only get the room up to 80ÅŸ. (The heater is analogous to an extra programmer. Without the heater, it would be 70ÅŸ, perhaps the same as having one programmer. You would like to have another heater to get the room to 90ÅŸ because you know that the rate is double that at 80ÅŸ, but your boss can only afford one; that is, with more programmers, you can work faster.)
So, can it be done?
150AB÷5AB/min=30min. Drat. You're fired. You just can't get it done. The time limit combined with the limit of production means you can't meet the goal. However, after 15 minutes, you would be able to produce 75AB, which is your old amount. (15min•5AB/min=75AB) If only you could change at least one of your limiting factors to get it done. You explain to your boss that you need fifteen more minutes. He says he'll give you 5. (20min•5AB/min=100) You tell him that you still can't get it done with all of those limits, though it would produce more than the old amount. If you could get another heater, it would be great. So he gets you another heater, and at a scorching 90ş, you get him 150AB in 15 minutes (150AB÷10AB/min=15min), just in at your original time, even. Now, you're boss only changed one limit at a time, (first the time, then the heaters) but he could have changed more than that at once.
Now, say you're working alone, and you boss tells you that some new investor wants to know how much AB you can produce. You tell him that there are a lot of variables involved, including the amount of A and B, the number of heaters you can use, how much time you have. You also tell him that it doesn't really matter how much you can make if the customer can't store it. You arbitrarily pick some limits, but not one of each: 1 heater, 10 minutes=50AB. You then tell him that you could make 70AB in 35 minutes without any heaters. You also tell him that if you had 2 heaters, and 40 minutes, you could make 400AB, even though a lot of customers couldn't store that much. Basically, it all depends on what situation your different variables combine to leave you with.
That took way too long to type. It's too late to argue anymore logic.
EDIT: Hey, it turned my b next to ) into a smiley.
This post has been edited by erikthered : 12 March 2007 - 02:16 AM
Hey, if I'd known you had experience with chemistry, I wouldn't have been mucking about with cakes all this time.
So what you're talking about there is rates of reaction. Effectively your AB analogy (bloody AI?) has AB being a product of programmer time and storage space, in addition to A and B themselves, while the temperature affects the rate of reaction. Correct me if I'm wrong, but you're saying that you could have a deficiency in one ingredient (e.g. programmer time) that can be made up for by modifying the environment the "reaction" takes place in (by adding heaters). Effectively you've reduced the amount of one ingredient required by increasing the efficacy of each unit of that ingredient. I certainly agree that that's the case, but I'm not convinced that it makes the heaters a factor in the sense I've been using. My assumption had always been that the reaction takes place in some fixed environment.
In the case of Matt Burch coding AI improvements, then, my assumptions were that his time to create the overall game was fixed, his speed of programming for each feature was some constant (e.g. 1 feature per day for outfits, .5 features per day for AI), and that his choices largely involved optimizing what elements get to be in the game, given his time constraints. Now you're saying that he should have just gone out and purchased five space heaters (and, um, hooked them up to his neighbor's power grid) and coded them all, to take your example to an illogical extreme, and the fact that he did not do this makes heat a limiting factor?
In any event, I still don't see how Matt could have possibly come up with a playable AI that pushed the limits of contemporary processors given what his constraints were.
I think part of our problem here is that we've been using time as an ingredient, when it's not generally thought of that way. Ahh, well.
I feel like jumping in to make a comment. The time it takes to produce something varies based on what you are producing. Lemme use my CTC development as an example. With rough guesstimates, it takes me roughly 15 minutes to create a new outfit and test it, 30 minutes to create a new weapon and test it, and 60 minutes to create a new ship and test at the same level of productivity that I am certain will remain consistent. If I double my productivity, my times will decrease very little due to other constraints. I cannot, for example, change the speed at which Mission Computer loads resources, or how fast I can test something, given I am already setting it up in a test enviroment within the TC. I still have to fly the ship, check its speed, handling, how much it gets knocked around by weapons, test its space, etc. These all take a certain amount of time, and I cannot reduce that amount of time it takes without eschewing some of my testing.
So, in my case, increasing productivity will only increase the amount of time I spend on something, since I cannot produce faster. I have no deadlines, so my average productivity for the TC since I've started has been rather low (given I don't have tons of time to devote to it). However, developers have time constraints and also other things they have to do. Assume they have 40 hours a week to work on it. During those 40 hours that it all they do. You cannot increase productivity because they are already entirely devoted to it during that time, no matter how many heaters you buy. During the other time, they have to deal with the rest of their life as well as take a rest. You could up their productivity to, say, 70 hours a week, but they'll be so tired it'll either be of low quality or they'll be burnt out the next week and get little done, if anything, so you really loose time.
So say three months development time. Theres an average of three weeks in a month, so that'll be 360 hours they have to devote to it at their highest level of productivity, assuming there are no problems along the way, such as a computer crashing and wiping all of their work. So, at best without lowering producitivty or overworking them, both of which leads to inefficiency, you'll get 360 hours worth of A.I, which includes making it, testing it, tweaking it, testing it, tweaking it, testing it, tweaking it, testing it, etc. Tweaking also assumes attempting to fix bugs, suggesting that there are no hard to find bugs. If that is the case, you have to factor in the time it takes to find the hard to find bugs and hard to fix bugs into your 360 hours. Remove testing time as well. Just throwing out a guess out there, after fixing bugs and testing it, you really only have about, say, 120 hours worth of A.I. developed, less if you underwork the developers due to...a lack of work and less if you overwork them, due to the problems and bugs that'll arise from sloppy coding while tired or worrying about the other things in life they should be doing instead of working on a game A.I.
Developers aren't machines, you can't just install a bunch of heaters and expect productivity to rise or increase the time they spend on it and expect better results. Time is a very scarce resource, deadline or not. If it wasn't, CTC 1.2 would be out, because if I had all the free time I've needed since I started, I would have finished the plug at the end of last summer. And if you're on a deadline, whether completely stated or implied, you can only do so much. And yes, a deadline can be implied. If you announce you're working on a game, especially a major corporation, it'll be generally expected to eb done within a year or two worth a time. There aren't many I can think of that took longer than that and there are a number that dumped content to meet a deadline, stated or implied.
Ok, that turned out to be longer than a comment.
Hmm. So much confusion over a simple question of definition.
Yes, there can only be one limiting factor at any given time. However, over the lifetime of a process (eg, EV AI development), there could be a series of different limiting factors. To use the tired cake analogy again, if you get a new supply of eggs in, something else - flour - will become the limiting factor. Maybe later you'll run short of eggs again, and that will again be the limiting factor. Whatever, there'll only be one at a time. Of course, there may be one limiting factor on rate of production (eg, how much space there is in the oven), and one limiting factor on total production (eg, quantities of ingredients).
However, whatever the series of limiting factors for EV AI development may have been, I can assure you (and this is only an opinion, but it is as close to an authoritative one as you're going to get short of the man himself popping up) that processing power has not been one of them. EV was not close to pushing that limit when it was originally designed, and never has been close to it since. Thus the - entirely accurate - point that computational power on the average machine has increased since the development of the original EV is irrelevant.
Now, if I dare take a step back towards the topic - well, at this point it's not actually the original topic, but it's a little closer to it - of AI, one additional problem with AI in a game like EV is that its objectives are complex. In chess, the goal of the AI is simple: to checkmate the opponent. (Nonetheless, plenty of complexity emerges out of that simple objective.) But in EV, a ship's goal is not, generally, to defeat the player. Should an AI treat the player differently from any other ship? Perhaps some kind of assassin AI should have the particular goal of killing the player, but most warships, for instance, should surely treat the player in the same way as any other enemy (when he's an enemy). A trading vessel under attack by the player would need to behave quite differently. What are the goals of fighters? To protect the mothership, attack their target, keep themselves intact? (Or to engage other fighters? Intercept missiles? Just reading through this thread would give us lots of possibilities.) It would be a long time before we ran out of ideas for the number of different goals we wanted ships to be able to pursue.
So already, with only an extremely superficial analysis, we have multiplied the task of the AI developer. We need not one (as in chess, albeit highly complex) AI, but many different ones. Let's say that within the development time available, a programmer could make one of these AIs really good (and barely sketch the others in), or all of them adequate. Knowledge of the constraints on the system lead me back to conclude that we have a remarkably good system, with a range of AIs for different purposes which do what they need to be able to do.
The shortcomings of the AI can be broadly compensated for by imaginative use of resources in other areas. For example, a poster commented (it may have been here, or in another thread) that skilful piloting boiled down to having the patience to run away and recharge enough times to wear down the opposition. There are a number of ways of addressing this: limiting player access to ships with the ability to outrun all enemies and drastically reducing (or removing) shield/armour regeneration rates to name but two.
To the content designer, the AI will always seem to be lacking. I have found that the best approach is to treat it as a source of opportunities and options with respect to design, rather than a source of obstacles and limitations.
This post has been edited by pac : 12 March 2007 - 12:51 PM
@derakon, on Mar 12 2007, 10:00 AM, said in Should Fighters Be Able to Kill Capitol Ships?:
Like I said, A and B are only a means to tie what you said (a certain amount of individual ingredients combining and running out of one) to what I was saying (the entire process). I could have easily done the example without A or B and said you were making Widgets, and "here's how quickly you can do it," etc. The heaters were merely a metaphor for something (whether it be more people, better skills, whatever) that would increase how quickly you can get things done. I never said that developers are machines that churn out programs constantly and that there is a simple solution to increasing work rate. All I was saying was that in my example, I used heaters as a means to adjust the workrate. Since the original discussion had to do with not being able to do much in a certain amount of time, you have to know the rate at which you are working and your timeframe, both of which are (possibly variable) limits.
All of you guys are still looking at is as running out of pieces and parts. But you don't run out of 1s and 0s. Your limits are not the pieces going into it, they are the limits of the process as a whole; you run out of time, you max out your work rate. Please, stop looking at it like a chemical equation that needs to be balanced and start looking at it from an economic production point of view. As long as you keep insisting that we will run out of something first, you will only see it as one limiting factor. I thought you guys might get that from my examples, particularly the second. No, there isn't a table that says this number of developers magically means you get your program done faster, but you might increase productivity (which, by the way is a rate--the amount of work you do in a given time) with more programmers, or better programmers, or faster computers that load Mission Computer more quickly, or more beta testers so you don't have to worry about trying to hunt down every bug yourself.
This post has been edited by erikthered : 12 March 2007 - 02:35 PM
I've worked on creating AI before (technically, they were expert systems, but then, technically, what we're talking about is an expert system as well). Let me just say that it is a hugely complex process.
Imagine this. Put how you play EVN into a series of IF/THEN/ELSE and LOOP statements. (For those of use who don't program, an IF/THEN/ELSE statement says "Is the supplied statement true? If it is then do one thing. Otherwise do something else." and a LOOP statement says "Do this. Then do it again. And again. And again..." though usually there is some way to stop doing it within the LOOP statement.) So, I'd go: Is there a ship that either wants to kill me or that I want to kill? If there is, then start combat, otherwise keep doing what I was doing. Pretty simple so far, and if I enter combat it might go: If I don't want to kill the ship attacking me, then flee. If I want to kill the ship attacking me, then attack it. That also seems pretty simple. But how do I attack the ship, if I attack it? Do I charge head on? To I stand off and fire missiles and long range guns? Do I go at an angle and do a flyby? A quick look at JoshTigerheart's guide to close combat can give you a whole list of ideas. And what if you want to combine more than one? Tell me exactly when you'd switch, but you can only do so by deciding whether a logical statement is true or false. Fleeing is almost as complex.
But wait! There's more! Now I'm not alone but with allies. What happens now? And remember, you can only tell me what to do based on logic statements.
I spent about three months, working forty hour weeks trying to get a computer to decide whether or not a picture was of a glass sphere or the surrounding substrate, and while this data is perfect (i.e. has no noise), it's also a much more complex and chaotic task.
Of course, that's just programming. We're not even going to get into deciding tactics and strategy to implement via the programming. To start with you'd need to decide whether the computer acts as homo sapiens or homo economicus. But after that, you'd need to make a comprehensive tactical manual. Just think for a second about how hard making a comprehensive tactical manual is. The US Army's is over three inches thick, and they still depend a lot on human initiative.
Either way. I just wanted to thank everyone for contributing to this topic. Cheers!
@erikthered, on Mar 12 2007, 08:19 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
All of you guys are still looking at is as running out of pieces and parts. But you don't run out of 1s and 0s. Your limits are not the pieces going into it, they are the limits of the process as a whole; you run out of time, you max out your work rate. Please, stop looking at it like a chemical equation that needs to be balanced and start looking at it from an economic production point of view. As long as you keep insisting that we will run out of something first, you will only see it as one limiting factor.
As we've been persistently trying to explain, there can only be one limiting factor. That is not due to some imaginative or conceptual failure on our part, but the definition of the term. (If you have another definition of the term, please feel free to provide a link to something supporting it.) I am looking at the question in terms of economic production - I have no problem with a model in which production is restricted by a series of bottle-necks, restrictions which can only be lifted by tackling that specific problem, and not other unrelated ones. You can improve the productivity of your work force as much as you please: if you run out of wheels, you won't be making any more cars. I'd like to discuss the subject as a whole further, but it's difficult when there is such a divergence on what should be a simple matter of terminology (it's the limiting factor on the discussion, if you like ;)).
To say that, because the average machine today has more computing power than its equivalent did 12 years ago, EV today should have better AI, is like saying that, because Hollywood special effects budgets have risen over the last 12 years, art-house movies should have better special effects. It simply doesn't follow. The two trends are not related to one another.
@pac, on Mar 12 2007, 05:36 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
To rebut, I was saying that people that were expecting a big jump in the AI from EV to Nova will be disappointed. EV didn't keep up with advances of other gaming AI.
As far as limiting factor... Here, here, and here. While the first definition at dictionary.com uses the article 'the,' the others use the articles 'a' and 'an.' Even the military definition says, 'a' not 'the' implying the possibility of the existence of more than one. Now, I'm not using the term in a strictly ecological sense, but you can read in one of my other posts my definitions for the word 'factor.'
I knew someone would bring this up again anyway, so here's another simple example. You're running an experiment to find out what fertilizer works best. So you have to set limits, also known as controls. You have to make sure, in order to assess data, that you apply limits such as the amount of water, type of plant, amount of sunlight, temperature of the room, humidity, and anything else you can control to make sure the experiment is accurate. All of those factors (as in an element of something) that limit exist simultaneously.
Now, with that said, I never said that the logic (in the computer sense) had to have more than one choice. I certainly understand that that is a series of yes or no questions, each needing to be determined before proceeding. What I said was that the process of creating code for AI is a process that has a number of limits. However, you still insist on looking at only one factor of a process, how much stuff you have, instead of the process as a whole.
This post has been edited by erikthered : 12 March 2007 - 07:31 PM
I like cake.
@flavius, on Mar 12 2007, 03:56 PM, said in Should Fighters Be Able to Kill Capitol Ships?:
<snip>
Pretty much what I wanted to say, which I couldn't given my A.I. programming experience is limited to a failure to make a computer play Tic-Tac-Toe in high school Computer Science using Turbo Pascal.
Meh, I got some other things I could say. I just don't know if it'd be worth the time. That and I don't feel trying to make graphs.
Flavius: To answer one of the questions (because I love shooting ideas around for no particular reason), EV already has several AIs. There's no reason to make an AI which tries to figure out what to do based on the ship itself because the developer can just select the AI he wants in the ship resource. If you're making a comprehensive AI you will probably also let the developer edit it to some extent or other to help deal with unforeseen consequences of different weapon sets. Also, not trying to let any one AI use multiple attack patterns in a logical manner would probably help and cut down a lot of time too. No need to get so ambitious as to implement all of Josh's points at once in everything, and setting limits like these, though not making the problem easy as pie, make it easier than impossible.
But you already know that, since you've done AI stuff yourself.
I wish we had a game where you could program the little EV ships to fly around. We could have little bot tournaments and stuff. Imagine being about to outfit your ship like in EV, but with AI programming!
sigh
All the AI games nowadays are dead or dead boring. >_<
This post has been edited by Phyvo : 24 March 2007 - 10:36 AM