Por otro lado, es evidente que el marketing es completamente fundamental para que tu juego pueda ser visto y así jugado. Y el marketing requiere mucha dedicación, imaginación, tacto, esfuerzo y dinero.

No es una parte del desarrollo, de la producción del videojuego, pero sí una clave o mejor dicha LA CLAVE del éxito o fracaso del juego. De hecho, el market está lleno de ejemplos, como el cundy crush, etc. Dicho en otras palabras, un mal juego con un buen marketing funcionará en la mayoría de los casos. Un buen juego sin un buen marketing está jodido.

Aunque también quiero creer que si haces un buen juego, notable, etc a la larga podría llegar a tener relativo éxito aun a pesar de un marketing pobre, débil o deficiente. O eso espero, XD

A mi me gusta la "fórmula" que dio Ron Carmel en una de sus charlas:

$$$ = Promotion x Specialness

La idea es que el éxito de tu juego va en función de como de "especial" sea, y cuanta gente oiga hablar de él. Si tu juego es muy interesante y pulido y divertido y diferente, a muy poca promoción que hagas probablemente sea un éxito, porque a la gente le tiran esos juegos, y los recomiendan, y hablan de ellos en foros y hacen videos de youtube, y aparecen en revistas porque los periodistas lo siguen porque también le llaman la antención esos juegos, etc...

El ejemplo más extremo de eso puede que sea Minecraft, pero puedes encontrar muchos otros a menor escala donde la promoción consiste en que el desarrollador tiene una cuenta Twitter y una página de Facebook, y pone actualizaciones de forma más o menos consistente. Si haces eso, y envías tu juego a periodistas, concursos y demás, ya tienes bastante avanzado, y no requiere unos conocimientos ni un esfuerzo fuera de lo normal.

Eso sí, si tu juego no tiene mucho de especial, entonces más te vale invertir en marketing y comprar anuncios, porque la gente no va hablar de "un juego más" del montón que no llama especialmente la atención, ni los periodistas van a escribir sobre ello, ni recibirá premios o interés en los concursos, ni nada...

Generalmente las mecánicas no son registrables, y no se suele considerar plagio siempre que los gráficos y demás sean distintos. Digo generalmente, porque ha habido casos puntuales donde SI que se ha considerado que un clon estaba infringiendo el copyright (el que se me viene a la cabeza es Triple Town contra uno de sus clones)

El otro tema es que si esas compañias deciden echarse encima tuya, la legalidad no importa tanto como parece, porque aunque tu tengas razon y al final ganes, tendras que ir a juicio de todos modos, con los gastos que eso conlleva, que posiblemente sean mayores que lo que puedas ingresar con el juego.

ni puede prescindir del trabajo por un juego indie que no se sabe como funcionará ni quiere perder la oportunidad de tener algún ingreso a mayores a raíz del trabajo realizado

Vale, pues despues de mirarlo, explico un poco mas esto, que tambien está relacionado con el punto 5)

Puedes trabajar por cuenta ajena, y aun asi facturar sin ser autonomo por lo que ganes de tu juego, siempre que sea un pequeño ingreso extraordinario y no se considere tu forma de sustento.

Para hacer eso, te das de alta como autonomo en Hacienda, pero no en la S. Social. Luego facturas como si fueras autonomo. Tienes tambien que presentar las declaraciones trimestrales de IVA e IRPF cuando correspondan. La diferencia es que no pagas la cuota de autonomos de la SS.

Las condiciones para hacer esto son:
- Tener otro trabajo que se pueda considerar como tu principal sustento.
- Que no estés cobrando paro.
- Que sea algo puntual. No factures todos los meses, porque entonces entras en la definicion de "habitual" que comentaba antes.
- Que sea por menos del salario minimo anual.

Aun asi, es posible que la SS se pille un mosqueo contigo y te ponga una sancion, que tendras que pagar y posteriormente recurrir (deberias ganar, siempre que cumplas las condiciones).

Antes de nada, lo mejor en estos casos es acudir a alguna gestoría, que son los que conocen la ley al dedillo. Lo que te podamos decir por el foro no lo tomes como cierto al 100%, verificalo antes. Si sigues un consejo erroneo y te metes en un lio, Hacienda va a ir a por ti y no a por el forero que te aconsejó mal.

Dicho eso:

1) Técnicamente deberías ser autónomo, aunque eso depende de cuanto vayas a ingresar.

