Leo en el blog de juanma zarza (aka mrkoala) una reflexión bastante interesante acerca del advergaming y su fama entre el público en general.
Y es que es muy raro que nadie se fije en uno de esos juegos "cutres" que publicitan una marca se vean en ninguna parte. Es cierto que hay mucha mierda y es cierto que muchos juegos móvil no tienen suficiente calidad. Eso sí, vemos a diario rumores sobre posibles juegos de EA o de gameloft (veer anaitgames, por poner un ejemplo) que sí, son unas super potencias en cuanto a juegos para móvil, pero que en mi opinión están super-valoradas, y pongo un ejemplo.[Y no quiero no hablar de la calidad de muchos de los juegos de nintendo DS (sobretodo) que se analizan...]
El ejemplo es uno de los últimos juegos de unkasoft en el que he participado directamente, que nadie conoce, pero que ya está por ahí. Se trata de una promoción llamada idrinks para diferentes bebidas alcohólicas. Bien, el juego está desarrollado en unos 8 días reales (en medio estuvo la navidad), esto es, desde 0 se crea un juego, gráficos, código y música... y todo eso para 450 móviles. Ahora pregunto, tiene eso menos mérito que crear un juegazo en 8 meses como hace gameloft? en 8 meses el equipo de unkasoft (en los juegos todos ponemos nuestro grano de arena) ha creado unos juegos de una calidad muy alta para los tiempos de desarrollo en los que nos movemos. Es tanta la diferencia?
¿Qué pasa? pues que somos así, tanto los que crean las noticias, como quienes las escriben. Muy poco se han preocupado los blogs o portales de noticias españolas por unkasoft (y otras muchas que trabajan en la sombra), a pesar de que los juegos que se hagan sean de una calidad altísima (sobretodo últimamente) incluso con licencias de películas que han estado en taquilla (rec, donkey xote), etc, etc. Eso sí, unkasoft tampoco puede/quiere/tiene tiempo de darle un poco más de bombo y publicitar un poco más los juegos que hace... a veces los NDA hacen un flaco favor a una empresa.
Me queda el consuelo de ver como cada día vamos mejorando nuestros juegos (a algunos puedes jugar gratis en unkasoft gamespace), sobretodo viendo los bocetos y desarrollos que tenemos actualmente en recamara.
Más vale pájaro en mano que ciento volando: Menos rumores de iphone y más noticias de verdad.
3.30.2008
3.29.2008
Serializando en C++: implementación quick and dirty
Si hay una cosa que me molesta es tener que repetir código o funcionalidad. Cuando estás programando te das cuenta que a veces hay partes de funcionalidad que hacen más o menos lo mismo.
Hay veces que tienes que implementar algo y cuando lo haces por gusto pues puedes pararte a implementar un mega sistema de serialización que te mueres, pero cuando tienes que hacer algo que sabes que no va a salir de ahí nunca te da igual la orientación a objetos. Esta es una lucha que siempre he tenido con mucha gente, el sobrediseño, el sobre*, es decir, la tendencia a tener que aplicar los patronos existentes, la necesidad de usar una metología o un paradigma concreto, pero eso es otra historia.
Necesitaba guardar y cargar datos y no me apetecía andar modificando el loader cada vez que modificase el writer... así que (formato patrocinado por vim):
#include
<stdio.h>
class A
{
public:
int a;
int b;
float c;
typedef unsigned int (*serialize_t)(void*, unsigned int, unsigned int, FILE* f);
void Save(FILE* f)
{
Serialize(f, (serialize_t)fwrite);
}
void Load(FILE* f)
{
Serialize(f, fread);
}
virtual void Serialize(FILE* f, serialize_t ser)
{
#define SER(x) ser(&(x), sizeof(x), 1, f)
SER(a);
SER(b);
SER(c);
}
};
int main()
{
const char* fn = "test.bin";
FILE* f = fopen(fn, "wb");
A a;
a.a = 11;
a.b = 22;
a.c = 33.33f;
a.Save(f);
fclose(f);
A c;
f = fopen(fn, "rb");
c.Load(f);
printf("a: %d, b %d, c %f\n", c.a, c.b,c.c);
fclose(f);
return 0;
}
guarro, poco elegante, rompe todos los paradigmas, pero rápido, funcional y efectivo :D
Hay veces que tienes que implementar algo y cuando lo haces por gusto pues puedes pararte a implementar un mega sistema de serialización que te mueres, pero cuando tienes que hacer algo que sabes que no va a salir de ahí nunca te da igual la orientación a objetos. Esta es una lucha que siempre he tenido con mucha gente, el sobrediseño, el sobre*, es decir, la tendencia a tener que aplicar los patronos existentes, la necesidad de usar una metología o un paradigma concreto, pero eso es otra historia.
Necesitaba guardar y cargar datos y no me apetecía andar modificando el loader cada vez que modificase el writer... así que (formato patrocinado por vim):
#include
<stdio.h>
class A
{
public:
int a;
int b;
float c;
typedef unsigned int (*serialize_t)(void*, unsigned int, unsigned int, FILE* f);
void Save(FILE* f)
{
Serialize(f, (serialize_t)fwrite);
}
void Load(FILE* f)
{
Serialize(f, fread);
}
virtual void Serialize(FILE* f, serialize_t ser)
{
#define SER(x) ser(&(x), sizeof(x), 1, f)
SER(a);
SER(b);
SER(c);
}
};
int main()
{
const char* fn = "test.bin";
FILE* f = fopen(fn, "wb");
A a;
a.a = 11;
a.b = 22;
a.c = 33.33f;
a.Save(f);
fclose(f);
A c;
f = fopen(fn, "rb");
c.Load(f);
printf("a: %d, b %d, c %f\n", c.a, c.b,c.c);
fclose(f);
return 0;
}
guarro, poco elegante, rompe todos los paradigmas, pero rápido, funcional y efectivo :D
3.26.2008
agroguía 2.0
Sí, ahora que estamos con la fiebre de la 2.0, de la web social, de facebook, de twitter y de todas esas cosas para las que todavía no he encontrado utilidad, resulta que ahora los usuarios de agroguía generan y suben su propio contenido a la web.
Nosotros frecuentemente subimos videos para tener a la gente interesada y "enganchada" en cierto modo. Hay uqe tener en cuenta que el target de usuarios de esta aplicación no soy muy dados a las nuevas tecnologías (aunque más de lo que se cree y me creía debo decir. Resulta que buscando un poco por youtube sobre sistemas similares me encuentro con que un cliente nuestro se ha grabado en video usando agroguía y lo ha subido... :).
Estyo terminando algunas de las nuevas features de agroguía, en unos días subiré unos videos mostrando como funcionan... eso siempre que sea capaz de hablar despacio, no hay nada peor que grabarse y comprobar que lo que te han repetido durante años es verdad, hablo a toda leche, me como palabras y me explico mal :).
Ya lo estoy viendo, de aquí a un año los agricultores subiendo sus parcelas, con sus tiempos, sus rendimientos, intentando estar en el top10 :)
Nosotros frecuentemente subimos videos para tener a la gente interesada y "enganchada" en cierto modo. Hay uqe tener en cuenta que el target de usuarios de esta aplicación no soy muy dados a las nuevas tecnologías (aunque más de lo que se cree y me creía debo decir. Resulta que buscando un poco por youtube sobre sistemas similares me encuentro con que un cliente nuestro se ha grabado en video usando agroguía y lo ha subido... :).
Estyo terminando algunas de las nuevas features de agroguía, en unos días subiré unos videos mostrando como funcionan... eso siempre que sea capaz de hablar despacio, no hay nada peor que grabarse y comprobar que lo que te han repetido durante años es verdad, hablo a toda leche, me como palabras y me explico mal :).
Ya lo estoy viendo, de aquí a un año los agricultores subiendo sus parcelas, con sus tiempos, sus rendimientos, intentando estar en el top10 :)
3.23.2008
clase transaccional en python
Después de unas "largas" vacaciones sin tocar el pc (apenas recuerdo donde están las teclas :) apetece leerse algún buen artículo, como por ejemplo uno de clases transaccionales en python.
Interesante artículo por varios motivos:
- La propia clase, personalmente creo que puede ser bastante útil, luego pongo un ejemplo
- El uso de introspection (o reflexion o como quiera que se llame) en python. Simple y efectivo
- La explicación, paso a paso, y el código final con sus test unitarios.
Este es el típico ejemplo de pequeña clase que se complica y que termina siendo un verdadero infierno si no se tienen claros los contratos. Personalmente he tenido muy malas experiencias con clases en teoría simples, pero que dado su uso intensivo terminan por matar una aplicación. Por ejemplo, una clase tan simple como un vector, que en resumen no dejan de ser 4 métodos, es usada en todo el código, seguramente por varias personas que no tendrán ni idea de como está implementada (con razón), de la cual se pueden sacar unas cuantas "condiciones de contorno" que pueden hacer que la aplicación fracase estrepitosamente ya que cada persona puede decir: "es que yo pensé que funcionaba así"
En cuanto a la clase transaccional, se me ocurre un uso muy práctico. Estamos acostumbrados a ver diálogos wizards y configururaciones en todas las aplicaciones. El usuario cambia valores, toquetea y al final pulsa sobre 'Ok' o sobre 'Cancel'. El planteamiento de la lógica del diálogo podría ser el siguiente:
- al comienzo del diálogo se hace una copia de los datos.
- se modifica la copia en función de los eventos de usuario
- si el usuario acepta, se vuelcan los cambios que están en la copia en los datos originales.
Queda mucho más elegante el siguiente funcionamiento:
- se modifican los datos (que implementan el modelo transacional) en función de los eventos de usuario.
- si el usuario cancela se hace rollback.
Pero es que además, con este modelo tenemos solucionado el típico undo que tantos quebraderos de cabeza da de forma "transparente" (de hecho implementa el típico patron memento). Si unes esto a una serialización como dios manda ya tienes solucionado medio modelo de datos de la aplicación :).
Eso sí, la clase tiene varios problemas, por lo menos dos que yo vea:
- si hay atributos muy pesados en 4 commits te has zumbado unos megas de ram y estos lenguajes dinámicos no son precisamente ahorradores en este aspecto
- a poco mal que hagas el modelo de datos habrá variables que no te interese, perdón, que no deban guardar el estado. Pasa exactamente lo mismo que con la serialización.
Interesante artículo por varios motivos:
- La propia clase, personalmente creo que puede ser bastante útil, luego pongo un ejemplo
- El uso de introspection (o reflexion o como quiera que se llame) en python. Simple y efectivo
- La explicación, paso a paso, y el código final con sus test unitarios.
Este es el típico ejemplo de pequeña clase que se complica y que termina siendo un verdadero infierno si no se tienen claros los contratos. Personalmente he tenido muy malas experiencias con clases en teoría simples, pero que dado su uso intensivo terminan por matar una aplicación. Por ejemplo, una clase tan simple como un vector, que en resumen no dejan de ser 4 métodos, es usada en todo el código, seguramente por varias personas que no tendrán ni idea de como está implementada (con razón), de la cual se pueden sacar unas cuantas "condiciones de contorno" que pueden hacer que la aplicación fracase estrepitosamente ya que cada persona puede decir: "es que yo pensé que funcionaba así"
En cuanto a la clase transaccional, se me ocurre un uso muy práctico. Estamos acostumbrados a ver diálogos wizards y configururaciones en todas las aplicaciones. El usuario cambia valores, toquetea y al final pulsa sobre 'Ok' o sobre 'Cancel'. El planteamiento de la lógica del diálogo podría ser el siguiente:
- al comienzo del diálogo se hace una copia de los datos.
- se modifica la copia en función de los eventos de usuario
- si el usuario acepta, se vuelcan los cambios que están en la copia en los datos originales.
Queda mucho más elegante el siguiente funcionamiento:
- se modifican los datos (que implementan el modelo transacional) en función de los eventos de usuario.
- si el usuario cancela se hace rollback.
Pero es que además, con este modelo tenemos solucionado el típico undo que tantos quebraderos de cabeza da de forma "transparente" (de hecho implementa el típico patron memento). Si unes esto a una serialización como dios manda ya tienes solucionado medio modelo de datos de la aplicación :).
Eso sí, la clase tiene varios problemas, por lo menos dos que yo vea:
- si hay atributos muy pesados en 4 commits te has zumbado unos megas de ram y estos lenguajes dinámicos no son precisamente ahorradores en este aspecto
- a poco mal que hagas el modelo de datos habrá variables que no te interese, perdón, que no deban guardar el estado. Pasa exactamente lo mismo que con la serialización.
3.12.2008
Los aerogeneradores como faros
Lo bueno que tiene hacer de comercial es que a veces te encuentras con cosas curiosas. Resulta que el otro día fui a Barruelos del Valle (google maps) y curiosamente el agricultor interesado era el alcalde del pueblo. Charlando con él acerca de algunos temas técnicos, salió el tema de los aeorgeneradores aprovechando que al lado había un parque eólico y le pregunté para qué servían esas luces que tienen en la parte superior.
Resulta que cada molino tiene una luz que parpadea periódicamente y la verdad es que incluso a plena luz del día ya se veía con claridad. El chico me comentó que de noche era un verdadero infierno, que se hacía de día cada medio segundo... No me lo creía hasta que he podido comprobar que desde mi pueblo, a unos 50kms, (y más lejos) puedo ver las luces. Si pasas por la A-62 o la A-6 lo podrás ver desde bastante lejos.
Otra cosa que me llamó la atención es que las luces de los aerogeneradores están sincronizadas. Lógicamente nadie se gasta dinero en sincronizar las luces para nada. Según me comentaron, estas luces se usan como faros para loa aviones. Cada parque eolico tiene un periodo diferente, de forma que viendo los periodos es posible "triangular" y saber donde se está.
Una curiosidad técnica y un martirio para los habitantes cercanos al parque.
Resulta que cada molino tiene una luz que parpadea periódicamente y la verdad es que incluso a plena luz del día ya se veía con claridad. El chico me comentó que de noche era un verdadero infierno, que se hacía de día cada medio segundo... No me lo creía hasta que he podido comprobar que desde mi pueblo, a unos 50kms, (y más lejos) puedo ver las luces. Si pasas por la A-62 o la A-6 lo podrás ver desde bastante lejos.
Otra cosa que me llamó la atención es que las luces de los aerogeneradores están sincronizadas. Lógicamente nadie se gasta dinero en sincronizar las luces para nada. Según me comentaron, estas luces se usan como faros para loa aviones. Cada parque eolico tiene un periodo diferente, de forma que viendo los periodos es posible "triangular" y saber donde se está.
Una curiosidad técnica y un martirio para los habitantes cercanos al parque.
Suscribirse a:
Entradas (Atom)