tada-s

Descripción: Mapa semi-realista Titulo del mapa: de_bidepot Tipo: de_ Slots: 16 TT - 16 CT Tamaño: Grande Descarga: http://gamebanana.com/maps/195681 Imágenes y comentarios: Encontré este proyecto abandonado que había iniciado hace años y dije: "Híjole, este map nunca la terminé.". Al inicio, la escencia de este map fué crear un mapa tan realista (a nivel gráfico), como se pueda llevando al límite el motor de juego GoldSrc que es del año 1998, tan realista que parezca un mapa para el motor Source. No pude lograr esa escencia, por la falta de experienca para este fin. Tuve muchos factores en cuenta al diseñar este mapa. En jugabilidad tuve en cuenta el balance, la forma del mapa, comprobando con cronometrado de tiempos de recorrido y pruebas de juego con bots. La prueba con bots no funcionaba correctamente porque en el primer reconocimiento del mapa, parecía que no detectaban los brushes CLIP y nunca pasaban el pasillo que conecta SpawnTT y Bomb Site 1. Tuve limitaciones con el motor de juego como la cantidad y tamaño de texturas (no superar 4 MB) porque me tiraba el error de MAX_MAP_MIPTEX. Aunque podía utilizar el flag -texdata para aumentar esta capacidad y utilizar texturas de mayor esolución y mas variedades, preferí no modificarla para que sigan siendo compatibles con computadoras antiguas. Por lo tanto, se tuvo que achicar y reutilizar bastante las texturas para que caiga en el rango de 4 MB. Intenté que las texturas sean completamente nuevas pero como las texturas de Paranoia son tan geniales, utilicé una gran parte de ella. Tuve en cuenta un poco en la estética y cuidar en no agregar tantos detalles para que no sea grotesca y mantener cierta simplicidad. No se utilizaron models para que se pueda jugar sólamente con el archivo .bsp y los sprites que vienen por defecto en el juego. Se tuvo en cuenta el performance del mapa al diseñar aunque igual fue muy difícil controlarlas. Utilicé texturas Hint-Skip para intentar amortiguar el performance pero no tuve mucha suerte. Aunque hay un punto donde la vista es muy abierto, la mayoría de los lugares es más cerrado. Algunos sólidos se convirtieron en entities para mejorar el rendimiento. No se si este sea mi último map (dentro de los pocos que había creado hasta ahora), pero probablemente no crearé mapas hasta que se me antoje hacer otra. Saludos Tadashi Descarga alternativa: https://mega.nz/#!upBDUC7Y!tCtxFNBMqULmyTshU8NQxfCdUGo85SP5z4EhdxQSC-g http://gamebanana.com/maps/195681 Screenshot

En estos días estuve intentando resolver unos cuántos problemas de teoría de grafos. Ahora que me topé con este artículo, me encontré que es interesante aplicar la teoría de grafos en los mapas para hacer un análisis matemático. Me puse a pensar y pude rescatar el siguiente análisis: Se puede determinar que un mapa si es simple o no contando la cantidad de ciclos que tiene un mapa. Por ejemplo, de_torn es más laberinto que de_aztec y eso está reflejado en la cantidad de ciclos que tiene el map. El de_aztec tiene sólamente 5 ciclos y de_torn tiene 11 ciclos (véase la imagen de abajo). De paso conté que de_dust2 tiene 5 ciclos y de_inferno tiene más de 14 ciclos (y eso increiblemente mucho). Cuando un mapa tiene muchos ciclos, habrá muchísimas formas que se puede ir de un punto en particular a otro punto en particular del mapa (desde base tt a base ct o desde bombiste B a largo, etc.). Y obviamente si el map tiene pocos ciclos, tendrá sólamente 1 o 2 formas de llegar hasta un lugar. Podemos aprobechar este análisis para contruir otras formas (geometrías) de mapas que tenga la propiedad de pocos laberintos o simples: por ejemplo, crear mapas que sólamente tenga 5 ciclos (imagen de abajo). Y estos mapas que no son muy "laberintosos" serán fáciles de aprender. En resumen, cuanto más ciclos tiene el mapa, más complejo es el mapa y cuando más complejo es el mapa, más difícil de aprender. :'/ Este análisis que hice ya podría ser un simple criterio para ver si un map es complejo o simple. Cabe aclarar no es completo ni excato ya que falta más profundidad y abarcar más detalles. Edit 2: No sé si se nota pero hice el esfuerzo para que el texto que escribí no sea muy... difícil de entender. ¿El texto sigue siendo difícil de entender? Edit: Si no entienden algo de lo que escribí, pueden preguntar y con gusto lo explicaré. Si no entienden nada, igual les explico Edit 3: Agh... Lo que hago cuando no me entran ganas para estudiar en la facu T_T. Bueno. Me iré a estudiar.