2) Hay dos formas de hacer esto:

- La fácil: La plataforma se encarga de vender en todo el mundo. Y tu solo les facturas a ellos. En la práctica es como si tuvieras un sólo comprador (Steam, o el que sea), y cada mes, trimestre, o cuando toque les haces una factura por el total que te van a pagar en ese periodo. Sólo tendrás que pagar el IVA que corresponda a esa factura, si es que corresponde alguno (sigue leyendo...)

- La dificil: La plataforma es solo un intermediario, y eres tu quien vende al cliente final. En estos casos tendrás que aplicar el IVA correspondiente a cada venta según el pais donde esté el cliente. Por lo que conozco, esta modalidad es menos habitual, pero creo que hay alguna store que funciona asi.

Sobre el IVA: Solo deberas pagar IVA en facturas a clientes españoles o europeos. Si son españoles pagas el 21%. Si son europeos tendras que aplicar el IVA del pais en cuestión -creo que hay una ventanilla única para centralizar esto, pero mejor lo consultas con tu gestor ;) En otros casos (ejemplo, facturas a Steam, y Steam tiene sede en USA), no hay que pagar IVA.

Tendras que declarar cada tres meses el IVA que hayas recaudado (y darselo a Montoro), asi como indicar el IVA del que te quieres deducir (guarda todas las facturas!)

Sobre el IRPF: Como las facturas no son a profesionales ni empresas españolas (generalmente) no tienes que retenerlo. Tendrás que hacer la declaración trimestral y la de la renta anual que tiene que hacer todo el mundo, donde tendras que declarar lo que hayas ingresado.

3) Sí, claro, pero cuidadín!! Basicamente la regla es que si es una actividad remunerada y habitual, tienes que darte de alta como autonomo. La definicion de habitual es... complicada. Si no recuerdo mal existe precedente legal de no tener que darte de alta si tus ingresos son inferiores al salario minimo, pero aun asi ten cuidado. Es un poco un balance de riesgo. Cuanto más ganes, mas riesgo tienes si no te das de alta. Ya depende de tu tolerancia al riesgo.

4) Esto no lo he hecho nunca, pero entiendo que será como la forma "dificil" que te comentaba antes. Tendras que aplicar el IVA correspondiente en cada caso. Pero como digo, no lo se al 100%.

5) Consulta a tu gestor. Pero que yo sepa si que puedes ser autonomo y tambien trabajar por cuenta ajena a la vez, aunque probablemente tengas que pagar a la Seguridad Social por duplicado.

6) Hay varias formas. Podeis constituir una empresa en la que todos (o algunos, como veais) seais socios, y la empresa paga a cada uno en funcion del trabajo (como si lo subcontratara a un freelance), o mediante reparto de beneficios. Si no quereis empresa, podeis hacer que uno "compre" el trabajo a los demas. Ese uno es el dueño legal del producto, y los demas le facturan por el trabajo que cada uno ha realizado "para el".

Esto lo teneis que hablar entre vosotros, y firmar los contratos que veais oportunos. Si vais a montar una empresa, esta será la dueña de la propiedad intelectual, o bien una licencia para explotarla. Igualmente si no teneis empresa, la persona individual que venda el juego tendrá que tener la propiedad intelectual.

Por lo que dices, parece que lo que te cuesta es el proceso de descomponer un problema en sus partes lógicas. Gran parte de aprender a programar es en realidad aprender a usar esta habilidad, y ser capaz de deducir una forma de combinar las distintas órdenes y piezas que ofrece el lenguaje para solucionar el problema en cuestión.

La mala noticia es que esto es una habilidad, y por tanto no hay un "truco" que te permita puentear su aprendizaje. La buena noticia es que esto es una habilidad, y por tanto puedes entrenarte en ella y mejorar con el tiempo y dedicación, como cualquier otra habilidad (conducir, tocar un instrumento, escribir, dibujar....)

Mi consejo sería que busques formas de entrenar esta habilidad más allá de estudiar programación. Por ejemplo, hay juegos como Spacechem o Infinifactory que se basan en esta misma habilidad de saber descomponer un problema en pasos más pequeños, y si juegas a ellos estarás entrenandote y al mismo tiempo te será menos frustrante. Tambien mucho del material moderno que se usa para enseñar a niños a programar se basa en el mismo concepto y son prácticamente juegos donde arrastras los "ifs" y bucles de forma visual, conectandolos para resolver un problema. Mira a ver si este tipo de material te pueda ser util también (que no te corte el que sea para niños. Igualmente, cuando empiezas a aprender un idioma los libros que vas a poder leer al principio son solo los que están escritos pensando en niños o adolescentes, etc...)

