Ese pack de textura se llama 8x porque es de 8*8 píxeles, es aún mas pequeño que la textura estándar de Minetest… Cualquier tostadora puede.
Lo que yo propongo es primero usar esos que compartieron y luego cambiarlos por unos propios asi no enfocamos en programar las mecánicas básicas y principales, usamos esas texturas como meros placeholder
2 Me gusta
Voy a armar un grupo de chat entre los que quieran participar en el proyecto para no llenar de spam en el tema.
El que quiera sumarse al proyecto, que me escriba por MD y lo agrego.
1 me gusta
perdón por la pregunta sin sentido… que es un MD? el privado?
Sip… de eso se hablo en el chat General, es algo así como un grupo en WhatsApp, pero en el foro, privacy-friendly y FOSS.
Se puede crear ahora mismo, es más, ahora los estoy metiendo.
Van a notar una notificación en verde en la sección de mensajes.
¿Algo como runscape?
Yo creo que es más recomendable la filosofía de Nintendo. Primero pensar en mecánicas y luego en diseño o historia. De todas formas lo más importante del medio es su interactividar. Pienso que lo razonable es enfocarse a primeras de esta misma. De momento solo habría que utilizar un placeholder, o como se diga, yo le digo los reemplazables o pa reemplazo
En lo personal minetest no me parece muy ligero, o al menos no está optimizado para arm. He tenido que hacer sacrificio de un sacrificio para que el juego me fuera a 30 fps inestables en la resolución más pequeña que permite mi raspberry pi 4
Yo por eso quisiera hacer mi propia versión del juego a mi manera desde cero. Porque no me termina de convencer del todo. Estoy seguro que un minecraft 1.12.0 iría mejor en mi raspberry pi y la versión java. Pero bueno, ya sería en otro momento eso. Primero tendría que aprender a programar jaja
Documentación / planificación:
Lo subo por aquí, si no están de acuerdo, mejor es discutirlo por el MD, y subir el definitivo. Pero sin una planificación no se va a llegar a nada.
Programación (escenas/entidades):
+------------------------------+
|Player
|-> position (vector2)
|-> life (int)
|-> inventory (dictionary)
|-> experence (int)
+------------------------------+
|Bots
|-> position (vector2)
|-> life (int)
|-> damage (int/float)
|-> experence (int)
|-> level (int)
|-> inventory (dictionary)
+------------------------------+
|Block
|-> position (vector2)
|-> type (int)
|-> life (int/float)
+------------------------------+
|Background
|-> image
+------------------------------+
|System Save-Load
|-> data (dictionary)
+------------------------------+
Los position son del tipo Vector2 tipo predefinido. Los datos de las tentativas escenas de arriba serían los datos más importantes, lo que mandarían al SystemSave, para guardar la partida y poderla restaurar. Si está bien estructurada la documentación, la carga de partidas no debería romper el juego.
Cada programador del equipo puedo asignarse una escena de las descriptas arriba, si hay varios programadores, pueden asignarse varios a cada una. También se podrían turnar entre escenas, mientras se intente mantener cierta estructura al juego, sino se rompe el sistema de guardado.
Arte:
Animaciones:
Player:
→ Quieto
→ Caminar
→ Correr
→ Saltar
→ Atacar
→ Minar/golpear
Bots:
→ Quieto
→ Caminar
→ Atacar
Bloque:
→ Quieto (con/sin animaciones)
→ Mientras se va rompiendo
Pueden hacerse en:
Pixelart: más atención en cada pixel (puede ser 10x10, 20x20…)
Dibujo: Si el / los artista/s prefieren dibujar con tableta y lápiz, en lugar de calcular cada pixel (puede ser 100x100, 200x200…).
Música:
Pack de música de fondo (a discutir).
Pack de efectos para las diferentes animaciones del apartado artístico.
¿Qué opinan?
Lo mejor es dicutirlo por el chat, y dejar las versiones de documentación por aquí, para atraer más gente.
1 me gusta
Hola buenas,
Solo por curiosidad, ¿como ha avanzado el proyecto?
Seguís trabajando en el? No había visto esta publicación hasta hoy y me ha parecido bonito ver a la comunidad unida para crear un juego 
Si tenéis algún avance presumidlo : ) .
1 me gusta