Game Update: Massive Obstacle Solving test #4
Lots and lots of Archers. When i finish this i will probably make all the sprites animated GIFs or something, because this kills my computer.
Lots and lots of Archers. When i finish this i will probably make all the sprites animated GIFs or something, because this kills my computer.
This video shows how i have everything setup so i can easily create units and formations without spending hours coding. Also i show here that the units has very few lines of code because everything is a composition of many individual parts.
Testing the walk animation of the Archer Unit + a complete change in internal architecture of the code. Now it’s easyer to experiment.
Internally, all Units (Warriors, Archers, etc) are defined by 3 objects now. The Unit Settings Object, the Unit Behaviour Object and the Unit Sprite Object. All these 3 objects interact with each other to make the Unit work.
Behaviour Objects uses Tasks Objects to make diferent stuff. Tasks uses a variable number of actions implemented as a Strategy Pattern.
The base of all the fun in the game, the projectile system!
Super early test, i just finished this, just a prototype.
Ok, time to some refactoring and optimization before doing anything else. I will be posting the ‘attack behaviour‘ preview in 1 or 2 days if i have time this weekend to work on it, or next week if i dont.
Simple behaviour, or i should say, Warrior behaviour: just go after the enemy, no fear

So now they can walk, move from obstacles, chase enemies, now they need to attack them. This system will be interesting because i will use an approach that i never used before. It’s gonna be fun
Excelente Pablo, pinta muy prometedor el engine, y buena la idea de revivir un clasico.
Nicooooo hoy hay Sprint? jaja, si, lo que tiene de bueno este tipo de juegos es que se pueden jugar todo el tiempo, como el ajedrez. En unos dias ya voy a tener a los arqueros
ahí empieza la diversión!
A little better, more fluid.
Yes, i was gonna do the attack behaviour, but decided to finish this behaviour first. Now the next step is “attack behaviour”.
Ok, now this is a little better with multiple collisions, but still a little messy.
I have an idea to make it more fluid, but for the moment i will move on to the ‘attack’ behaviour.
Ok, now i’m trying to make the Units to solve obstacles in the way, this is a first attemt… it dosen’t have any Pathfinding
Right now i’m working on a possible better solution, this is the first attempt:
Ok, i’m starting to finish an early prototype.
Now i will re-code everything to organize the data structures of the game.
Geru 11:31 PM on 1 September 2010 Permalink |
Hey pablo,
en vez de hacer gif animado, porque no haces frames cacheados en bitmap data? Ese sistema es muy utilizado para hacer sistemas de particulas animadas.
ej:
var m:MovieClip = new ArcherMC()
var archerFrames:Array = [];
var b:BitmapData
for (var i:int = 0; i< m.totalFrames; i++){
b = new BitmapData(m.width,m.height,true,0×000000)
b.draw(m)
m.gotoAndStop(i+1)
archerFrames.push(b)
}
y despues cada archer tendria en su contenedor un objeto Bitmap que cambie su propiedad bitmapData al frame que corresponda.
Pablo Bandin 1:15 PM on 2 September 2010 Permalink |
Ciertamente, me gusta la idea. Pero no se como se comportaría en el juego. Porque, por la forma en que tengo los MCs organizados, cada vez que salga del frame, el movie clip se destruiría y al volver nuevamente se repetiría el proceso.
Por ejemplo, lo mando al frame de lucha, luego al de caminar, el de lucha se elimina, el espacio en memoria queda ocupado hasta el el GC lo borre, y al volver se crea todo nuevamente repetido… podría crear un especia de singleton que contenga todos los sprites cacheados, si… mmm… sería un laburito importante (en cuanto a organización)
Creo que tendría que estudiar que me llevaría menos tiempo, eso o exportar todo como una secuencia de PNGs… pero si, lo voy a tener en cuenta.
Ahora mismo estoy planeando dedicarme a cerrar el tema de programación del juego y despues dedicarme a la gráfica a full.
Tambien podría usar esta classe de ByteArray que hace justamente eso que decís.
Geru 3:22 PM on 3 September 2010 Permalink
Una vez tuve que hacer algo similar y termine usando un singleton con una matriz de bitmaps que cacheaban algo similar a eso. Entonces recurría al bitmap adecuado según orientación/movimiento del personaje.
Uses o no PNGS creo que sería necesario el singleton con los bitmaps cacheados, así mejoras mucho en cuanto a uso de memoria y performance.
Lo bueno de utilizar bitmaps es que podes poner quality Low para el stage y estéticamente se conserva la calidad (siempre que no escales o rotes).
Y si tenés la posibilidad utilizá algo de HAXE para ganar algunos frames mas
. Muy bueno el laburo que estás haciendo.