En esa misma linea, puede venirte bien dibujar diagramas de flujo cuando estes programando, donde el proceso de toma de decisiones (los ifs, los bucles...) se muestra de forma más clara y visual, lo que te puede facilitar el visualizarlo y trabajar con ello.

Haz juegos.

Muchos de los mejores diseñadores (y programadores, grafistas...) son autodidactas, simplemente porque cuando empezaron aun no existían ni masters ni cursos "oficiales", ni nada del estilo. Los recursos que necesitas para aprender están ahí, a tu disposición. Tienes tutoriales, artículos, libros, proyectos de ejemplo, series de video-tutoriales en Youtube, etc... y todo gratis.

Muchas de las herramientas son ya gratuitas, o tienen precios tan bajos que seguro que te lo puedes permitir. Y las que no, seguramente no las vayas a sacar partido de todos modos. Si el dinero es un problema, olvidate de los masters. Bajate una herramienta, unos cuantos tutoriales, y ponte a trabajar. Puedes empezar hoy mismo a hacer un juego, si quieres.

Diseñador significa cosas distintas según a quién preguntes. En algunas empresas significa hacer los mapas, y ajustar los valores de armas, enemigos, etc... pero a mi me gusta más la definición que usa Firaxis, y que también la he visto repetida en muchos indies:

Según ellos, un diseñador es el que decide las reglas del juego. Pero como los juegos son interactivos, un diseñador debe conocer el lenguaje de la interacción, que es el de la programación. Eso no significa SER programador, igual que saber esbozar rápido un arma o personaje en una hoja de papel no es lo mismo que ser un grafista. Basta con tener el nivel de programación suficiente como para poder expresar tus ideas en forma de prototipos interactivos que otras personas puedan probar.

Esto libera al diseñador de la dependencia de otras personas, que es uno de los principales bloqueos que tienes delante para aprender. Si puedes prototipar tus ideas, puedes iterar sobre ellas, ajustarlas, y encontrar la diversión (o hacer que expresen lo que quieras que expresen). Y no tienes porque depender de un programador (que no entenderá como quieres que funcione tu idea), o un grafista (que no entenderá lo que quieres trasmitir)

Sí, el prototipo será feo, porque no eres un grafista, y el rendimiento será malo, y a veces se colgará, porque no eres un programador. Pero es similar a que un arquitecto haga una maqueta del edificio. La maqueta no tiene ni las tuberías, ni los cables de electricidad, ni los materiales finales... Pero sirve como un punto de partida que luego usará el resto del equipo.

Como verás, el rol del diseñador es crítico. Gran parte del futuro del proyecto depende de sus decisiones. Por eso es dificil entrar a la industria como diseñador. Un diseñador recién salido de un master no tiene mucha experiencia. ¿Confiarias el futuro de un proyecto a alguien sin experiencia? Normalmente se suelen buscar diseñadores dentro de la propia plantilla, o bien en empresas más grandes, diseñadores junior entendidos como los que ajustan valores de armas y poco más, que tienen poco poder de decisión sobre el proyecto en sí.

Como digo, para aprender a diseñar juegos la mejor manera es: hacer juegos.

También puedes jugar a juegos y analizarlos de forma crítica. Y leer libros. Y recibir formación tipo charlas, masters, etc... Pero todo eso es complementario a hacer juegos.

Así que vamos a hacer juegos. Algunas herramientas seguro que las conoces:
- Unity
- Unreal4 (aunque yo suelo recomendar Unity a principiantes, porque es más fácil de aprender)

Pero existen alternativas más centradas en 2D, que no requieren muchos conocimientos de programación, y pueden ser un buen punto de entrada:
- Game Maker
- RPG Maker (para hacer juegos tipo RPG retro)
- Hacer mods de juegos existentes (ej: Skyrim)
- Stencyl
- Twine (aventuras de texto interactivas)
- Y muchas mas...