Muy buen punto. Ese sacrificio creo que fue muy importante (y). Como el techo está un poco lejano a la vista del jugador, se podría reducir las texturas a tamaños mucho menores a 256x256 Respecto al map, ofrece una característica interesante: más divertido cuando más gente está jugando, a diferencia de aim_map: más divertido cuando menos gente está jugando. La textura "{arbolada_trees" veo que perdió mucho la calidad cuando creaste. ¿Qué programa usaste para cambiar a 256 colores?

Mi primer map que comensé a crear fue mi colegio. Empecé a trabajar en marzo 2007 y terminé el noviembre 2009. Durante todos estos años, aprendí muchas cosas sobre el mapping y volví a crear en total 4 veces todo el map hasta que me convenciera (Fueron muy grandes la diferencia). Es enorme el map y no es apto para el motor de juego de Counter-Strike pero en ese momento no sabía sobre epolys ni wpolys. Igual, nos divertimos jugando el map hasta que la directora de mi cole me llamó, llamaron a mis padres, me explicó que el colegio me puede demandar por crear este map. Borré todas (excepto una oculta en mi PC). de_sanjo (unas pocas imagenes y sin el .bsp por razones legales ) Mi primer map que terminé fue la que comensé y terminé el noviembre 2009 (antes del map del colegio). de_radistation Descarga: https://mega.co.nz/#!boJ0lJyC!gwnDaZiaIlIGcVYYHyzPtV5oWJvuQSYC8oa8-GubOj8

Muchas felicidades DanielMap, BetanSaim y Carnacleos! Sus mapas son muy lindos e interesantes, así como de los demás maps que se presentaron en este torneo. Cada una son diferentes y tiene se puede apreciar el estilo que tiene cada uno (y hace poco había visto un mapa muy muy similar al aim_decound de Carnacleos). Es muy dificil apreciar un map atraves de las fotos (algunas no son muy descriptivas). Se podría publicar los maps para que se pueda descargar??

Cuando estuve preparando el map para el torneo tuve dudas sobre el critero de optimización: estaba definido por fps (como mínimo 60fps) y noté que dependiendo de la máquina y otros factores es muy diferente el fps que tendrá en los maps. Tengo una PC muy rápida, muy pocas veces llega a 70fps y eso hacía que fuese complicado imaginar el fps que podría tener los jurados. Tuve que ingeniar guiandome por los wpolys y epolys de los mapas oficiales. Si un map funciona a 100fps en la PC del mapper, una cómun en estos días, y en la PC del jurado, una de hace 4 años, le corre con 50fps e influye a la calificación sería frustrante para el mapper. Creo que el rendimiento del map es un factor decisivo muy crítico: un map innvoador con una jugabilidad excelente puede llegar a ser descartado completamente desde un comienzo si funciona a 20fps. Propongo en debatir sobre "cómo determinar si el rendimiento de un map es bueno o malo". PD: Después de escribir todo esto, estoy en dudas si ésto es innecesario (ya que tiendo a analizar profundo a las cosas y eso podría complicar las cosas).

