what's the secret to making a good robot in robocode

From RoboWiki
Fragment of a discussion from User talk:Tmservo
Jump to: navigation, search

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Skilgannon (talk)14:35, 17 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

MN (talk)16:05, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Rednaxela (talk)18:13, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)20:12, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

MN (talk)20:31, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)20:36, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Sheldor (talk)21:22, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)21:30, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Rednaxela (talk)21:58, 18 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)01:55, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Rednaxela (talk)03:40, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)03:57, 19 December 2013
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)04:12, 19 December 2013
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Straw (talk)00:20, 20 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)00:34, 20 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Straw (talk)01:22, 20 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)01:34, 20 December 2013
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Rednaxela (talk)14:05, 20 December 2013
 
 
 
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)02:04, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Sheldor (talk)02:28, 19 December 2013
 
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Sheldor (talk)01:32, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)01:41, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Sheldor (talk)02:22, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)02:29, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Sheldor (talk)03:32, 19 December 2013
 
 

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

MN (talk)03:19, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

Voidious (talk)03:35, 19 December 2013

First thanks to all for the praise I've recieved on the thread =) I don't think I'm superhuman, but I know that I do approach problems from a different perspective than most people.

I don't think I've discussed much is about the process I go through when I make gains. These are typically from three things:

  1. Adding a new behaviour that has already been shown to improve performance, or creating a new behaviour that might improve performance and then testing it to death over lots of battles to see if it actually helped.
  2. Fixing bugs. Enough said.
  3. Speeding up code to make the skipped turn behaviour more predictable, and add spare CPU/memory capacity for future features

So absolutely, I agree with what JDev has said here: make it work, make it right, make it fast.

One other thing that I have to recommend is to not make ANY assumptions about enemy or bot behaviour. If you do make an assumption, do a bunch of tessts and check that the data supports your assumption. And once your feature is implemented, see if there is any way you can get rid of the assumption and thus take advantage of the cases where it isn't true.

MN (talk)15:02, 19 December 2013
 
 
 
 
 
 
 
 
 
 
 
 
Personal tools