Practicamente todas ellas tienen tutoriales o recursos de aprendizaje gratuitos, en inglés claro. Mira en las webs de las propias herramientas (ej: la web de Unity tiene videos introductorios, y practicamente todas te enlazan a tutoriales por donde empezar a aprender, manuales y demás). Mira también las comunidades de desarrolladores de cada caso, seguro que tienen recursos de aprendizaje. Busca el nombre de la herramienta seguido de "tutorial" en youtube o google, y sigue profundizando. Busca el nombre de la herramienta en Amazon, y te saldrán libros de donde aprender. Para saber cuales son buenos, mira las reviews.

Haz juegos.

No hagas el juego en que estás pensando. Aun no vas a saber cómo. Haz los juegos que te recomienden los tutoriales. Apunta bajo y termina lo que empieces. Luego apunta algo más alto y terminalo. Luego un poco más arriba. Termínalo... etc.

Haz juegos cortos. Las jams son una buena oportunidad para forzarte a hacer cosas pequeñas y acabarlas, ya que te fuerzan a reducir el scope, asi que apuntate a todas las que puedas.

Para aprender más sobre diseño: http://www.pixelprospector.com/the-big-list-of-game-design/
De hecho, esa pagina es buena, empieza por la raiz: http://www.pixelprospector.com/game-development

Si usas Unity, visita la Asset Store y tira de assets para lo que no sepas hacer. Tienes también assets como PlayMaker que te permiten hacer programación visual (en base a nodos y grafos) en lugar de tener que programar con código. No te engañes, sigue siendo programación, pero es más accesible.

Si tu objetivo es ser diseñador, céntrate en HACER EL JUEGO de la forma más efectiva posible. No te enfrasques en la tecnología a no ser que lo que quieras sea aprender dicha tecnología.

Y bueno, me he cansado ya de escribir, pero espero que ayude algo y si tienes dudas pregunta!

Este artículo confunde "industria del videojuego" con "modelo AAA". Incluso si el modelo actual de AAA entrara en crisis, eso no es lo mismo que decir que hay una crisis en la industria. La industria es mucho más grande que eso!

De hecho, algunos de los puntos que comenta son exactamente opuestos dependiendo de qué parte de la industria mires. "Aumento de los costes de producción" es un buen ejemplo: con las herramientas modernas nunca ha sido TAN BARATO hacer un juego siendo un estudio pequeño! Si hubiera intentado hacer un juego como el mío hace 10-15 años me hubiera sido imposible. En realidad, de lo que está hablando es que los juegos AAA tienden a ser cada vez más grandes, y eso lleva costes mayores, pero eso sólo es cierto en ese sub-mercado. Y aunque llegue un momento donde esa estrategia deje de ser rentable, en ese caso se adoptaría otra nueva que sí lo sea. Mientras haya demanda por este tipo de juegos, seguirá habiendo triple A.

Igualmente comenta "competencia del mercado móvil", como si de alguna forma los juegos móviles no fueran parte de la industria del videojuego, cuando en realidad el efecto de estas plataformas es aumentar el posible "pool" de jugadores a cantidades enormes de gente nunca antes vista. O que pasa, ¿es que los jugadores de Angry Birds o Plants vs Zombies no cuentan?

Comenta también problemas como la "simplificación" y juegos más fáciles y aburridos. Será que no ha jugado a Bloodborne, o a Super Meat Boy, etc... Que haya una serie de juegos que te parezcan demasiado fáciles no significa que eso sea un problema en toda la industria, significa simplemente que esos juegos no te gustan a ti... y ya está. Hay más juegos, y si buscas un poco encuentras montones que si que están diseñados para gente que le gusten los juegos difíciles, o más complejos.

En cualquier caso, todo esto son problemas puntuales de ciertos modelos de negocio, sagas, o empresas. Mientras la gente quiera jugar a videojuegos, existirá una industria dedicada a ello. Igualmente que no va a desaparecer la industria editorial simplemente porque haya muchos libros malos en Amazon. Como mucho desaparecería Amazon, pero la gente no va a dejar de leer los libros que le interese. ¡Yo tampoco voy a dejar de escuchar mi música porque en la TV solo se escuche a One Direction, por ejemplo!

Y la verdad es que no lo se, las cosas en un determinado sector (construccion, empresas .com, etc) nunca van tan bien como justo antes de estallar una burbuja.
A mi me huele parecido a burbuja, pero no tengo suficientes datos para saberlo, tengo dudas...

