El Domingo va a ser lanzada, si no surge nada en el medio, la versión 1.0 del Simulador OpenBVE. Hoy está disponible la 0.9.7.0.
Y quiero transcribir la traducción que hice del siguiente artículo (disculpen los errores!)
http://openbve.uuuq.com/en/future.html
En esta página, quiero resumir que comenzó a motivarme en la creación de openBVE, que ha sido hecho a partir de un día al presente, y que podría seguir tarde o temprano en el futuro. Quiero asegurarme que usted entiende que algo representado en esta página sobre la futura materia es la especulación pura. Si realmente las cosas resultan como es representado en este documento sobre todo depende del interés a openBVE por la comunidad.
El principio: A partir de un día a la versión 1.0
Usted puede haberse enterado del principio KISS: Simplemente es estúpido. Esto es un paradigma de diseño de programa que es centrado alrededor de la idea de pensar en pequeños pasos y entonces realizar estos pasos sin tener un plan último a largo plazo en mente.
La arquitectura de objetos animados
Después de cuatro días de desarrollo, llegué a algún tipo de un visualizador de ruta que al menos podría reproducir una ruta del modo intencionado. Pero como aquella temprana versión no destacó ningún panel de tren aún, añadiendo el apoyo a ellos era la siguiente cosa para mí para hacer. Entonces, como traté de pensar como al mejor instrumento los paneles, vine a la idea de un sistema de objeto generalizado animado.
Básicamente, el panel de tren es una serie de objetos animados: Hay texturas que se cambian de vez en cuando (p.ej. lámparas), entonces hay objetos que realizan una rotación alrededor de un eje predefinido (p.ej. agujas), etcétera. Los usuarios de BVE Trainsim siempre estaban pidiendo la introducción de tráfico contrario, unos quieren realizar maniobras y más. Con el concepto de sólo un tren sobre un pedazo que no diverge de pista, esto es bastante ilusorio. ¿Y sin embargo, qué tiene que ver con todo esto paneles y objetos animados?
Bien, para visualizar un tren precedente o visualizar cualquier tren contrario, usted tendrá que tener un tren exterior, no sólo un panel. Y además de esto, yo siempre me sentía restringido por la vista(opinión) fija del panel de 2D del BVE, y quise tener paneles de 3D en cambio. Entonces realicé(comprendí) que yo podría preparar el apoyo a todas estas cosas al mismo tiempo por usando un sistema de objeto generalizado animado.
La idea de un objeto animado en openBVE es esto: Hay un depósito de objetos ordinarios estáticos con un estado dado. Al objeto animado entonces se le es asignado funciones que controlan los estados para mostrar, como moverlos alrededor, como hacerlos girar, y como cambiar las texturas sobre ellos alrededor. Las funciones pueden emplear la aritmética y fluir el control, y tener el acceso a una amplia gama de variables para leer datos de, p.ej. la velocidad del tren, la aceleración, la presión en cualquiera de los cilindros, el estado de las puertas, etcétera.
Mediante las combinaciones primitivas (la translación, la rotación, etc.) con la aritmética, fluye el control y variables (la velocidad, la presión, etc.), usted puede crear una amplia gama de animación, como un velocímetro en el interior de tren, ruedas sobre el tren exterior, también puertas que se cierran y abren, relojes, coches y mucho más.
En el tiempo comprendí el potencial de este acercamiento generalizado, yo sabía que openBVE podría ser traído a una vida más rica. Desde luego mucha gente todavía pregunta por qué me he concentrado en tener en cuenta los trenes exteriores (el tren no la cabina en OpenBVE se utiliza mucho el Termino "Train exteriors";comentario agregado por Martin P.) y en alguna animación, y por qué ofrezco el apoyo a altas resoluciones de demostración y los similares, cuando el foco principal de un simulador de tren debería ser el realismo. Mientras siempre trato de entender como poniendo su demostración a la resolución más baja el realismo de aumentos posible, puedo decirle seguro que el tráfico contrario es definitivamente imposible sin el exterior del tren.
Como una consecuencia, el enfoque en el objeto animado no sólo permite visualizar su propio tren, no sólo el tren precedente y no sólo los paneles delante de usted, en el futuro, esto también servirá para visualizar el tráfico contrario, mientras la belleza principal consiste en que cualquier objeto independientemente del cual hablamos puede ser totalmente animado de muchos modos. Para mí, este enfoque ahorró mucho tiempo como no tengo que manejar paneles, ni exteriores ,etcétera de cualquier modo especial. Para el motor subyacente, no hay prácticamente ninguna diferencia entre estas cosas.Desde luego, para motivos de funcionamiento, el paisaje estático es manejado sobre todo, y para la compatibilidad BVE, los paneles no son totalmente de 3D tampoco. Por supuesto, por razones de rendimiento, el paisaje realizado generalmente es estático , además para poder mantener la compatibilidad con BVE, los paneles no son totalmente en 3D, bien. Pero aún así, los desarrolladores pueden ver que se trata de algo positivo además de que la animación no se limita a los paneles, pero se puede utilizar libremente en cualquier otro lugar, también.
Mientras al principio pensé en la versión 1.0 como el punto donde alcanzar un grado aceptable de compatibilidad con BVE Trainsim, esto ahora también expone las partes principales de la arquitectura de objeto animada. Como tal, los objetos de paisaje pueden ser animados con la versión corriente, así como el exterior de los trenes.
He estado pensando mucho como debían moverse después. Seguramente, paneles de 3D no son expuestos aún, y con un simulador de tren al alcance de la mano, la cosa más obvia de hacer en el futuro es de aumentar el realismo en la parte de simulación real. Sin embargo, durante mucho tiempo, yo no conocía cuales cosas deberían tener la prioridad. ¿Debería yo poner en práctica una variedad mayor de sistemas de freno, tener la flexibilidad más señalada en cuenta, el trabajo sobre cabinas en 3D ...?
Entonces esto vino a mí en última instancia, añadiendo rasgos empotrados al código original es un callejón sin salida el camino por lo que la extensibilidad es correspondida, que es por qué completamente he replanteado mis prioridades para una versión 2.0 próxima.
La siguiente encarnación: Avance hacia la la versión 2.0
Para entender que intención tengo de hacer con la versión 2.0, usted primero debería conseguir una vislumbre de como la versión 1.0 corriente internamente es organizada, y como todo trabaja juntos.
La arquitectura de la versión 1.0
De la cima, en la versión 1.0 openBVE, tenemos un menú principal que es separado de la simulación real. Esto fue hecho por una variedad de motivos, incluyendo la creación de interfaz de usuario más fácil gráfica vía WinForms (las ventanas, botones, menús desplegables etc. con los que usted es muy familiar), y el apoyo adecuado a Unicode. Dentro del menú, usted puede poner sus opciones, seleccionar su ruta y tren, y luego comenzar la simulación.
Que pasa después de una secuencia relativamente estricta de funcionalidad empotrada: Ante todo, el analizador gramatical de ruta empotrado para .CSV o rutas .RW es usado para cargar la ruta, que a su turno hace el empleo de los analizadores gramaticales empotrados para B3D, CSV, X y objetos ANIMADOS. La carga de ruta incluye la creación del paisaje tranquilo de muchos objetos, creación de la pista sobre la cuál conduciremos (que es una descripción geométrica de donde las curvas y gradientes se encuentran), y señales que crean, estaciones y otras pequeñas cosas. Una vez que esto es hecho, tenemos una ruta sobre la cuál conducir.
Pero sin un tren, esto no es mucha diversión. Así, el analizador gramatical empotrado para trenes es usado para cargar las características de tren, sonidos, etc. El analizador gramatical a su turno podría usar los analizadores gramaticales de objeto empotrados para cargar objetos exteriores. Una vez que todo esto es hecho, tenemos un tren para conducir.
Finalmente, la simulación corre, y openBVE hace una serie de cosas para traer el tren a la vida: La física empotrada permite al tren seguir la pista, simulando choques, descarrilamientos, gravedad, momento de rotación, fricción, aire y la mayor parte de otras cosas en consideración. Sistemas de freno empotrados permiten simular frenos neumáticos y algunas formas más modernas de frenos. Mecanismos de acoplador empotrados permiten a los coches individuales de un tren para chocar el uno con el otro, así como con otros trenes. Y finalmente, datos de traída de sistemas de seguridad empotrados de transpondedores, presentan algunos indicadores al conductor, y asumen el control del tren considerado apropiado.
Ahora por el número de la expresión "empotrado" que he usado en el párrafo anterior, no parece que 1.0 tiene una muy extensibe arquitectura. Bien, una cosa interina de BVE Trainsim es la capacidad de integrar plugins externos que principalmente tienen sistemas de seguridad, así como para algunos trucos gráficos para aparecer en el panel de tren y para algunos sonidos de encargo jugar de vez en cuando. Estos plugins son limitados con algún grado. Ante todo, ellos son C/C 32 bites ++ DLLs que sólo puede ejecutar sobre Microsoft 32 bites Ventanas, que van en contra de la filosofía del openBVE de ser la plataforma enfadada. (enfadada?,¿ le habré errado en la traducción? a lo mejor quiere decir que le cuesta procesarlos
). Segundo, ellos no permiten a las lecturas de muchos componentes de tren, ni para aquellos de trenes diferentes, la geometría de pista próxima, etc. Muchos sistemas de seguridad modernos necesitan la transmisión continua de tales datos, que el plugins no ofrece (aunque un revelador bastante elegante pueda acercarse sobre tales sistemas relativamente bien). Básicamente, resumiendo, la mayor parte de la funcionalidad proporcionada es empotrado, y hay relativamente pequeños modos de ampliar aquella funcionalidad sin integrarlo directamente en el código original openBVE. Ahora aun cuando openBVE sea la fuente abierta y podría ser utilizada regularmente por alguien, un problema simple surgiría en tal caso: El contenido desarrollado para un programa de moda es improbable compatible con openBVE, tal como el contenido para openBVE es no necesariamente compatible con BVE Trainsim. También debería ser indicado que ilimitadamente la ampliación del código original con nuevos rasgos improbablemente va a trabajar a la larga. La razón es simple, y relativamente bien puede ser ilustrada con los sistemas de seguridad:
Corrientemente, openBVE ofrece ATS empotrado y sistemas ATC, o en realidad, aproximaciones solamente ásperas a la variedad infinita de los sistemas originales japoneses. Visite el Reino Unido y encuentre ATP, AWS, TPWS y otros por el estilo Vaya a Alemania y encuentre PZB, LZB, y otros por el estilo Vaya a Francia y encuentre KVB, TVM, o a Europa en general, y tenga ETCS. Usted con esperanza puede imaginarse que mientras otros simuladores de sus países respectivos ofrecen el apoyo generoso empotrado a tales sistemas, ningún simulador alguna vez suficientemente habrá detallado y el apoyo realista a todos ellos. Por eso la arquitectura de plugins permite simular cosas que el programa principal no ofrece en lo inmediato. En última instancia, esto garantiza que otros sistemas pueden ser simulados, dado que alguien escribe un plugin.
Vaya a asumir que usted sabe cual la diferencia principal entre BVE Trainsim / openBVE 1.0 y todos los otros simuladores es: codificación de mano una pista contra una red entera en 3D. Usted podría ser consciente del hecho que traté de dirigir algunas limitaciones asociadas con los formatos existentes en los cuales es codificado a mano - sin mucho éxito, solamente mencionar esto, también. Esto me hizo pensar por qué todos los analizadores gramaticales tienen que ser unos empotrados en primer lugar. ¿Considerando el poder de una arquitectura de plugins, no sólo podrían los sistemas de seguridad ser extensibe vía plugins, pero también todo el objeto, la ruta y manejar analizadores gramaticales, la física, los sistemas de freno - y por qué no la señalización, también?
La arquitectura de la versión 2.0 prevista
Como una consecuencia, me imagino un corazón mucho más ligero que realmente sólo hace las tareas más rudimentarias. Mire a la ilustración siguiente:
Y otra vez, vaya al principio de la cima. Vía un sistema de menú totalmente integrado en la simulación (más sobre aquel más tarde), usted puede seleccionar una ruta y un tren como siempre, pero entonces, las cosas son un poco diferentes comparadas a la 1.0 arquitectura.
La primera diferencia es que ninguno de los analizadores están incorporados. Todo es externo y puede ser ampliado con las características que actualmente no sea posible o imaginado. Echemos un vistazo más de cerca a los objetos. Lo incorporado en la actualidad sólo permite a los analizadores procesar formatos B3D, CSV, ANIMATED, y algo llamado X (un subconjunto de objetos de Microsoft DirectX formato). No sólo puede usted tener un intérprete que pueda procesar toda la gama de los archivos objeto de DirectX, pero también podría preguntarse acerca de por qué no tener un intérprete que puede cargar cosas de otros Simuladores ferroviarios. Hay un montón de cosas para, por ejemplo MSTS. Lo único que nos impide cargar un objeto originalmente escrito para MSTS en openBVE es la falta de apoyo a los formatos de archivo, posiblemente incluyendo los formatos de objeto y textura.
Considerando una arquitectura de enchufe, los analizadores gramaticales actualmente empotrados se harían plugins externo que se comunica con openBVE por un uso poderoso que programa el interfaz (API). En el caso de un analizador gramatical de objeto, todo lo que las necesidades para ser hechas son de presentar el analizador gramatical con un nombre del archivo agradable y hacerlo tratar el archivo para datos que openBVE puede entender. Los datos pasados atrás pueden ser usados en cualquier parte donde sea requerido, p.ej. en la ruta.
De la misma manera, un analizador gramatical de ruta tendría el trabajo de crear una pista en la forma que openBVE requiere, y poblar el mundo con muchos objetos. Si los analizadores gramaticales actualmente empotrados para CSV y rutas RW se hacen plugins externos, nada nos impediría tener plugins que podrían importar una ruta de MSTS. En última instancia, para atenerse a este ejemplo, una ruta MSTS es terminada con un archivo de actividad que dice que el camino en la ruta tomar. Incluso si usted se imagina en BVE Trainsim la pista sólo funcional sobre la cuál conducir , un programador motivado todavía podría escribir un enchufe que carga una actividad de ruta MSTS en tal estructura de pista, con todo lo demás siendo el truco visual.
La mayor parte noticable diferente entre BVE Trainsim y otros simuladores es, sin embargo, un pedazo funcional de la pista para conducir. He llegado a una conclusión que esto sería demasiado trabajo para transformar la corriente openBVE 1.0 en una red de ferrocarriles totalmente funcional. Sin embargo, teniendo una cantidad ilimitada de pistas funcionales, pero independientes, es algo que sería fácilmente posible, y también tendría el tráfico muy querido contrario en mente. Como tal, importando rutas de otro sims en openBVE no parece ser mucha diversión, todavía sería posible. Y es sobre qué la arquitectura es principalmente. No enfoco el contenido de permiso de otro sims siendo reutilizado en openBVE, pero simplemente crear una arquitectura que es extensibe a tal clase de un grado.
Vaya a mirar a las posibilidades de sistemas de freno y física, e ir al principio con el éste. Mientras los pedazos interconectados de pista todavía serían manejados por openBVE, y mientras "los ejes" o algo más qué es querido para seguir la pista todavía serían manejados por openBVE, hay un bajo que puede ser hecho además de esto. Ante todo, un coche necesita coordenadas exactas para aparecer en el espacio de 3D, afectado por un choque por ejemplo, o inexactitudes en la pista. Sobre una colisión o el descarrilamiento, usted podría querer que el coche completamente dejara la pista e hicieran algunos movimientos turbulentos. ¿Usted quiere una simulación de autobús? Bien, el autobús tendría que dejar "la pista" completamente y sería libremente controlable.
Esto es uno de los empleos del componente de física. Los otros incluyen la simulación de gravedad, viento, airean la fricción, etcétera - o, básicamente algo que cuenta como el tren tiene que mover, donde para ello para aparecer. Incluso las cosas más rudimentarias como "la velocidad" no serían una cosa que openBVE internamente entendaría ya, pero sería simulado en el juicio propio de la física de plugins. La clase diferente de vehículos necesita la física diferente. Dudo que una simulación a base de fricción fuera apropiada por un maglev, por ejemplo. Esto es donde la extensibilidad podría dar resultado, y no digamos un simulador de autobús para aquellos interesados
Y en cuanto a sistemas de freno... Bien, hay muchos sistemas de freno, aunque el más prominente sea probablemente cualquier derivado del sistema de freno neumático clásico. He gastado mucho tiempo para la creación de un sistema de freno que excede el realismo encontrado en otros simuladores, aun cuando yo fuera enfrentado con algunos desafíos que tarde o temprano no solucioné aún: Poner en práctica un tubo de freno bueno presionan el algoritmo de propagación, por ejemplo. Esto habría querido decir simular el flujo de aire y todos los retrasos asociados y fluctuaciones debido a escapes y presionaría "el consumo".
Teóricamente, sobre el papel - puramente especulativo - tal arquitectura también podría ser un modo de atraer a Mackoy, el creador de BVE Trainsim, en el desarrollo que se une sobre openBVE. Vía la ruta adecuada y el analizador gramatical de tren plugins, todo el BVE 5's nuevos formatos podrían ser manejados por openBVE.
Sin embargo, si usted ha llegado a una conclusión que en última instancia quieren decir la arquitectura entera de plugins para la integración de otro sims en openBVE, luego déjeme hacer cosas un poco más claras., como una persona sola, posiblemente no puedo crear todo lo que la gente podría querer tener en el futuro, y con todo lo que creo, openBVE todavía sería limitado con aquella funcionalidad particular. Una arquitectura de plugins tendría a otra gente en cuenta para remotamente unir el desarrollo de un simulador de tren por escribiendo los componentes que más tarde pueden ser reutilizados. Considerando otro medio de instalar el contenido (más sobre aquel más tarde), cualquier cargador de objeto de plugins podría ser usado por cualquier cargador de ruta de enchufe para cargar objetos, por ejemplo. De la misma manera, cualquier ruta o tren podrían usar cualquier física de plugin considerado apropiado, tal como cualquier tren podría usar cualquier sistema de freno o el sistema de seguridad aplicable. Con plugins que tiene tales objetivos distintos, combinándolos del modo apropiado tendrían en cuenta mucho más y el contenido detallado que posible con la funcionalidad únicamente empotrada. Esto es sobre qué la arquitectura es: extensibilidad, de cualquier modo en última instancia usado.
Desde luego hay muchas preguntas para contestar sobre como diseñar la arquitectura en sí mismo, sobre todo para las diferentes necesidades. El tiempo próximo bien podría ser gastado sobre la discusión del API, desde el diseño desde cero, para llegar a la primera y la reflexión a través de un usuario. Casi obviamente, ya he pensado en la mayor parte de las ramificaciones, y tienen un diseño especial en mente.
Ahora usted podría pensar que mi trabajo se termina en el suministro de la arquitectura, y la salida del resto a otros. Bien, uno de los objetivos más importantes es para siempre proporcionar la compatibilidad atrasada para las cosas ya creadas. Esto quiere decir que un juego de bibliotecas estándar (plugins) estará disponible para dirigir rutas CSV/RW, CSV/B3D/X/ANIMATED objetos y los trenes, y yo desde luego seguiría manteniéndolos.
Más que esto, hay cosas a las que quiero llegar como ya he mencionado antes, sobre la posibilidad de simulación individual de coche, cabinas en 3D y características de tren más flexibles. Un nuevo formato de ruta posible para la su edición mediante un editor de texto y desarrollarlo mediante el tipeo, aunque yo haya notado una carencia relativa de interés. Sin embargo, el motor principal debería proporcionar una serie de nuevos rasgos interesantes, que serán presentados en el siguiente.
Nuevos rasgos de ruta
Hay dos aspectos para el futuro desarrollo. Ante todo, hay pista. Corrientemente, sólo una pista funcional limita el tráfico significativo con el tren del jugador y cualquier tren precedente o subsecuente que conduce sobre la misma pista en la misma dirección. Como ya indicado antes, una red entera de pistas interconectadas (p.ej. mediante cambios de vía) no va a pasar para 2.0. Sin embargo, la capacidad de conducir sobre un pedazo solo de pista hacia adelante y hacia atrás, muchas veces, debería ser una posibilidad. Usted puede hacer esto también con 1.0, pero algunas cosas previene la operación significativa: Sólo quieren decir la señalización y transpondedores para trabajar en la dirección avanzada, y la estación establece un horario no interpreta cosas como la conducción hacia adelante y hacia atrás.
El cambio más importante a las pistas ellos mismos aunque sea la capacidad de tener no sólo una pista funcional, pero múltiples pistas no interconectadas. Esto, permitiendo cambiando de una pista al otro, todavía tendrá el tráfico contrario en cuenta, el tráfico paralelo, o cualquier otro tráfico significativo o sabio de efecto.
Otro aspecto es meteorológico y el tiempo de día. Quiero introducir efectos meteorológicos como la lluvia, la nieve, truenos y viento, que es efectos sobre todo visuales, pero por lo que el viento está preocupado, también funcional debido a resistencias asociadas. Por ejemplo, si el viento sopla en la dirección de viajes, la resistencia de aire será inferior como la diferencia de velocidad entre el tren y el viento sería más pequeño. De otra parte, el viento apretaría contra el área expuesta frontal del tren y aceleraría el tren en aquella dirección (aunque sea una pequeña fuerza ). Entonces, hay tiempo de día. Corrientemente, todas las rutas y objetos son construidos para representar un tiempo específico de día. Con la introducción de texturas de día/de noche y la emisión de luz, el mismo objeto puede representar condición, o en realidad, aún una transición continua entre ellos. Corrientemente, las fuentes luminosas son fijadas en la posición y el color, pero un sol simulado se desharía colores diferentes de la salida del sol a la puesta del sol, tal como la luna. El apoyo a estos fuentes luminosas rudimentarias que Efectúan Tierra deberían ser incluidas en openBVE para dejar a cualquier ruta representar cualquier tiempo de día sin un cambio de archivos de objeto y la ruta. Estaciones desde luego diferentes son otro problema, pero no actualmente intencionadas para ser dirigido este camino.
Para el mejor funcionamiento, el nivel de sistemas de detalle también probablemente es destacado en el futuro, con un sistema de dirección de objeto y la herramienta de restitución más ampliamente que apunta las necesidades de un mundo libre-itinerante de 3D en vez de un 1º pedazo de pista.
Nuevos rasgos de tren
Hay dos cosas prominentes que deberían cambiarse con la versión 2.0: Tener cabinas interactivas en 3D y simular individualmente cada coche permitiendo la creación de consists.
He estado queriendo cabinas totalmente en 3D durante mucho tiempo. Comparado a muchos otros simuladores, nunca he tenido ningún interés particular al detalle extenso geométrico. Hay muchos programas ahí que ofrecen el detalle geométrico a cargo del detalle de textura. Una regla general que he observado consiste en que más alto la cantidad de polígonos, menos probablemente se hace esto si el autor usa texturas buenas, si no alguno en absoluto. Pienso que las cabinas de BVE parecen en particular bien sobre todo porque ellos no usan el detalle geométrico, si no únicamente texturas.No quiero que el 3D sea a cargo de texturas. En el peor de los casos, yo consideraría un cubo con seis caras centradas en el ojo del conductor de una cabina en 3D, a condición de que texturas de mirar buenas sobre las caras del cubo. Posiblemente, puede haber mejor materia creada aquí, pero quiero acentuar que el 3D tiene que parecer bien, ser ello con la tendencia de geometría de la ingeniería y texturas para sólo parecer bien del punto de vista habitual del conductor.
El asunto principal asociado con cabinas en 3D es obviamente el grado más alto de libertad. Usted puede mirar alrededor libremente, observar todos los indicadores donde ellos en realidad, como se supone, son, y mirar a la izquierda o el derecho de pararse más con exactitud en estaciones, observar elementos de paisaje o permitir las operaciones que no serían posibles de otra manera.
He estado jugando algunos simuladores de vuelo últimamente (incluyendo el Orbiter, un simulador de vuelo espacial) y he notado que me gustan mejor el que donde todos los elementos en la cabina totalmente pueden ser manejados con el ratón. Considerando un vehículo de una complejidad particular, se siente algo poco realista siempre golpear sobre combinaciones (se refiere a utilizar las teclas del teclado!) claves cuando usted - en realidad - tendría que estirarse sus brazos en todas las direcciones de la cabina. Vía el control de ratón, todas las palancas, los botones e interruptores de la misma manera podrían ser manejados en openBVE, a condición de que desde luego que los usuarios quieren hacer esto. Considere screenshots siguiente de Orbiter. El que a la izquierda es interactivo, el que a la derecha lamentablemente sólo visual:
¿No hay todo lo que muchos elementos para actuar recíprocamente dentro de un verdadero tren? Bien, cualquier cabina moderna de un tren de alta velocidad está por lo general llena de mandos, y no digamos locomotoras de vapor y sus varios componentes. Desde luego, la cantidad de mandos y sus posiciones(ubicaciones) en una cabina varía enormemente entre trenes. Aquí está un ejemplo de una cabina modestamente moderna:
http://commons.wikimedia.org/wiki/File: ... nd_411.jpg
Esto también ilustra otra adición interesante posible: Apoyo a demostraciones multi-funcionales (MFDs). Si ellos deben ser animados con el texto, un texto real y la gráfica que dibuja API podría ser más práctica que el funcionamiento con un manojo de bitmaps individual. Aunque probablemente fuera solamente algún tipo de una prima y no un rasgo necesario.
Si usted siguiera el desarrollo de openBVE hasta 1.0, entonces usted probablemente puede imaginarse que el apoyo a taxis de 3D es largo disponible, solamente no expuesto aún. El formato de objeto animado proporciona todo el medio de crear objetos en el 3D y animarlos en consecuencia en una base de bajo nivel. Con los cambios arquitectónicos planificados para la 2.0, tiene que haber un pensamiento - por el interfaz primero aunque para permitir a objetos animados representar todos los variados componentes de un tren. La razón es simplemente que mientras actualmente tenemos cilindros de freno e impulsamos muescas (los puntos del controller, palancas de potencia como más te guste
), esto podría estar bien diferente con un plugin que usa otras cosas.Contenido gestionado
Una de las cosas más peculiares de BVE Trainsim es el modo que el contenido es almacenado. Primero, hay una carpeta llamada Railway con las carpetas de Rutas (Route) , los objetos (Object) y Sonidos (Sound) separadas. Así, en vez de guardar el contenido de una ruta en un pack juntos, es separado en tres carpetas dentro de otra carpeta.. A menudo, los reveladores usan nombres sin significado para una carpeta, o no usan ninguna subcarpeta totalmente. Tarde o temprano, el contenido es propenso para ser superpuesto o perdido en la selva de archivos inidentificables y carpetas.
Como un usuario de BVE Trainsim, usted es presentado con la opción para descargar archivos individuales o carpetas y tiene que montar una configuración trabajador usted mismo. A veces, los instaladores son abrigados alrededor de distribuciones, y a menudo, es inseguro donde ellos extraen el contenido exactamente, y usted tiene que chekear, instalando los archivos en una carpeta temporal solamente para asegurarse que el contenido es extraído en el modo que usted lo esperaría. Sobre actualizaciones de ruta, usted a menudo es instruido para ir a la carpeta XYZ y suprimir todos los archivos almacenados allí antes del intento de descargar e instalar la nueva versión - todo a mano desde luego.
Un problema bastante diferente es donde conseguir nuevos accesorios en primer lugar. La mayor parte de los usuarios probablemente buscan los foros para se vinculan a páginas de entrada que ellos ya no conocen, montando una lista grande así. Y de todos modos, aún después de que los años han pasado, usted tarde o temprano podría encontrar el contenido que estaba allí, sólo que usted no podía encontrarlo antes. Es así no sólo sobre el fastidio de como instalar la materia, pero también donde conseguirlo.
He estado jugando otros juegos, pero simuladores últimamente, también, incluyendo The Battle for Wesnoth, un juego de estrategia a base de vuelta (que sigue el KISS muy estrictamente). Pienso que la dirección contenta no podía ser más fácil en aquel juego. Dentro del menú principal, usted pulsa sobre Accesorios, selecciona la campaña que usted quiere descargar, y he aquí. Entonces, en cualquier momento más tarde, vaya a Hacer una campaña dentro del menú principal para seleccionar una campaña para el juego. Pienso no podía ser mucho más simple de conseguir accesorios (que aquí también son desarrollados por terceros):
¿Cómo trabaja esto? Bien, los desarrolladores crean su accesorio, luego lo cargan vía un servidor complementario, entonces usted puede descargarlo. He pensado en estas numerosas veces y pienso que aún con mucha comunidad BVE diferente, un concepto similar puede ser usado, aunque con algunas diferencias.
Ante todo, vaya a volver al modo que el contenido es almacenado sobre el disco duro. En BVE Trainsim, el contenido es inmanejado, queriéndole decir tiene que montar el contenido y ponerlo en el lugar derecho usted mismo. A veces, un pedazo de contenido (p.ej. una ruta) tiene una dependencia (p.ej. un paquete de señal). Desde luego solamente(justo) instalando(instalación) un pedazo de contenido sin otra voluntad conducen a efectos secundarios no deseados. La primera cosa que yo querría introducir (aunque todo opcionalmente) sea manejado el contenido.
El contenido manejado básicamente sería empaquetado en una carpeta sola con un nombre único e incluiría la información sobre el contenido, como las dependencias, pero también la información adicional como el ajuste de la ruta (el país, la ciudad, el operador, etc.).
Un revelador que quiere proporcionar el contenido en la forma manejada todavía podría ofrecer el descargado sobre su propia página de entrada, así no requiriendo a ningún servidor complementario (aun cuando uno fuera favorable para impedir al contenido cesarse debido a la página de entrada del revelador que se hace no disponible tarde o temprano). Darían al contenido manejado un archivo de descripción especial que es transmitible de la página de entrada de los reveladores, decir http://www.developer.org/openbve_content.txt. El archivo incluiría URLS exactas del contenido real que el desarrollador provee, p.ej. se vincula a todas las rutas transmitibles, y también la información sobre el contenido (mirar encima del párrafo). Ahora, el revelador sólo tiene que hacer de aquel archivo un archivo público de descripción de modo que los visitantes puedan tomarlo. Si usted pudiera seguir hasta ahora, seguir con el siguiente paso.
Proveedores de directorio, que son la gente que busca para encontrar el nuevo contenido sobre el web, recogerían todos los archivos de descripción que ellos pueden encontrar (tal como el recogimiento se vincula a páginas de entrada), luego cree un archivo de descripción especial de directorio, diga http://www.volunteer.org/openbve_directory.txt, que incluye el URLS a los archivos de descripción contentos de todos los reveladores conocidos, y la actualización de esta lista con regularidad. Desde luego, los proveedores de directorio harían el eslabón a su público de directorio. Si usted pudiera seguir hasta ahora, seguir con el siguiente paso.
Los usuarios llegan a conocer el URL de un proveedor de directorio, entran en aquel eslabón en openBVE, y luego la magia comienza a pasar. openBVE ahora recupera el directorio, así sabe de los archivos contentos de todos los reveladores disponibles, pregunta sobre los archivos, y así consigue una lista de todo el contenido disponible. Vaya a mirar a la información otra vez que proporcionan con el contenido. Con el país y ciudades dadas, openBVE podría clasificar el contenido por el país, por la ciudad, por el operador de tren, etc. Usted fácilmente podría encontrar el contenido que usted está interesado hojeando el contenido. De estar interesado, como con "The Battle for Wesnoth" ahora solamente pulsan un botón de Descargado, y openBVE automáticamente podrían recuperar el contenido de la página de entrada del revelador e instalar el paquete en su carpeta manejada regularmente.
Pero no solamente que, como el contenido es señalado con las dependencias, el ahora la red conocida puede ser buscada la dependencia, que entonces es descargada también. Si no está interesado en un pedazo de contenido más, usted fácilmente pudiera tal como desinstalarlo por una lista de contenido ya instalado. openBVE podría guardar la pista de dependencias y desinstalarlos también si no es necesario por algo más.
¿Sin embargo, cómo podríamos nosotros garantizar que el proveedor de directorio del que usted consiguió sólo un link en realidad ha incluido en un índice todo el contenido disponible? Probablemente, un admirador de Japón, probablemente natalmente hablando el japonés, más probablemente incluye en un índice el contenido japonés, mientras un inglés que habla a la persona podría ser más probable para incluir en un índice el contenido ESTADOUNIDENSE/británico. Bien, si proveedores de directorio no sólo incluyen en un índice el contenido, también el uno al otro, entonces, con solamente un link conocido, usted podría ganar el acceso a todo el contenido disponible por todo el mundo. En realidad he gastado mucho más pensamientos para los formatos reales de cambio y consigo todo para al menos trabajar sobre el papel. Obviamente, hay preguntas dejadas para contestar, p.ej. como útil debería ponerse en contacto con todos los reveladores solamente(justo) para comprobar para la nueva materia o actualizaciones. Esto podría tardar mucho. Si los proveedores de directorio cached la información, que sería más fácil. Pero estos son detalles de implementacion. La pregunta más importante es si tal contenido manejado sería útil o no.
El nuevo interfaz de usuario
Además de la capacidad de hojear el contenido manejado de mucho más modo mucho más estructurado (mirar encima), p.ej. por hojeando (Japón> Tokio> Tokio Metro>Línea Hanzomon) o por entrando en palabras clave, hay algunos otros cambios importantes. Corrientemente, el menú principal donde seleccionar opciones y rutas/trenes para conducir es separado de la simulación real, que hace las miradas incoherentes, y usted no puede cambiar ningún ajuste una vez que la simulación ha comenzado. Puse en práctica el menú principal WinForms principalmente porque era más fácil entonces. Escribiendo un interfaz de usuario hecho y derecho en OpenGL habría costado mucho más tiempo, de la creación de botones y otro widges, al apoyo de fuente. Tarde o temprano, quiero tener un interfaz que totalmente es integrado en la simulación.
¡Si usted alguna vez ha jugado Densha de GO! el título (demo o full), usted probablemente puede seguir que ventajas yo veo tanto visualmente como funcionalmente en una estructura como usado según aquel programa. Básicamente, usted tiene un menú sobre la cima de una imagen agradable,fullscreen de fondo, entonces usted selecciona su ruta. Para ser así, tal vez otro fondo ahora muestra la representación de la ruta seleccionada, entonces usted puede escoger el día, la estación o cualquier otra variación de la ruta, y continuar. ¡En Densha de GO!, usted ahora puede seleccionar de una serie de los trenes que son compatibles con aquella ruta, y continúan este camino hasta que la simulación pueda comenzar. Comparado a la carpeta/archivo manual busca en cuadros de diálogo como conocido de BVE Trainsim, pienso que las variaciones de ruta más fácilmente podrían ser tenidas acceso por tal acercamiento de hierachical.
Con mecanismos más poderosos que construyen la ruta, p.ej. el tiempo de día (como ilustrado antes), desarrolladores
podría en muchas ocasiones sólo tiene que proporcionar un archivo de ruta, mientras usted puede seleccionar de una serie de opciones disponibles para aquel archivo de ruta del menú.
¿Cuándo ello estará pasando?
No hay ningunas fechas de juego sobre las cuales el desarrollo podría comenzar. De hecho, aún no lo saber los rasgos que en realidad entrarán en 2.0, o si allí habrá un 2.0. Esto en gran parte depende como se interesó la comunidad en OpenBVE.
Desde hoy, no he visto mucho contenido desarrollado para openBVE, si alguno en absoluto. Sin embargo, los motivos no podían ser más obvios: openBVE 1.0 es solamente hacia fuera, y el desarrollo de contenido bueno puede tomar - bien, digamos el rato - a veces meses, a veces años. Desde luego yo no trabajaría para potencialmente nada si no hay ningún interés suficiente, entonces esto en gran parte dependerá cuanto interés noto, y a cuánto la comunidad está dispuesta a ayudar en el proceso de desarrollo.
El uno o el otro camino, si el desarrollo sigue, yo querría frenar abajo los objetivos en pedazos realizables. Por lo visto, las cabs.en 3D y trenes a base de cochesserían un principio buenos.El uno o el otro camino, durante el proceso de desarrollo, los formatos existentes probablemente son mezclados con nuevos formatos para proporcionar una transición. Otra alternativa debería desarrollar la arquitectura entera inmediatamente, pero es demasiado trabajo para hacer y demasiado aventurado el uno o el otro camino.
En este punto, yo estaría más interesado lo que los usuarios piensan.¿Hacía donde debería dirigirse OpenBVE?
¿Lo que de las cosas presenté aquí son valuoso, cuál omitiendo? Si usted quiere fijar sus pensamientos, este thread disponible sobre el foro dedicado a comentarios a este artículo. http://openbve.freeforums.org/comments- ... -t610.html
Un último sueño: Llegada a la versión 3.0:
Incluso aunque openBVE 2.0 sea solamente un objetivo áspero, openBVE 3.0 tomaría la 2.0 arquitectura más lejos por un rasgo notable: El permiso para tener múltiples pistas que son interconectadas, p.ej. vía interruptores, señalización, etc. La mayor parte de otros simuladores de tren ofrecen esto, pero esto plantea una serie de desafíos adicionales, incluyendo la señalización y el ajuste del camino correcto para un tren particular. Esto es demasiado de una futura conversación en cuanto a esto, entonces sería lo mejor si usted se concentra en el 2.0 objetivo por el momento.
--------------------------------------------------------------------------------------------------------
Ya que para leerlo lo iba a tener que traducir decidí colgarlo acá de paso
.Saludos.