Animación original... es el conjunto de animación que es caminar, saltar, agachar, disparar? Es para que un jugador tenga ese model? o es para colocar en alguna parte del mapa? qué parte del mapa? Qué quiere que haga el zombie? Esta enjaulado? Está caminado en cualquier dirección? camina lentamente como zombie? o camina como supermodelo? xD Son algunas cosas que no entiendo bien. Puedo hacerlo pero lo ideal sería que tú lo hagas. ¿Sabes cómo animar un model y compilar?

Se puede hacer eso. Qué tipo de animación quieres que tenga??

Hola todos! Como no he podido terminar el map a tiempo para el primer torneo de mapping, escribo este tutorial con el fin de transmitir la idea de no quedar encerrado con viejas teorías y herramientas y extender los brazos a nuevas ideas y conceptos. En este tutorial utilizaremos el programa tree[d] 3.0 para generar el árbol y kHED 1.1.5 para aplicación de textura, compilación y otros ajustes. Este tutorial supone que usted tiene el manejo básico del programa kHED. De lo contrario puede aprender en el siguiente link: http://www.mundo-mapping.net/foro/showthread.php?174-GU%C3%8DA-Crear-modelos-3d-en-kHED-%28PARTE-1%29. Link de descarga del programa tree[d] 3.0 (actualmente, 26/04/2015, ya no existe la pagina oficial) Link: https://web.archive.org/web/20130915030534/http://www.frecle.net/treed/tree%5Bd%5D- setup310.exe Navegación: Click derecho: Zoom Click izquierdo: Rotación de la cámara Proceso Generar y exportar el árbol Ejecutamos el programa tree[d] y generamos nuestro árbol deseado. Para tener un buen rendimiento (fps) en el juego, hay que estar atento en la cantidad de triángulos! Se sugiere que esté mas o menos dentro del rango de 300 a 800 triángulos (sí, muy poco). Pero éste rango puede variar mucho (incluso más que 800 triangulos), dependiendo del máximo wpolys y epolys que tendrá cada map (está relacionado con la cantidad de triangulos visibles desde cualquier lugar. Véase "r_speeds 1"), y también del motor de juego y la GPU de cada máquina. Algunos ajustes rápidos para reducir la cantidad de triángulos: Utilizar textura que continene varias hojas en vez de utilizar texturas de unsa sola hoja. Para eso, cantidad de "Leaf" colocamos 0 y activamos los "Cross Horizontal Geometry" y "Cross Vertical Gemoetry". (Reduce drásticamente) Reducir la subramificación o "Sub Branches" a 1 o 2. (Reduce drásticamente) Reducir la ramificación o "branch". (Reduce moderadamente) Reducir la segmentación en longitud y perimetral o "Length Segs" y "Radial Segs" en el tronco "Trunk" y ramificación "Branch". (Reduce suavemente) Otras combinaciones de ajustes. Modificación directa sobre el model en kHED. Este proceso se puede realizar en cualquier momento después de exportar a .obj. Recuerda! Al reducir la cantidad de triángulos se obtiene mejor rendimiento pero se sacrifica el aspecto del árbol. Luego de generar nuestro árbol, exportamos como archivo .obj Editar el archivo .obj Como kHED no carga los datos .mtl (la información del "material" o textura) al importar los archivos .obj, debemos separar en dos (o tres) archivos .obj. Abrimos el archivo .obj con bloc de notas (o cualquier editor de texto) y encontraremos una extensa lista de numeros. Básicamente tiene esta estructura: mtllib Save OBJ.mtl o trunk # verts v 0.228363 0.00198195 -0.00269278 v 0.0887559 -0.00124904 -0.157965 : : # normals vn 0.984815 0.0336342 0.170316 vn 0.542289 -0.111007 -0.832826 : : # texcoords vt 0.0 0.0 0.0 vt -0.166667 0.0 0.0 vt -0.333333 0.0 0.0 : : g usemtl wood03png f 2/2/2 8/8/8 1/1/1 f 2/2/2 9/9/9 8/8/8 f 3/3/3 9/9/9 2/2/2 : : g usemtl leaf08png f 76/76/76 79/79/79 77/77/77 f 76/76/76 78/78/78 79/79/79 f 80/80/80 83/83/83 81/81/81 : : La primera parte "roja" está almacenada la información de los vértices y alineación de texturas entre otras cosas. Esa parte no tocamos. La segunda parte "rosa" con "verde", comienza con una "g" minúscula y luego una extensa información de caras. Ésta nos interesa. Lo que haremos es crear dos (o tres) copias de este archivo .obj y lo renombramos (como ejemplo, ramas.obj y hojas.obj). En la primera copia eliminamos un bloque, o sea, la primera "g" y la extensa lista de caras "f numero/numero/numero ..." (Este proceso podemos agilizar utilizando el "Buscar" de bloc de notas buscando la palabra "g"). En la segunda copia eliminamos el otro bloque desde el segundo "g" y la extensa lista de caras. Así, tenemos dos archivos, una con hojas y la otra con ramas. Nota: Sólamente necesitamos dos copias si utilizamos hoja chiquita y ramas o cúmulo de hojas ("cross geometry") y ramas. Si utilizamos hoja chiquita, el cúmulo de hojas y ramas, debemos hacer tres copias y cada una debe contener un sólo bloque de caras. Texturizar, combinar y otros detalles. 1) Ejecutamos el programa kHED e importamos uno de los archivos .obj. 2) Seleccionamos todas las caras . 3) En la ventana de Groups , agrupamos y renombramos . 4) Abrimos la ventana de material , creamos un nuevo "material", renombramos y cargamos una imagen (la imagen debe cumplir varios requisitos). 5) Asignamos el material al model (debe estar seleccionado el objeto). 6) Verificamos el UVmap del material (el objeto debe estar seleccionado). Si está completamente afuera de la imagen, reacomodamos los vértices de manera adecuada para evitar un bug en las texturas. Puede o no estar el poligono completamente adentro pero por lo menos una parte de ella debe estar encima de la imagen. 7) Guardamos como un archivo .khe ? Repetimos este proceso con el otro archivo .obj. 9) Luego, combinamos los dos models en el menú [File]->[Merge... Ctrl+Shift+O]. 10) Redimensionamos agrandando (o achicando) y damos los toques que deseamos Resultado Voilà ! Ya está listo para compilar!