Las burbujas son algo muy específico, relacionado con la especulación. Ocurre cuando la gente comienza a invertir en algo esperando que ese algo suba de valor en el mercado, pero en realidad el valor real de ese algo está por debajo de lo que la gente cree.

No veo como se aplica el concepto al videojuego, dado que el mecanismo básico que provoca una burbuja no existe en esta industria. Yo no "invierto" en juegos esperando que se revaloricen. Y a no ser que seas un bussiness angel, tampoco inviertes en empresas. Lo que haces es comprar un producto, y la industria a dia de hoy se basa en vender ese producto al público. Los ingresos de las empresas de videojuegos vienen directamente de ventas, no de la especulación. Si venden, sobreviven. Si no venden, se hunden.

Por tanto no es una burbuja especulativa, si no que es un mercado común y corriente donde hay una demanda (videojuegos), y mientras esa demanda exista, habrá incentivo para que la gente haga videojuegos y cubra la demanda. Por muchos problemas que haya, y modelos de negocio nuevos que triunfen / fallen / etc... al final siempre habrá una estabilidad entre demanda por jugar, y empresas que hagan juegos.

el problema es cuando haces cosas por ejemplo para Kongregate o newgrounds, o cualquier portal de estos de juegos (licencia exclusiva) que no tiene nada que ver con android o iphone. Por ahora estoy poniendome al dia en el tema de programación y montandome la estructura del proyecto que tengo en mente pero cuando vaya a declarar la verdad es que no se que le voy a decir al gestor al ser compañias del extranjero. xD. El extranjero da como yuyu, al no ser españa no es algo tan facil de comprobar.

A mi no me parece para tanto, da igual si es Apple, Kongregate, o Pipas Martínez, tu sigues siempre el mismo sistema. En mi caso estoy con una gestoría, y cada vez que recibo un pago, hago la factura por la cantidad que he cobrado, y se la paso al gestor para que la apunte. Lo que tiene que ir en la factura depende de donde sea la empresa, pero eso te lo puede explicar el gestor. Y si a tu gestor el tema del extranjero le lía... ¡pues cambia de gestor!

[Sobre el IVA:]

Hola. Aunque no tengo experiencia en Google Play, si que puedo comentar en plan general, mientras alguno que si tenga experiencia en esa tienda se anima a contestar con los detalles.

Por lo que he visto, hay dos formas de gestionar esto, dependiendo de la tienda:

Lo más sencillo es que la tienda se encargue de todos los detalles (facturar a clientes, IVA, etc...), y te de un agregado de tus ingresos finales tras aplicar su comisión (un total de lo que has ganado ese mes). En este caso tu no vendes a los clientes finales, sino que eres un proveedor de la tienda (es como si la tienda te comprara el juego a ti). Lo que harías sería facturar a la tienda por ese total, aplicando el IVA que corresponda según el pais donde esté la tienda.

La otra forma es que la tienda sea solo un intermediario, y seas tu el que vendes al cliente final. En este caso la tienda debe darte más datos: todas las ventas que se han hecho, y desglosadas por país. Lo normal es que la tienda aplique el IVA correspondiente al cliente final, y simplemente te diga: has vendido el juego a un Alemán, por 5€ + X de IVA, y así con todos. En ese caso tendrás que sumar y declarar todos esos ingresos, y lo mismo con todo el IVA que hayas recaudado, por pais (más sobre eso abajo).

Generalmente en este segundo caso la tienda se quedará una comisión. Lo habitual es que eso se declare como un gasto (es decir, la tienda te factura a ti X-tantos euros, que corresponde por ejemplo al 30% de tus ingresos). Esto es: si has generado ingresos por 1000€, pero la tienda sólo te da 700€ tras descontar su comisión, tu tienes que seguir declarando los 1000€, y luego declarar 300€ como gastos.

Sobre el IVA:

Ten cuidado con esto, sobre todo con el IVA en la UE, porque muchos artículos están desactualizados. Básicamente:
- Si vendes fuera de la UE, no hay que poner IVA.
- Si vendes en España, pones el IVA español (21%), y lo declaras en el 303
- Si vendes en la UE a consumidores finales, pones el IVA del pais del comprador (YA NO ES EL 21%), y lo declaras en el modelo 368, desglosando por cada pais.
- Si vendes en la UE a una empresa dada de alta en el ROI con un número válido en el VIES, no hay que poner IVA (esto sería por ejemplo si es el primer caso que comentaba antes, donde facturas a la tienda en lugar de a clientes finales, y la tienda tiene sede en Europa)

