2011-01-12 11 views
8

Tengo algunas (creo que) excelentes ideas para un juego de estrategia en línea similar a Travian. Hay algo de contenido que aún no he descifrado y algunos otros desafíos que aún no conozco.Elegir Ruby on Rails como plataforma para un juego en línea basado en navegador

Este es un proyecto bastante grande y tal vez demasiado pesado para una persona que no es un desarrollador web habilidoso (todavía). Todavía me gustaría intentarlo, pero tengo problemas para elegir una plataforma. Las "escalas" del mundo se han lanzado mucho últimamente y he visto a Ruby on Rails siendo criticado porque no se escala bien, así que he venido aquí para obtener algunas respuestas.

Me gusta Ruby on Rails, Ruby and Rails. Ciertamente no soy un experto en eso, pero me encanta trabajar con él. También he trabajado anteriormente con Python + Django y también con PHP (que no me gusta).

Idealmente, el juego tendría, digamos, 7000 jugadores por servidor, supuestamente una gran cantidad de datos por procesar por segundo . ¿Sería RoR una plataforma viable?

Disculpa si esta pregunta es vaga, supongo que estoy buscando un "RoR está bien, ¡adelante!" tipo de respuesta. Cualquier cosa que quieras agregar está bien.

Gracias!

+6

Creo que deberías intentar que 7000 personas jueguen primero antes de preocuparte por la escalabilidad. – elmt

+0

Por supuesto elmt. Pensé que la palabra "idealmente" significaría que estaba asumiendo que este sería un juego exitoso dentro de un año o cinco a partir de ahora. ;) –

+0

@elmt Acepto "Preocuparse por la escalabilidad más adelante", pero sigue siendo una pregunta válida. – Oddmund

Respuesta

6

Así que, si yo fuera usted, estaría buscando servidores sin bloqueo como node.js, simplemente porque son MUCHO más adecuados para mantener abiertas muchas conexiones durante largos períodos de tiempo, que es lo que los juegos deben hacer, en comparación con los servidores web tradicionales.

Dicho esto

Hay 3 cosas principales de las que preocuparse cuando se aumenta de escala y una aplicación web; memoria, velocidad de ejecución e io (hd y red) en ese orden.

Para la memoria, las cosas están mucho mejor de lo que solían ser. Phusion Passenger utiliza copy on write para dividir a sus empleados, por lo que el entorno de los rieles se compartirá entre todos los trabajadores en un segmento determinado, lo cual es bastante significativo. También ha habido grandes mejoras en la forma en que ruby ​​maneja la memoria en comparación con "los tiempos oscuros", si estás usando 1.8.7 entonces quieres usar los parches que componen Ruby Enterprise Edition (la diferencia es como la noche y el día) . 1.9.x fue una reescritura total del tiempo de ejecución, así que si está usando eso, los problemas de memoria ya se han solucionado.

Para la velocidad de ejecución, 1.8.7 suele ser "lo suficientemente rápido" (al menos después de ajustar la configuración de recolección de basura). 1.9.2 es en realidad alrededor de la misma velocidad que Python, lo que lo coloca en el lado más rápido de los idiomas interpretados. La importancia de este punto depende completamente de la naturaleza de su aplicación.

El último punto es IO, que no es realmente una preocupación de los rieles, sino más bien su estrategia de persistencia. A los rubyistas les encantan las cosas nuevas, por lo que encontrarás soporte de primera clase para cosas como redis y mongodb, con mucha gente hablando de usarlos y sus ganancias/ganancias. Me gustaría investigar mongo si fuera usted y ver si las compensaciones de durabilidad son aceptables.

Estaba en java /.neto antes de ir a los rieles, y al final del día, va a pagar más por la infraestructura, pero la cantidad quedará eclipsada por lo que ahorre en tiempo de desarrollo.

+0

Ese es el tipo de respuesta que quería escuchar; algunas opiniones generales y consejos. ¡Gracias un montón! =) –

+0

"Phusion Passenger utiliza copia en escritura para bifurcar a sus trabajadores, por lo que el entorno de los rieles se compartirá entre todos los trabajadores en un segmento determinado". Pero copy-on-write solo es posible con Ruby Enterprise Edition, no con 1.9.2. ¿No es así? –

1

Como dijiste a ti mismo, ya tienes la respuesta y solo estás buscando palabras alentadoras :). Yo no soy un experto en RoR, pero no creo que la escalabilidad siga siendo un gran problema en esta plataforma. Te aconsejaría hacer un pico de arquitectura (terminología XP). Escriba una prueba con 7000 clientes y un método que realice operaciones similares a las que pretende crear. Por ejemplo, puede cargar archivos, renderizar vistas o incluso esperar ... Lo importante es probar solo lo que le preocupa. ¡Buena suerte!

6

compilarlo en Rails, alojarlo en Heroku.com - trabajo hecho. Escala casi infinita de la que no tiene que preocuparse acerca de cómo funciona (simplemente funciona) y aloja muchas aplicaciones de Facebook con mucho tráfico, por lo que puede manejarlo con creces.

+0

Agradable. No sabía sobre Heroku. –

+0

Sabía sobre Heroku pero nunca pensé en alojar mi aplicación allí. Gracias por el consejo. –

+0

Como un nuevo desarrollador que no ha tenido mucha experiencia con la escalabilidad, encontrará que los cuellos de botella provienen de su propio código: solicitudes redundantes, cargar modelos en la memoria cuando no lo necesita, olvidando add_index, etc. Son cosas que aprendes a refactorizar a medida que ganas más experiencia. Una vez que tiene muchos usuarios, la IO de la base de datos es el próximo cuello de botella, y es una preocupación sin importar qué marco esté utilizando. También recomiendo a Heroku. Externalice su escala para que pueda dedicar su tiempo al desarrollo. Incluso puede escalar automáticamente: https://github.com/ddollar/heroku-autoscale – danneu

0

Esta es una pregunta un poco imposible de responder, porque para saber si los rieles son adecuados para lo que quieres hacer, necesitaríamos mucho más acerca de lo que estás tratando de hacer. El mejor consejo que puedo dar en ausencia de información es que revises el railslab scaling videos para poder resolverlo por ti mismo.

Cuestiones relacionadas