Tio el dev blog se me queda corto, necesito que hagas videos en youtube contando como haces toda esta mierda es que suena super interesante xD
Ojalá saber una tercera parte de lo que sabes tu, la mayoría de cosas ni las entiendo ni sabria por donde empezar 
Te esta quedando fetén 
#35 thanks, aun no estoy trabajando el apartado gráfico, en ese sentido va a mejorar bastante.
#36 si lo dices por el multiplayer, empiezas por un chat, sigues con un pong, llegas al típico juego de tanques donde ya sincronizas varios elementos simultáneamente, posición tanque, giro cañón, balas...
Y si te "engancha", el resto ya es "bola de nieve montaña abajo" xD
En la versión actual...
Una vez pasado por el gzip del server son 190KB de código, el resto son assets.
Arriba el consumo de memoria RAM, el orden es:
- hilo principal Core
- worker Física
- worker Multiplayer
- worker Renderizador
Unas 20 veces menos de lo que ocuparía en el WebGL de Unity.
edit: incluso son cifras por debajo de Proyect Tiny, pero en 3D y con multiplayer.
Lo que yo me pregunto es qué haces en este foro y no currando en alguna empresa tochisima siendo el puto boss de tecnología y cobrando en barcos y putas.
#42 yo si estuviera en un barco no postearía en mv salvo para poner fotos de mi barco y mis putas xD
Tal vez ha contratado gente para que postee en mediavida, y cada cuenta que ha borrado era alguien que ha despedido, mientras él disfruta de sus barcos y putas
Pequeño update gráfico, esperar carga del mapa de luz... (las puertas están mal iluminadas, se "bakearon" abiertas, fix pendiente de elaborar @aikonCWD ).
Ahora toca refactorizar... y después física de vuelo + planeta.
#36 Cuando aprendas de networking verás que es sencillo.
Cada puerta guarda un booleano que decide si está abierta o cerrada.
Player pasa por el trigger de abrir la puerta 1 en su versión local (o bien el trigger se activa en server-side si tienes collision detection allí) -> manda paquete al server -> el server hace broadcast del nuevo estado de la puerta a todos los demás -> done.
La mayoría de gente sucumbe al miedo antes de aprender.
Yo te digo que te atrevas a fallar. Te darás cuenta de que las cosas realmente no son tan difíciles como parecen, y que está bien si la cagas, todo tiene arreglo en esta industria. Y si no que se lo digan a Sean Murray.
#40 Unity nunca jamás va a tener builds tan ligeras, es imposible. Y que exista Unity Tiny es la prueba de ello (que menuda puta mierda es Unity Tiny por cierto).
#49 Buen curro.
Oye quizá te interesa esto: https://wwwtyro.github.io/space-3d/
Genera skyboxes ambientadas en el espacio. Yo lo he usado un par de veces, está guay.
#51 Entonces tu lo que haces es enviarle el user a tocado esta tecla y ya en el server lo tratas todo? Nunca he tocado multi, pero normalmente no es así? Como suele ser normalmente?
Que usas en el server para las físicas?
#52 es para evitar cheats.
¿De qué te sirve un multi si cualquiera puede hacer trampas?
Ahora mismo estoy con cannonjs tanto en cliente como server. Aunque para el server es posible que lo cambie en el futuro...
#53 Y no afecta a tema rendimiento por ejemplo hacer calculos en el cliente y después pasarlo al server? O sería lo mismo? Son preguntas muy de noob supongo
#51 En mi opinión Unity Tiny podría estar bien llamándolo de otra forma, que no sea Unity, porque no tiene nada que ver con el workflow de Unity - es algo totalmente distinto, y para empezar ni siquiera es motor Unity, es un framework que trabaja con canvas.
Que quizá dentro de 5 años estará usable para proyectos grandes y tal, pues sí, pero en mi opinión no es Unity, es algo a parte.
#54 En resumen:
- Si lo haces todo server side, el cliente es super ligero, carga instantáneo, al final solo está renderizando información. Drawbacks: Delay de input, coste de servidores más alto porque simulan todo.
- Si lo haces mixto (para mí la mejor opción): Simulas tanto en cliente como en server y en server comparas, al final la versión que estará siempre bien es la del servidor, así que si alguien hace trampa, lo puedes pillar fácil, pero evitas que el player tenga una peor experiencia debido a delays.
- Si lo haces lo más simple que hay, todo client side, servidor sólo replica paquetes: Coste de servidores ridículo pero carne de tramposos pobres como @elraro
#57 el workflow de Unity tiene fecha de caducidad... Tiny es parte de lo que viene con DOTS.
Ahora que Tiny ha migrado a C# no lo llamaría framework.