Disclaimer: no conozco este curso, ni he hecho ningún otro, y generalmente soy bastante "anti-cursos" y prefiero ser auto-didacta

Por partes:
¿Sabes programar? Si ya sabes programar, este curso no parece que te vaya a aportar mucho, ya que por lo que veo es principalmente un curso de introducción a C#, no tanto un curso de Unity (hay otro curso más centrado en Unity en la misma web). Incluso si no sabes C#, pero conoces otros lenguajes como C++, Java, etc... con que te leas un par de artículos sobre las diferencias te basta. El resto es práctica.

Si no sabes programar, creo que hay muchos recursos gratuitos para aprender a programar online (por ejemplo: http://www.codecademy.com/es/), videos en youtube, páginas, libros, etc... Y si sabes inglés, los recursos son casi infinitos.

En cuanto a Unity: es un poco lo mismo, tienes muchísimos recursos online gratuitos, y libros y demás que puedes usar ya mismo si quieres. Aunque en este caso lo que yo veo interesante de los cursos es que te "obligan" a practicar lo que aprendes, y si tienes una dinámica profesor - alumno en que puedas hacer preguntas y tal, puede ser interesante.

Pero como digo, si sabes inglés, tienes recursos infinitos. Puedes empezar por la serie Cooking With Unity, por ejemplo (https://www.youtube.com/playlist?list=PLlHjNcdoyw6UK30xrTUhjM-usQOOE5jhN)

Personalmente no le doy mucho valor a la "acreditación" o el título en sí, especialmente tratándose de un curso online. En mi opinion, el valor estos cursos es el de lo que te enseñan, ni mas ni menos.

A lo mejor llego un poco tarde, pero bueno...

Yo valoraría lo que aporta el clon sobre el original. Si el clon es una copia "tal cual", y no aporta nada de cosecha propia, para mi no tiene valor alguno. Podría no existir y no perderíamos nada.

Sin embargo, la mayoría de lo que llamamos clones en realidad incorporan elementos nuevos propios. Puede que mezclen conceptos venidos de otros géneros. Puede que estén dirigidos a otras plataformas, donde los controles son distintos y obligan a readaptar el juego. O puede que simplemente perfeccionen mecánicas que el original creó, pero que no llevó hasta su máximo nivel posible.

Si hacemos un poco memoria, al principio sólo existía Doom. No había First-Person-Shooters como tales. A lo que había se les llamaba "clones de Doom". Pero con el tiempo esos clones, y los que vinieron detrás, fueron evolucionando, llevándo las ideas originales a nuevos territorios, centrándose en un aspecto y olvidando otros, etc... hasta que al final crearon lo que ahora vemos como un género de juegos.

Yo diría que incluso un reskin puede ser interesante, siempre que aporte algo nuevo que no existía antes. El pasar un shooter de, por ejemplo, una ambientación actual, a una ambientación de ciencia ficción puede abrir nuevas oportunidades para explorar otras ideas y mecánicas (aunque sea simplemente contar una historia distinta y más fresca).

Pero la clave está en aportar siempre algo. No reproducir lo mismo que ya han hecho antes, sino añadir de tu cosecha.

Yo lo valoraría en este orden:

1) Juego terminado, y bien programado.
2) Juego terminado, y mal programado.
3) Juego no terminado, pero lo que hay está bien hecho.
4) Juego no terminado, y mal hecho.

Aunque como dice Valnar, las empresas generalmente no van a mirar el código de tu proyecto, sino que van a evaluar tu nivel de programación mediante tests y/o preguntas en la entrevista.

Recomendaría ver la GDC desde el punto de vista de una inversión: ¿qué es lo que esperas obtener, y hasta que punto estás dispuesto a pagar por ello?

Generalmente, veo dos tipos de mentalidades respecto a cómo asistir:

- Ir a las conferencias
Normalmente se trata de empleados de empresas "potentes", tipo AAA o estudios más pequeños pero conocidos, que asisten con pase Full Access o Main. En estos casos, a la empresa le compensa gastarse la pasta con el objetivo de que su lead técnico (o de diseño, o el que sea) pueda ir a las conferencias y volver con nuevos conocimientos técnicos, información sobre herramientas, etc... que les haga más competitivos.