Ya tengo la idea! Me anoto

Hola todos! Hoy les traigo otro tutorial fantástico creado exclusivamente para mapping-zone.net! XD Bueno. Este tutorial consiste en crear una textura animada (que se mueve) y utilizaremos este model como ejemplo: +0lab1_cmpm3 Como se crea? Es fácil! Primeramente, las texturas que se mueven tiene un “+”, “un numero” y “nombre de la textura” al principio del nombre de la textura. El “+” indica que es una textura que se mueve y “un numero” significa que frame es. Ejemplo: +0mapping-zone.net. La textura de Half-Life, se mueve a 10fps (10 frames per second) o mejor dicho, se cambia las imágenes cada 0.10 segundos.http://img444.imageshack.us/img444/4532/2lab1cmpm3.png Por ejemplo, la textura +0lab1_cmpm3 que hay en halflife.wad, está compuesto así: +0lab1_cmpm3 +1lab1_cmpm3 +2lab1_cmpm3 +3lab1_cmpm3 +4lab1_cmpm3 +5lab1_cmpm3 Y cuando aplicas esta textura (solo una de la lista), esta se mueve cuando juegas! Cuando agregas a un wad, tenes que poner todas las texturas (en este caso los 6) en el wad. Importante El número de frame máximo es de 0 a 9. Por lo tanto, no funcionará las texturas como +01screen_1. Pero no creo que tengan problema con eso, porque no usarán mucho. Espero que les sirva!