vamos, un juego de programar ai d toa la vida.
Anda k compartir código... hay k ser catetorr xD
Me habeis metido todo el Hype cabrones xDDD, en cuanto salga de trabajar lo pillo, tiene algun sistema de grupos, clan,guild,amigos?
Lo podeis probar gratis registrandoos en la web, lo unico que no teneis CPU y solo funcionara vuestra zona cuando tengais el navegador encendido.
#56 Puedes asignarle a un creep un atributo nuevo, creado por ti?
En ese caso, se me ocurre que tendrías que hacer que los creeps de la cadena humana que mueven recursos estén haciendo una especie de polling, es decir, que cada ciclo busquen si hay un constructor a tope de energía ( _.filter(Game.Creeps)? ). Añades a los recolectores un atributo que sea "transporter" y que sea una id o una referencia al creep que va a ir a buscar su energía. Así, ahora los creeps de la cadena humana tienen que buscar un creep lleno de energía , y sin transporter (sólo el primero, que se registrará como su transporter, para que no vayan 5 a por un recolector). En ese caso, deberán moverse hacia el creep que está minando, pillar su energía y volver. En el momento en el que pillen la energía del creep que está minando, le asignas transporter = null, de manera que cuando vuelva a estar a full de energía otro creep de la cadena humana podrá ir a por él.
Y luego optimizar a gusto del consumidor: que vaya a buscarlo el creep más cercano, calcular los ticks que le quedan para estar full, de forma que cuando esté lleno haya un transporter esperándolo, etc.
No he jugado aún, eh? Solo estoy pensando en alto (o por escrito).
tengo sentimientos encontrados. La idea es curiosa, pero siento como que saldría d etrabajar, y me pondría a currar mas.
Algo así me pasaba con el Papers, please
#61 En GitHub hay mucho código compartido, pero por lo que he podido ver, la peña que tiene un buen imperio no compacódigo (normal).
#62 Implicitamente no, pero todo se puede programar. Cada unidad, elemento u objeto del juego tiene una zona de memoria que puede ser explotada a tu antojo. Por ejemplo si miras mis ejemplos de #1, verás que establezco un valor en creep.memory.role = 'builder'. Esa propiedad role me la he inventado, y luego la utilizo para diferenciar el rol (o trabajo) que desempeñará mi creep. Para crear un clan podríamos utilizar lo mismo, pero asignando un valor clan=mediavida y en nuestro script buscar creeps enemigos con el valor mediavida y no atacarlos, o tradear energia con ellos 
Joder el juego tiene pintaza, yo soy muy noob en programación, solo sé lo básico (variables, if/else, cuentas...) pero me ha entrado hype y voy a darle un try a ver si así de paso voy aprendiendo cositas mas avanzadas
Gran juego para que los programadores puedan seguir programando cuando salen del curro. Una bonita forma de vivir en el mundo de Java antes, durante y despues del trabajo.
#67 creep.memory.guild=mv, por ejemplo? De todas maneras, ¿qué cantidad de creeps se espera tener? Porque según he leído en Memory estamos limitados a 2MB de memoria en total.
#72 La gestión de memoria también es un punto a tener en cuenta. Arriba tienes un contador para saber cuanta memoria estás utilizando. Para una colonia GRANDE, 2MB son suficientes. Yo actualmente la utilizo para designar roles (tipos de creeps) y healers (médicos).
La idea de los medicos sería crear un creep de ataque y un creep healer. Asigar el rol correspondiente a cada creep. Luego asignar el ID único del creep de ataque a la memoria del healer, para luego programar una función que situe el healer 2 posiciones por detrás del atacante y compruebe sus puntos de vida. Si la vida decrece entonces el healer se aproximará y lo curará. De ésta forma podemos tener un ejercito de creeps atacantes con sus respectivos healers, algo similar al Medic+Heavy del TF2.
Ésto se me acabo de ocurrir mientras escribía, ahora tocará programarlo xD
#73 interesante idea, aunque creo que me mola más el símil Marine + Medic de SC 
.
Si no hay muchas restricciones, tiene pinta de que podemos hacer cosas bastante guapas en el juego, qué ganas de dejar el puto JS del curro y ponerme con el puto JS del juego, juajuajua. A ver cómo chutan los creeps estos con programación funcional
#1 Me puedes explicar en que influye la cantidad de CPUs?
Tus colonias trabajan mas rapido porque pueden ejecutar mas lineas de codigo o que?
#75 http://support.screeps.com/hc/en-us/articles/204332302-How-does-CPU-limit-work
Básicamente, CPU time = tiempo máximo que pueden tardar tus scripts en ejecutarse por cada tick. Si durante varios ticks tus scripts terminan antes del límite, puedes ir acumulando tiempo de CPU no utilizado, hasta 10.000 CPU. En sucesivos ticks, si tus scripts tardan más del límite, pueden ir tirando de ese valor acumulado hasta adicionalmente 500 CPU por tick (es decir, si acumulas 10k CPU, podrías tener 20 ciclos que consuman +500CPU).
Lo que no me queda del todo claro es el modelo de pago, si es un pay2win. Es decir, si la cuota mensual es para que todo el mundo tenga 10CPU, o si hay gente que puede desembolsar pasta par a tener 20,30,50CPU, en cuyo caso no me plantearía jugar (o pagar por jugar).
#75 No. El juego no es un pay2win. La velocidad del juego online va por tiks. Un tick es un ciclo de cálculo del servidor, su duración será igual al tiempo empleado en procesar todos los scripts de todos los jugadores a la vez. Actualmente el tiempo de un tik está en 2.5 segundos.
En cada tik, el servidor ejecutará tu código JS. Dependiendo de la cantidad de instrucciones que ejecutes en cada tik, se asignará un valor de "coste" de CPU. Por ejemplo la función creeps.attack(); tiene un coste de 0.2 CPU. La suma de los costes de CPU de todas tus instrucciones no deberá superar el número total de CPU contratado. Si lees la wiki oficial sobre la CPU hablan de un bucket donde se almacenan las CPU contratadas por todos los usuarios pero que no han sido usadas, para que el resto d eusuarios se beneficiend de esas CPU sin usar (creo que se refiere a eso).
En resumen, tu colonia no trabaja más rapido por tener más CPU. Lo único que conseguirás es poder ejecutar más instrucciones a la vez en cada tik. La compra por Steam te otorga 10 CPU siempre, tamaño suficiente para una colonia media/grande.
#76 Ojo, una cosa es el CPU time y otra el número de CPU. El CPU time es lo que comentas, la ejecución de tu código no podrá superar los 100ms. A medida que adquieres nivel en el juego, esa limitación sube de forma gratuita.
Luego tienes el número de CPU (lo he expicado arriba) que limita la cantidad de instrucciones por tik, independientemente de que todas ellas se ejecuten en 1ms.
No os precupéis por la CPU, los tik y la memoria. De forma inicial tienen unos limites muy altos como para que os impacte durante los primeros meses de juego.
#77 No he dicho nada, estoy releyendo tu mensaje con lo que has editado, que creo que como comentas, estoy hablando de un concepto distinto.
Joder...mira que me tenia que poner las pilas con Java este verano y no empezar a picotear en otros lenguajes...pero esto es superior a mi, JavaScript ale voy¡¡
#80 Bienvenido al peligroso y divertido mundo hipster de JS (ya estás en él si picas Ruby/Python/etc). Haz lo que puedas imaginar y programar, pero hazlo bajo tu responsabilidad .
Joder, me han dado unas ganas de jugar terribles. Sois lo puto peor de esta galaxia. Aunque me vendrá bien para aprender más de javascript y dejar de odiarlo tanto.
#77 Supongo que el juego te dice cuanto consume cada script tuyo?
Y que si optimizas el codigo consume menos CPU por lo que podras tener mas funciones?
#83 Si, puedes llamar a Game.CPU y dentro tienes varias propiedades y metodos para controlar tu gasto. De todas formas no te preocupes en optimizar. Para jugar en el simulador no hay limite de CPU, y online por steam tendrás 10 CPU (dan para una colonia grande).
Estoy intentando programar el rol de creeps atacantes con un medic/healer detrás. Por el momento no me sale nada xD
#74 ayy lmao, os dejo mi primer contacto con el sistema de ataque xD:
He puesto el comando say para ver si mis creeps estaban ejecutando la zona de código correcta. El creep de color rojo es del tipo ataque, con el siguiente código:
var target = creep.pos.findClosestByRange(FIND_HOSTILE_CREEPS);
if(target) {
creep.say('atacando');
if(creep.attack(target) == ERR_NOT_IN_RANGE) {
creep.moveTo(target);
}
}El creep con el punto verde es un medic (muy básico, solo tiene una parte de heal y es poco efectivo). Además no he programado que siga al creep de ataque, simplemente espera a que algún creep esté herido para curarle:
var target = creep.pos.findClosestByRange(FIND_MY_CREEPS, {
filter: function(object) {
return object.hits < object.hitsMax;
}
});
if(target) {
creep.say('curando');
if(creep.heal(target) == ERR_NOT_IN_RANGE) {
creep.moveTo(target);
}
}El resultado ya lo habéis visto xD. Debería haber creado un creep de ataque más fuerte y un healer más listo y efectivo. No he durado ni 2 hostias xddddd. No me negaréis que éste juego es la repanocha. Voy a tirarme todo el Agosto atrapado.
#87 Mola!
Te ayudo a completar un poco el script
var target = creep.pos.findClosestByRange(FIND_MY_CREEPS, {
filter: function(object) {
return object.hits < object.hitsMax;
}
});
if(target) {
creep.say('curando');
if(creep.heal(target) == ERR_NOT_IN_RANGE) {
creep.moveTo(target);
}
} else if(creep.hits < creep.hitsMax){
[b]GET THE FUCK OUT!!!![/b]
}Y ya fuera de coña, y como me aburro en el curro, se me ocurre que si te guardas en la memoria del creep que cura los HP del creep al que está curando, y en el siguiente tick, en el caso de ser el mismo creep y que después de haberlo curado tenga menos HP que en el tick anterior, ahí puedes identificar una situación en la que, si nada cambia, tu creep está bajando de vida (de seguir así, si el enemigo no muere, tu creep morirá, porque el daño que recibe es mayor al heal).
No sé, se me ocurren muchas cosas, no sé luego hasta qué punto será factible hacerlo limpio . Lo único que me sigue preocupando son esos 2MB de memoria cuando aumente el número de elementos a controlar, ya que veo mucho dato candidato a ser persistido entre un tick y el siguiente.
#87 ¿Puedes crear híbridos? Estaría bien que el healer pudiera apoyar algo desde la distancia. Esta tarde le daré a ver que sale, pero con eso que has puesto ahí ya me has enganchado xD