- Ir a networking
En este caso tu objetivo es darte a conocer, enseñar tu juego / prototipo / lo que sea, e intentar conseguir un trato con un publisher o similar. Para esto no necesitas gastarte mucho (con el pase Expo ya tienes acceso a la mayoría de zonas), y muchos de los eventos de networking son fuera de la GDC en sí (estate atento a los "mixers", fiestas y demás que hay todos los días). Ayuda el ir ya con algunos encuentros concertados de antemano, si es posible.

No tiene por qué ser 100% exclusivo, ya que aunque vayas a networking, también puedes visitar la expo, y tendrás acceso a todas las charlas sponsorizadas, y de "advocacy", que no son pocas. Igualmente, si vas a ver conferencias, también puedes ir a los "mixers", hablar con los indies que expongan en la expo, etc...

Personalmente si eres indie, recomiendo el pase Indie, que precisamente está pensado para este tipo de desarrollador. Te da acceso a todas las charlas "indie", la expo y charlas sponsorizadas y advocacy. Y luego a hacer networking

Si no estás seguro, te diría que fueras primero a la GDC Europe (que es más barata), y en base a eso juzgues si te merece la pena ir a la GDC proper o no el proximo año.

En cuanto a las charlas en si, suelen ser muy interesantes, pero lo que decía antes: ¿hasta qué punto estás dispuesto a pagar por ellas? ¿vas a rentabilizar esa inversión?

Si te sobra el dinero, y te da igual si las vas a rentabilizar o no, pues tomalo como unas vacaciones, y adelante. Es una experiencia muy chula y divertida, asi que tampoco es cuestion de sentirse mal por invertir en pasarlo bien y aprender, si te lo puedes permitir.

No conocía el curso,  pero juzgando por la página que enlazas, veo el temario bastante simplón para un curso que se supone es de 450 horas. Quizas ayudaria si dieran información más detallada.

Compara por ejemplo con el de Trazos (que tampoco sé si es bueno o no), y la información que dan sobre temario para un curso de mucha menor duración: http://www.trazos.net/cursos/curso-de-produccion-de-videojuegos

En general no soy muy partidario de cursos online. Existen bastantes recursos gratuitos en Internet en forma de tutoriales, videoseries, foros, etc... como para que no aporten demasiado. A un curso presencial si que le veo más valor, ya que tiene una dinámica muy distinta a la hora de aprender.

Antes de nada, trabajo en una pequeña empresa, asi que mi respuesta puede estar algo condicionada por ello.

Personalmente, creo que depende del tipo de puesto. Para un puesto de responsabilidad (ej: diseñador, programador jefe, cosas asi...) creo que es mejor una empresa grande. Vas a tomar decisiones importantes para el poyecto, y el proyecto en sí va a ser más grande e interesante. Si lo que quieres es especializarte en una cosa muy concreta (ej: programador de IA), en una empresa grande vas a poder hacerlo. Pero si lo que te ofrecen es un puesto de menor nivel, no especializado, pienso que es preferible la empresa pequeña.

En una empresa pequeña tendrás mucha más influencia en el desarrollo del proyecto, lo que hará que sientas el juego como algo en parte "tuyo", cosa que no es tan fácil si estás apretando tornillos en una gran corporación, en base a decisiones tomadas a un nivel tan por encima de tí que ni siquiera nadie se ha molestado en explicartelas. Además, vas a tocar más campos y aspectos distintos, por lo que vas a tener un aprendizaje mas extenso de como funciona el desarrollo de un juego en conjunto, aunque no aprendas tantas técnicas específicas de ningún campo en concreto como haciendo un trabajo especializado en una empresa mayor.

Este tipo de aprendizaje creo que es más útil para conseguir puestos de responsabilidad en el futuro, o montar tu propio desarrollo. Pienso que es mejor conocer el 100% del desarrollo de un juego pequeño al 10% del de uno grande, porque te va a permitir conocer lo suficiente de cada uno de los aspectos para poder comunicarte con especialistas de esos campos, tomar decisiones informadas, etc... que de la otra forma no podrías.

Por supuesto, hay más factores importantes: cómo es el entorno de trabajo, el proyecto, la gente, tu sueldo y condiciones, etc... y generalmente una empresa mayor ofrece más estabilidad laboral, que también es importante en los tiempos que corren.

Un saludo.