Las probabilidades de la lotería

De vez en cuando compro un boleto de lotería, lo reconozco. ¿Por qué? Pues no lo sé. Supongo que como todos, por aquello de... "y si toca"... Supongo que todos caemos en la (falsa) idea de que a alguien le tiene que tocar. Y lo cierto, es que eso no es cierto. 😊

Mucha gente nos hemos tomado la molestia de entender cómo funciona la lotería. Vas a la web y lees los datos, las probabilidades, y listo. En un juego como el de los Euromillones, por ejemplo, la probabilidad de ganar un premio de primera categoría es de 1 entre 139,838,160 (más info aqui)

¿Pero, qué quiere decir eso exactamente? Si jugaras una apuesta en todos y cada uno de los sorteos de Euromillones, ¿cuánto tiempo crees que te costaría ganarlo? Hay quien dice que ni en un millon de años...

Qué exagerados, ¿no? ¿Cuánto tiempo dirías tu? Es evidente que no esperas ganar después de 1 año jugando, sería un chollo. Pero... ¿Y si estás 10 años jugando? ¿Y si son 50 años, toda una vida, jugando sin excepción dos veces todas las semanas? ¿Dirías que tienes una probabilidad aceptable de que te toque?

Ni remotamente.

Los que entienden algo de mates, saben que no. Que puedes estar una vida, y dos, y tres, jugando, y que no te va a tocar. Pero yo quería verlo. Experimentarlo. Quería tener una idea real de cómo de difícil es que te toque. Evidentemente, el azar es el azar y puedes ganarlos en la primera apuesta, pero también no ganarlos nunca. 

Decidí investigar, y encontré simuladores que permitían hacer eso: simular apuestas una y otra vez. Lamentablemente, en cuanto empecé a probarlos me di cuenta de que eran demasiado lentos. La cosa iba para largo, y su baja velocidad iba a hacer la prueba inviable. Así que hice lo único que se hacer: programé un simulador de Euromillones más rápido que los que había por ahí.

Es una aplicación que simula el proceso de tener 50 bolas en un bombo, y sacar 5 al azar para los números normales. Luego repite el proceso después, sacando 2 de entre 12 bolas más (para las estrellas). Además, hace esto dos veces por sorteo, una para sacar la combinación ganadora, y otra para sacar una apuesta distinta cada vez. Todo ello, 17.000 veces por segundo.

Programé la aplicación para simular 1 apuesta simple por sorteo, 2 veces por semana, con el bote máximo (190 Millones de Euros de premio). Añadí además una estimación de las cantidades que recibes en los premios (cuando resulta que hay premio) para poder tener un balance del dinero que llevas gastado y ganado. 

El resultado, como podéis ver en el vídeo de más arriba, es desalentador. 

1.383.899 años jugando

Más de 78 millones de euros perdidos

Y eso a pesar de haber ganado un bote de 190 millones de euros. Lo cierto es que en el vídeo se ve claramente que, cuanto más juegas, más pierdes.

¿Es más probable ganar con apuestas aleatorias, o siempre la misma?

La teoría nos dice que la probabilidad de ganar es la misma (si no fuera la misma, tened bien claro que su precio no sería el mismo tampoco), pero gracias a este simulador, podemos comprobarlo.

He ejecutado la simulación desmarcando la opción de que regenera la apuesta cada vez, para que siempre sea la misma. ¿El resultado? Pues igual. En este caso en 1500 millones de años ni siquiera ha logrado ganar el primer premio. Cuando llevaba un número de años similar a la simulación anterior, los resultados eran muy muy parecidos:

Dado que ha tardado más en ganar el primer premio, ¿quiere decir que una apuesta fija tiene una probabilidad más baja de ganar? No, tiene la misma. Dado que solo esperamos a que se gane el primer premio 1 vez (el número de muestras de ese evento es bajo), hay bastante variabilidad acerca del momento en el que se consigue. Sin embargo, si esperáramos a que la simulación gane el primer premio muchas veces, las cifras tenderían a igualarse.

¿Y qué sucede con las apuestas múltiples?

Las apuestas múltiples sí tienen más probabilidad, evidentemente. Por eso cuestan más, mucho más.

El juego de los Euromillones, por ejemplo, permite hacer apuestas en las que no escoges 5 números y 2 estrellas, sino más. Hasta un máximo de 10 números y 5 estrellas. Evidentemente, la probabilidad de ganar con una apuesta así es mucho mayor, teóricamente equivalente a hacer 2520 apuestas sencillas. Por eso, su precio es 2520 veces mayor, nada menos que 6300 € por apuesta múltiple.

Ahora bien, ¿merece la pena? ¿cómo de probable es ganar con una apuesta así de fuerte (y de cara)? Veámoslo:

Como podemos comprobar, el resultado es igual de desalentador. En los primeros 100 años, la inversión en apuestas es de 66 millones de euros, y apenas se ha ganado más de medio millón.

El primer premio de primera categoría se obtiene tras 600 años jugando, y aunque hay varios puntos de la simulación en los que el balance es positivo (a los 1200, 1400, 1700, 2200 y 2700 años jugando) la tendencia a la larga es exactamente la misma. Cuanto más juegas, más pierdes. Así que no, no merece la pena.

Y si es tan improbable, ¿por qué toca tan a menudo? 

Pues porque juega muchísima gente (se prueban muchísimas combinaciones distintas cada día), normalmente entre 20 y 60 millones por sorteo, dependiendo del bote que haya. Así que la probabilidad de que le toque a alguien es razonablemente alta. Pero lamentablemente, la probabilidad de que ese “alguien” seas tú sigue siendo bajísima.

¿Como diseñan estos sorteos?

Está claro que si tocara muy a menudo, el bote no crecería (y no despertaría demasiado interés), y si tocara muy poco, la consecuencia sería la misma (la gente no se interesaría por el sorteo).

Así que si os fijáis, dado que juegan 20-60 millones de personas cada día, y hay un número de combinaciones de 139 millones, el juego está perfectamente diseñado para que toque el gordo cada pocos sorteos. Por supuesto, el azar es el azar, y a veces tarda más, o menos, pero por regla general, la probabilidad se cumple.

¿Realmente se cumplen las probabilidades?

Si, a rajatabla.

Veamos la tabla de probabilidades oficial de los Euromillones:

Fuente: https://www.euro-millions.com/prizes

Si os fijáis en el número de veces que ha tocado cada tipo de premio en el siguiente pantallazo, sacado del final del video:

 En nuestra simulación se han hecho más de 144 millones de sorteos. Veréis que las probabilidades teóricas se cumplen a rajatabla (especialmente en los premios de abajo, con mayor número de muestras):

- El premio 2 + 0 ha tocado 1 vez de cada 21.9 veces

- El premio 2 + 1 ha tocado 1 vez de cada 49.23 veces

- El premio 1 + 2 ha tocado 1 vez de cada 187.9 veces

- El premio 3 + 0 ha tocado 1 vez de cada 313.6 veces

...

Y así sucesivamente. Los números son muy muy aproximados a los de la tabla de arriba, proviniente de la página oficial de los Euromillones.

Eso muestra que mi programa está bien hecho, y que las probabilidades que ofrecen en la web del sorteo son 100% reales. 

Aun así, ya ves que ganar es muy, muy, muy poco probable. Podrías estar mil vidas jugando, y ni aproximarte a ganar...

Suerte!

Azure IoT Device Client SDK v 1.2.0 doesn't work with Xamarin Android apps

Several hours lost trying to deal with a connectivity issue between our Android app and a test Azure IoT server, just to find out that the problem was just having update the Client SDK nuget package (https://github.com/Azure/azure-iot-sdk-csharp)

The SendEventAsync seemed to never finish the task when using MQTT, and it threw an exception when AMQP (something related to Amqp constructor could not intialize the Configuration System).

After several hours assuming it was a fault in my code, or in the Azure setup, I checked the SDK release notes ( https://github.com/Azure/azure-iot-sdk-csharp/releases ), to find that last version was released a few days ago, with a major AMQP redesign.

Downgrading to version 1.19 simply did the trick...

World Enduro Rally

I'm happy to share the result of the work I've been doing in the last months: yesterday, World Enduro Rally came to light.



The game is available for XBoxOne, Steam, Android and Windows. You can get all the details at its Facebook page, or download directly here:

Hope you like it!

Como mejorar tu protección contra ciberataques como WannaCry, en 3 sencillos pasos

Nota: Consejos genéricos para Windows 8 y 10. Podría no aplicar a versiones anteriores de Windows. Esto es solo un consejo que ayuda a mejorar la seguridad, y no garantiza ningún tipo de invulnerabilidad a éste u otro tipo de ataques. El autor de este blog no es experto en seguridad y no ofrece ninguna garantía en absoluto. Use it at your own risk. 

Manually copying Unity's APK and OBB files to an Android device for testing

When developing an Android game that is meant to be published through the PlayStore, there's a limitation regarding the maximum file size of the APK. It currently can't exceed 100 MB.

The thing is that games usually go beyond that limit. To deal with that, Google offers the so called APK Expansion Files. Every application can include up to 2 of them, with a maximum size of 2 GB each.

If your game goes beyond 100 MB, you can easily instruct Unity to split the game in two by checking the "Split Application Binary" in Edit->Project Settings->Player->Android->Publishing Settings.

That will generate two files instead of one:

• APK: the usual APK file with all the binaries, scripts etc, and the first scene included in the build settings (the scene with build index 0). You need to take care that the first scene is small enough so this APK doesn't go beyond 100 MB. In general, this scene is usually just a loading icon, or a game logo that is displayed while loading. 
• OBB: A second Expansion File with the OBB, holding everything else. 

Some time ago, it was necessary to use a Unity plugin to deal with OBB loading, but this is no longer necessary. So, first of all, DO NOT USE that plugin. In fact, it hasn't been updated for years, and won't work in current versions of Unity. 

Current versions of Google PlayStore natively support the distribution of OBB files, so you won't need to do anything special besides providing the OBBs along with the APK when you upload your game.

Note: usually, the first time you upload your game to Google Play, it won't ask you for OBB expansion files (I guess that's a bug in the system). If that's your case, simply generate a second version of your game, and re-upload your APK. Then it will ask for Expansion Files properly. 

How to install the game locally, in a test device? 

In normal circumstances, you  just create one big APK, copy it manually to the SD-Card of your phone, and install the game by tapping on the APK file. If you do that now, the game will install fine but it won't be able to find the Expansion OBB files, so the first scene will load fine, but it will probably get stuck there. 

In order to let the game find the OBB files, you need to:

1.- Rename the OBB so it follows the convention:

Unity creates valid OBB files, but their names don't follow the convention Android expects. Your OBB file should have a name like the following: 

main.[VERSION_NUMBER].[PACKAGE_NAME].obb

Where [VERSION_NUMBER] is the highest digit of the version number you can find in the Player Settings:

And [PACKAGE_NAME] is the package name specified in the same screen, right above the version number:

So, in the example depicted in the images, the name of the OBB file would be:

main.1.com.iayucar.TestGame1.obb

2.- Copy the renamed OBB file to an specific location

The game will expect to find that OBB file in a location like:

[INSTALL_LOCATION]\Android\obb\[PACKAGE_NAME]

Where [PACKAGE_NAME] is the same value described above, and INSTALL_LOCATION refers to whether the game is installed in the internal memory or the external SD-Card (this depends on your own settings). 

As our game is configured to be installed in an external SD-Card preferably, the folder where we need to paste the OBB file is:

\\SDCard\Android\obb\com.iayucar.TestGame1\

And that's it. Now you can launch the game, and it will properly find the additional contents included in the OBB Expansion File. 

Happy 10th Birthday, GraphicDNA !

Last week this blog turned 10!!

Can't believe how fast time goes by.

During this period, I founded my company, I had the honor to be awarded as DirectX MVP (4 years in a row), I became part of Microsoft / RARE team, and then I spent some of the best years I had in the industry, working as Associate Technical Director at Electronic Arts. It's been an amazing adventure being part of the development teams of all these games:

Now that I´m back to teaching, writing, developing and R&D projects, I'm certain that the best is yet to come.

It's been a wonderful time to be a developer all along, so let's see what the next 10 years bring :)

Cheers!

Custom MainLoop in C# / UWP applications with DirectX (SharpDX) with unlocked frame rates (beyond 60 Hz)

When you want to write a game or a 3D application in C# using SharpDX, and you want it to be UWP, there is little information about how to correctly handle the basics of the main loop.

All examples I found were based on the interop between XAML and DirectX, but if you go that path, you´ll need to rely on the CompositingTarget.Rendering event to handle your updates and renders, which lets all the inner processing to Windows.UI.XAML and limits the frame rate to 60 Hz.

So, how to create your own, unlocked-framerate-ready, main loop?

First things first:

Dude, where's my Main entry point?

Typically, a C# application has a Program static class where the "main" entry point is defined.

When you create a WPF, UWP or Windows Store application though, aparently that code is missing, and the application is started magically by the system.

The truth is that the main entry point is hidden in automatically-generated source code files under the obj\platform\debug folder. If you look there for a file called App.g.i.cs, you'll find something like this:

#if !DISABLE_XAML_GENERATED_MAIN
    /// <summary>
    /// Program class
    /// </summary>
    public static class Program
    {
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Windows.UI.Xaml.Build.Tasks"," 14.0.0.0")]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        static void Main(string[] args)
        {
            global::Windows.UI.Xaml.Application.Start((p) => new App());
        }
    }
#endif

Et'voila... There's your entry point.

So first thing is to define the DISABLE_XAML_GENERATED_MAIN conditional compilation symbol to prevent Visual Studio from generating the entry point for you.

Next, is to add your own Program class and main entry points, as always, so you have control on the application start procedure. You can simply copy-paste that code anywhere in your project.

The Main Loop

Please note: this implementation is inspired by the C++ equivalent described here.

Now that you have a main entry point, you can replace the invokation of Windows.UI.Xaml.Application.Start (which internally deals with its own main loop) with your own code.

What we want to use instead is: Windows.ApplicationModel.Core.CoreApplication.Run, which is not bound to XAML and allows you to define your own IFrameworkView class, with your custom Run method.

Something like:

public static class Program
{
    static void Main(string[] args)
    {
        MyApp sample = new MyApp();
        var viewProvider = new ViewProvider(sample);

        Windows.ApplicationModel.Core.CoreApplication.Run(viewProvider);            
    }
}

The ViewProvider class

The main purpose of the view provider is to create a IFrameworkView when required, so it could be something like this:

public class ViewProvider : IFrameworkViewSource
    {
        MyApp mSample;

        public ViewProvider(MyApp pSample)
        {
            mSample = pSample;
        }
        //
        // Summary:
        //     A method that returns a view provider object.
        //
        // Returns:
        //     An object that implements a view provider.
        public IFrameworkView CreateView()
        {
            return new View(mSample);
        }
    }

The View Class

The view class implements the IFrameworkView interface, which defines most of the logic we want to implement.

The framework will invoke interface's methods to perform the initialization, uninitialization, resource loading, etc, and will also report us when the application window changes through the SetWindow method.

For the purpose of this article, the most interesting part is the Run method, which we can write to include our own, shiny, new Main Loop:

public void Run()
{
    var applicationView = ApplicationView.GetForCurrentView();
    applicationView.Title = mApp.Title;

    mApp.Initialize();

    while (!mWindowClosed)
    {
        CoreWindow.GetForCurrentThread().Dispatcher.ProcessEvents(

                                   CoreProcessEventsOption.ProcessAllIfPresent);
        mApp.OnFrameMove();
        mApp.OnRender();
    }

    mApp.Dispose();
}

This removes the need to rely on XAML stuff in your game (and its overhead), gives you more control about how the mainloop behaves, and unleashes the possibility of rendering with a variable frame rate in C#.

Please refer to this page for further info about how to initialize a swap chain suitable for unlocked frame rates.

Hope it helps!

[UWP] Unable to activate Windows Store app - The app didn't start

Today, I've been struggling with a Visual Studio 2015 deploy error for a while.

When trying to debug a C# - UWP application, I kept receiving the following error upon application activation:

Places like this have information about other people finding the same error. Some of them even re-installed Windows 10 from scratch with no luck.

In my case, the cause (and solution) was much simpler than that:

I have my all my projects in an external SSD drive. Yesterday I was working in my laptop, and the last compilation I did there was in Release mode. When I brought the external disk back to my main PC today and tried to deploy directly as Debug, the activation failed for some reason.

So, going back to Release mode, rebuild, launch and let Windows activate the app did the trick. After that, I've been able to go back to Debug mode normally. 

Hope it helps.

Using RacingWheels and other kind of devices in Windows.Gaming.Input

Now that UWP (Universal Windows Platform) is out (and apparently the way to go for video games), a decent Input API was more than needed, to be able to use controllers like racing wheels. And that API is Windows.Gaming.Input.

I already talked about this topic last month, but no matter how hard I tried to make my Logitech G27 be recognized by the API, it simply didn't work. And it was hard to do something wrong in the code, as reading the controller is as simple and straightforward as checking the contents of a collection.

I simply assumed that the API, or the Logitech Driver, or Windows, had problems with certain controllers somehow. And provided that the G27 is a bit old, and that Logitech hasn't updated the drivers since last March, that sounded realistic.

But yesterday, Forza 6 Apex was updated (and taken out of BETA), and finally announced steering wheel support, so I quickly updated it, just to check (to my surprise) that my G27 worked perfectly.

And it's a UWP too, so it was clearly not due to a bug in the API or the driver, but a problem in my application. Provided that the code is so simple, it had to be some configuration issue, and yes, it was...

I checked a thousand times the Capabilities section of the AppxManifest, but I never saw anything that seemed related. But thanks to Mark Thompson (and to the XBox Developer Forums), now I found out what should be added to the AppxManifest in order to make it work.

Simply add the following to the Capabilities section:

 <DeviceCapability Name="humaninterfacedevice">  
     <Device Id="any">  
      <Function Type="usage:0001 0004"/>  
      <Function Type="usage:0001 0005"/>  
     </Device>  
  </DeviceCapability>  

Et voilá. Now the G27 is properly recognized by the app. I still don't understand why this is needed for racing wheel, but not for gamepads.

However, you can find more info here:

• More information about device capabilities in the AppxManifest: https://msdn.microsoft.com/en-us/library/windows/apps/dn263092.aspx
• More information about HID-specific device capabilities: https://msdn.microsoft.com/en-us/library/windows/apps/dn263091.aspx

Microsoft guys told us that this will be added to the docs soon, but for now, it's not there.

Hope it helps!

Quiero trabajar haciendo videojuegos ¿Qué tengo que hacer?

Hace algún tiempo, un buen amigo me pidió si podía asesorar a una alumna suya, que quería orientar su carrera profesional hacia el sector de la creación de Videojuegos. 

Más concretamente, le gustaría trabajar desarrollando software (ingeniería) en alguno de los estudios realmente grandes de la industria (casi siempre situados en el extranjero). 

Dado que es una industria bastante particular y algunos ya hemos pasado por ello unas cuantas veces, me pareció útil publicar aquí la carta que le escribí. Espero que ayude a otros estudiantes que quieran seguir los mismos pasos. 

Ahí va! 

---

Hola XXXXX. Encantado de saludarte.

He escrito el siguiente texto, describiendo todos los aspectos que me parecen relevantes a la hora de acceder a esta industria. Espero que te sirva...

Estudios y formación previa

Sobre departamentos de arte no puedo opinar mucho, pero si lo que te interesa es la parte de ingeniería, lo mejor es estudiar Ingeniería Informática o alguna otra carrera especializada. 

En cuanto a los másters que suelen ofrecer las universidades, cuidado... porque hay de todo. Muy a menudo (y más en este país) la gente que imparte los masters tiene poca (o ninguna) experiencia en estudios de desarrollo reales (y menos aún en estudios de primera fila). Casi toda la experiencia que hay en este país es en estudios muy pequeños, generalmente de desarrollo para móviles. Y aunque puede ser muy buena, hay algunas diferencias entre trabajar ahí, y trabajar en DICE. 

Así que lo que yo te recomendaría, si te decantas por esta opción, es que te fijes no solo en los contenidos que se imparten, sino también en quienes son los profesores del master y si tienen experiencia real en la industria. Eso es lo más importante, porque así no solo aprenderás la parte teórica/práctica, sino también las particularidades que tiene el día a día del trabajo en un estudio (que no son pocas).  

El proceso de selección

Una vez hayas completado tu formación, y quieras aplicar a un trabajo, el proceso de selección en los estudios grandes o TripleA (Visceral, Rockstar, DICE, Ubisoft, Valve, Rare, etc), suele ser como sigue (evidentemente varía en función del puesto, pero suele ser asi):

1.      Filtro inicial: se aplica un filtro de corte y a los que no lo pasan ni siquiera le devuelven el email (si, son así de crueles). Se trata de comprobar algunos requisitos mínimos, que son absolutamente indispensables y normalmente lo hace un empleado de RRHH. Es decir, si no pasas ese filtro, el verdadero reclutador (responsable del departamento que ha abierto la plaza), ni siquiera ve tu candidatura (luego te hablaré más de RRHH):

a.      Nivel de inglés muy alto (indispensable). No importa cómo de bien creas que hablas inglés, cuando llegues a un estudio así, los primeros meses los pasarás fatal en las reuniones (te lo digo por experiencia…). El resto de idiomas que hables, importa más bien poco. Da igual a qué país vayas… Da igual que no hables el idioma local. Vas a trabajar en inglés, y cualquier estudio serio es el único idioma que te va a exigir.

c.      Permiso de trabajo en el país donde está el estudio. Hay muchas ofertas en USA en las que no quieren ni oír hablar de candidatos que no tienen permiso de trabajo allí. Para ellos es un lío gestionar eso, así que es muy frecuente que te rechacen por esto. Empresas grandes como EA o Microsoft sí suelen gestionar el visado, pero aún así es complicado.

2.      Filtro secundario: este ya tiene que ver con necesidades adicionales para el puesto, y dependiendo de casos pueden ser irrenunciables también. En ocasiones, y si el personal de RRHH está especializado, este segundo filtro lo aplican ellos también, por lo que seguirás sin llegar a la persona que sería tu jefe en caso de ser aceptado:

a.      Experiencia en la industria: Esto suele ser muy habitual. A no ser que busquen gente muy muy junior (recién salida de la uni), la experiencia en otros títulos suele ser algo exigido con mucha frecuencia. Y aunque no sea un requisito indispensable, suele ser de las cosas que más valoran. Sobre todo si has estado ya en un estudio considerado “de los grandes”, suele ser de las cosas que más pesan en el CV. Por encima de másters, formación, etc.

b.     Muestras de trabajo: Hoy en día, el CV se utiliza más como un filtro de corte para rechazar candidatos, pero como te decía no es lo más importante a la hora de valorar un candidato. Si pasas el primer corte y, aunque no tengas experiencia, aportas muestras de trabajo (o de proyectos en los que hayas trabajado) que impresionen a los reclutadores, ganarás muchos puntos. Eso si, asegúrate de presentar solo lo verdaderamente bueno. El nivel en los estudios es altísimo, y si presentas algo que les parezca mediocre, puede ser contraproducente.

3.      Entrevistas: Si has pasado los 2 primeros filtros, eso quiere decir que el de RRHH no te ha descartado, y ha hecho que tu candidatura llegue a la persona que realmente ha abierto el puesto. Probablemente la persona que será tu jefe en caso de ser aceptado. Dicha persona puede aplicar su propio filtro y descartar más candidatos, pero si contactan contigo, lo siguiente que querrán será tener una entrevista contigo por Skype. 

Yo he hecho muchas, y me he encontrado de todo. Lo normal es que todo el mundo sea muy amable, pero como te digo, te puedes encontrar de todo. Recuerdo una vez, en una entrevista para Blizzard  (en Los Angeles), el tío fue tan borde que fui yo el que a mitad de la entrevista le corté y le dije que no me interesaba el puesto. 

Deberías haber visto su cara, pero sinceramente, si ya en la entrevista son tan estresantes y bruscos es probable que luego el día a día allí sea un infierno. Nunca se sabe, probablemente el tipo tenía un mal día, pero es un mal modo de empezar, y estudios hay muchos.

Las entrevistas suelen ser varias:

a.      Primera entrevista: en la primera entrevista, probablemente solo querrán conocerte. Ver qué tipo de persona eres. Esta entrevista a veces la hace RRHH también, y va más orientada a asegurarse de que vas a encajar en la filosofía del estudio (que como verás más adelante, suele ser especial de narices).

b.      Segunda entrevista: esta entrevista seguramente será mucho más técnica o enfocada al puesto para el que aplicas, y seguramente la hagas con la persona que sería tu manager si fueras admitida.

c.      Prueba técnica: Es muy frecuente que, después de esta entrevista, te hagan una especie de examen técnico. Suele ser una prueba de programación, que a veces va acompañada de un examen teórico. Y suele ser muy, muy exigente. Lo normal es que la prueba esté a un nivel exigente incluso para ellos, porque una de las cosas que quieren ver es cómo reaccionas ante algo que no sabes resolver. Ahora que soy yo el que prepara los procesos de selección, te aseguro que a veces preguntamos cosas que nosotros mismos tendríamos que consultar.

d.      Entrevista en persona: esto es algo inevitable. Si pasas todos los filtros anteriores, tarde o temprano te querrán ver en persona. Da igual si el estudio está en Inglaterra, Estados Unidos o Australia. Lo normal es que hagan una entrevista personal, y lo normal es que ellos corran con todos los gastos también (viaje, hotel, etc). 

Si todo el mundo pide experiencia en el sector, ¿cómo demonios voy a lograr entrar en el?

Como te decía, lo que más va a pesar una vez pasas el filtro básico, es la experiencia. 

Aquí es donde uno se pregunta lo de siempre… ¿cómo demonios voy a ganar experiencia, si todo el mundo exige experiencia para contratarme? Es un círculo vicioso, si, pero hay formas de poder salir de el.

• Opción 1: tener experiencia en otros sectores que, aunque no sean de videojuegos, pueden ser muy similares. Por ejemplo, el sector de la simulación.
• Opción 2: tener experiencia en estudios mucho más modestos que no suelen ser tan exigentes. El típico ejemplo son los estudios de juegos para móviles pequeños, y de eso hay unos cuantos en España.
• Opción 3: no tener experiencia en estudios, pero haber publicado tus propios juegos a título personal. Hoy en día, en el mercado móvil es muy asequible hacer esto y es una muy buena forma de demostrar lo que sabes
• Opción 4: no tener experiencia alguna, pero deslumbrar con muestras de trabajo de otro tipo. Como te decía, pueden ser un buen sustituto y en temas de programación es fácil demostrar lo que sabes. Proyectos en los que hayas colaborado, tener tu propio blog técnico, proyectos en GitHub o CodePlex, etc. Todo ayuda.
• Opción 5: Internships: Es el equivalente extranjero a los becarios o a las prácticas de empresa, y ahí si que es mucho más fácil que acepten a recién graduados. Y es una experiencia que sirve. Quiero decir, que otros estudios sí lo valorarán a la hora de evaluarte, así que es una forma muy buena de conseguir experiencia.

¿Cuando aplicar?

Si tu objetivo es trabajar en un estudio, empieza a aplicar en cuanto acabes la carrera. Se ambicioso, que nunca se sabe. Tiempo tienes para que te digan que no. Y no te preocupes, que no pasa nada porque no te cojan. 

No vas a entrar en una lista negra en la que ya no volverán a considerarte. Al contrario. Los estudios tienen cierto puntito de “religión” y les suele gustar la perseverancia. Hay mucha pasión en este mundillo, y que les digas que uno de tus sueños era trabajar con ellos, les pone. 

Si ven que has aplicado 4 veces, y que has ido mejorando tu candidatura por el camino, va a ser algo positivo, no negativo.

Y lo que te decía, si consigues entrar, aunque sea como internship, eso va a pesar mucho más en tu CV para futuras aplicaciones que cualquier Máster que hayas podido hacer. Eso si, mientras no consigas entrar en ningún sitio, estudia mucho, haz todos los máster que puedas y prepara un buen portfolio de muestras de trabajo.

Referencias

En esta industria es bastante frecuente que consulten tus referencias. Sobre todo si aportas algo de experiencia en otros estudios, les van a llamar para preguntar por ti. Es algo importante a tener en cuenta. Incluye referencias en tu CV.  

Recursos Humanos

El tema de RRHH merece mención aparte, ya que su comportamiento es muy curioso: el personal de RRHH está centrado en lo suyo. EXCLUSIVAMENTE. A veces, incluso son “contractors”, y van por objetivos. Su trabajo es conseguir candidatos que terminen encajando en el puesto y son evaluados por ello. Punto. 

No es el caso de Electronic Arts (ya que aquí el personal de RRHH es parte de la plantilla fija), pero a veces si pasa en otras empresas grandes como Microsoft, Google, Apple, etc. 

Y cuando eso pasa, la cosa funciona así: algún manager necesita cubrir una vacante, así que informa a RRHH y les pasa una descripción del puesto y de requisitos. A partir de ahí, RRHH toma las riendas de todo, y el reclutador se limita a valorar los candidatos que pasan los primeros filtros.

¿Qué quiere decir todo esto? Pues que aunque parezca sorprendente, a veces RRHH y ese mánager están increíblemente des-alineados. Y lamentablemente, muchas veces la gente de RRHH funciona como comerciales. Si tienes pinta de ser un buen candidato para el puesto, intentan “vendértelo” por todos los medios. 

No es algo que pase en EA, pero en otras empresas si puede suceder. Así que mi consejo: TODO lo que te digan los de RRHH debes contrastarlo con el que vaya a ser tu mánager.

Y otra cosa, los de RRHH son perros viejos. Y como saben de qué va el juego, nunca te van a confirmar nada por escrito. Verás que, aunque tu les mandes un email, ellos te contestan por teléfono la mayoría de las veces. Tienen alergia a dejar las cosas por escrito, así que NUNCA consideres nada como cerrado hasta que no te manden “la carta”. 

Cuando las cosas ya están confirmadas, te mandan una oferta formal por escrito que oficializa todo. En estudios grandes, esto se hace siempre y es una carta en la que se especifican todas las condiciones. Hasta que no te han mandado esa carta, y tu la aceptas oficialmente, no hay nada comprometido. 

Puede que para internships la cosa sea menos formal, pero para puestos fijos (regular, o full-time) es así. 

Regular/Full-time employees

Esto probablemente aplique para cuando tengas más años, pero conviene tenerlo en cuenta: todas estas empresas tienen siempre dos tipos de empleados: permanentes y temporales. Y solo los full-time suelen gozar de todos los beneficios asociados al puesto. A veces, no queda otra que entrar como temporal. Pero ojo, pasar a ser un empleado permanente a veces no es sencillo. Si tienes que escoger entre dos estudios, y en uno eres fijo y en el otro no, tenlo en cuenta. 

Los estudios de desarrollo

Los estudios de desarrollo suelen componerse de artistas (modeladores 3D, sonido, texturas, etc), que suelen ser mayoría en todos los estudios, e ingenieros (que suelen ser un 20-40% del total de empleados). 

Estos últimos, suelen dividirse en los siguientes equipos:

• Tools&Pipelines: creación y mantenimiento de herramientas para la gestión de assets y procedimientos, editores 3D, etc.
• UI: creación y mantenimiento de la tecnología de user interface
• Gameplay: ingenieros que trabajan en la tecnología para gestionar el juego y hacer que sea fluido, divertido, etc.
• Core Tech: Rendering, animation, audio, A.I., Physics
• …

A mucha gente le suele llamar la parte de Core Tech, pero ya te aviso: es donde más bichos raros hay. Gente que duerme en el estudio, y a veces incluso gente que huele mal (literalmente). 

Te vas a encontrar freaks de un nivel que nunca nunca nunca hubieras imaginado. Pero claro, ese nivel de frikismo es por un motivo: CoreTech es lo más complicada de todo y la que requiere más talento. Vas a conocer gente con un talento que te va a dejar alucinado. Literalmente. Y vas a aprender muchísimo. Así que tiene su lado malo y su lado bueno… :)

Las dinámicas de trabajo

En los estudios actuales, normalmente se trabaja siguiendo dinámicas SCRUM. Con equipos no muy grandes en los que un mánager gestiona a su equipo, tanto a nivel personal como profesional. Luego suelen estar los Project o Product Managers, que se encargan de comunicar a unos equipos con otros: transmitir necesidades, priorizar temas, etc. Todo lo que te puedas familiarizar con éstas formas de trabajo, mejor.

El nivel en los estudios

Si eres un buen ingeniero, conviene no asustarse demasiado. En casi todos los estudios están los 3-4 típicos cracks que son DIOS. Las personas a las que todo el mundo pregunta cuando tiene dudas. Y luego hay una masa de ingenieros, que simplemente son muy buenos. Pero no DIOS. :)

Y otra cosa, todo el mundo asume que una persona nueva tiene que aprender. Nadie te va a pedir que llegues y seas productivo el primer día. No agobiarse con eso. 

Solo aprender la terminología y los acrónimos propios del estudio ya te llevará semanas… :)

Tecnología

Hay algunas tecnologías que se han adoptado como estándar en la industria. Por ejemplo Perforce. No es más que un sistema de repositorio y de control de versiones y código fuente, que se usa para almacenar y gestionar el acceso a todo el código de los juegos (y de los assets). Si tienes experiencia con Perforce, mini-punto para ti. :)

En cuanto a herramientas típicas para otras gestiones, tienes Jira, Confluence, DevTrack, etc... Si te suenan, mini-punto para ti... :)

Lenguages de Programación

Normalmente, el lenguaje de programación estándar es C++. 

A no ser que apliques a un estudio exclusivamente móvil, en el que últimamente se ha estandarizado mucho Unity (con C#). Pero si es un estudio que publica para consolas y PC, casi seguro tu lenguaje será C++.

Hay otra excepción: si aplicas a un equipo de Tools&Pipelines, éstos suelen trabajar en C#, por una cuestión de eficiencia y rapidez. Puesto que sus herramientas suelen ser internas y no necesitan ser cross-platform (solo se usan en PC, de forma interna al estudio), casi todos los estudios escogen este lenguaje para esa parte.

Espero que os sirva! 

Steering Wheel Support in Forza Motorsport 6: Apex (and any other UWP application)

Since Turn10 released the Forza Motorsport 6: Apex demo, there has been quite a lot of noise, rumors, and opinions about the lack of support for steering wheels like Logitech G27, G29, Fanatec, and so on.

Sites like this or even the official Forza forums have tough debates about the issue. Some users complain about Microsoft not caring about PC gamers, or even talking about a conspiracy to force us to renew our controllers (or to buy XBox Certified devices). Leaving conspiracies aside, most people wonder why a PC game has no support for steering wheels, when the controller is perfectly detected and configured in Windows.

Truth is there is no conspiracy... The answer is simple: UWP

What is UWP and why should I care? 

UWP stands for Universal Windows Platform.

Apps developed as UWP can run in any device (PCs, XBox, Phones, ...) and can be published in the consolidated Windows Store. You know, the famous convergence:one OS, one Store... So, it has its advantages (big advantages, to be honest).

Why does that affect to Forza? Guess... Forza 6: Apex has been developed as an UWP. Probably as part of a marketing campaign to push the platform forward, or maybe because Turn10 really saw the benefits of UWP. Who knows.

The thing is that UWP-compatible APIs currently offer no single way to do proper controller input, besides Gamepads. And that's probably the main reason why Forza 6 has been released as BETA until now. Because they knew they didn't have a chance to offer support for steering wheels.

See? No conspiracy. It's just a technical limitation.

So, will it be fixed?

Short answer: yes.

Long answer: a bit of history first...

To make your apps compliant with UWP, you cannot use certain old technologies that don't follow some of the current standards. One example of those technologies that are no longer valid is DirectInput.

DirectInput is a quite old piece of technology that hasn't received updates for many many years. And yet it has been the only way to get decent access to certain types of controllers, until now.

Even the Logitech Developer Labs has been using DirectInput to build their SteeringWheel SDK up to date (this screenshot has been taken today):

As a developer that has been working with DirectInput for more than a decade, I have to say that it had its charms: it was extremely open to literally ANY kind of device. But it had its drawbacks too (like a quite difficult learning curve). So I agree it needed a replacement that complies with current development standards.

That's what Microsoft has been trying in the last few years: to find a decent replacement for DirectInput. With no luck, I have to say. They created XInput, which was meant to be that replacement. Or at least that's what they promised, but the truth is that it never received enough attention to become that. It never got any kind of support for game controllers besides Gamepads. So, it never was an option for Joysticks or RacingWheels.

Some time ago, we heard about a new API called Windows.Gaming.Input. And again, it was described as the way to go now.

We (developers) were a bit skeptical about that, because it sounded too familiar after the XInput promises. And things got only worse when we could start testing it out, and again it only offered support for Gamepads.

That has changed now with the release of the Windows 10 Anniversary Update. and the corresponding Windows 10 SDK - build 14393. Both publicly released today.

So, is it fixed yet?

No, but at least the tech bits needed are there.

The Windows.Gaming.Input namespace now includes all the classes necessary to read from a wider selection of devices, including ArcadeSticks, Gamepads, HeadSets and RacingWheels (surprisingly no Joysticks by now).

I´m sure that now that the update has been released, and UWP apps can read from Steering Wheels, Turn10 will release an update to Forza 6 soon. Maybe it even exits the BETA stage, who knows.

What Steering Wheels will Forza Support?

As far as I know, Forza should support the same range of devices supported by the API. And according to the API documentation, the currently supported list of steering wheels is:

Supported Devices

RacingWheel supports any Xbox One certified or Xbox 360 compatible racing wheel without force feedback support.

Force feedback is supported on the following device models:

Manufacturer	Model
Logitech	G25
	G27
	G29
	G920
	MOMO Force Feedback Racing Wheel
Thrustmaster	T300RS
	T500RS
	RGT Force Feedback
	T150
	TX
	TMX
Fanatec	CSR
	HID-mode for the Xbox One

So, the wait should be over soon! 

Be patient, and wait for the Forza update... 

Cheers, 

Cannot find type System.MarshalByRefObject error in UWP app

Playing and learning with UWPs today, I found a strange error when compiling with VS 2015:

Xaml Internal Error error WMC9999: Cannot find type System.MarshalByRefObject

It's a bit misleading, but one can easily see that it's related to DLL references. After dealing with it for a while, I realized some of my Nuget packages were not up to date. Updating them fixed the issue.

More precisely, updating Microsoft.NETCore.UniversalWindowsPlatform to version 5.1.0 fixed the issue.

Hope it helps! 

DirectInput, XInput, Windows.Gaming.Input, y ahora qué? Forza Motor Sport 6

Desde que supe que Forza Motorsport 6 iba a ser una UWP (app universal), y por tanto iba a tener una versión Windows 10, estaba muy expectante para ver qué pasaba con un tema muy concreto: DirectInput. 

Microsoft lleva años dando bandazos con determinadas tecnologías de juegos (todos recordamos el bizarro caso de XNA). Y DirectInput es un caso parecido, aún más extremo si cabe. Para los que no lo sepáis, DirectInput es un módulo dentro de DirectX que se encarga(ba) de acceder a dispositivos como Joysticks, volantes, gamepads, etc.

Cuando salió Windows 8, lanzaron el que (se suponía) iba a ser su sucesor: XInput. Pero inexplicablemetne hicieron una chapuza que solo soportaba gamepads, nada de dispositivos de entrada genéricos ni Force Feedback.

En applicaciones Windows Desktop, uno puede seguir usando la librería, por muy deprecada que esté. De hecho, si vais a la web de Developers de Logitech y os bajáis su SDK, veréis que aún está basado en DirectInput: http://gaming.logitech.com/en-us/developers

El problema, es que las Apps Universales no son aplicaciones desktop, sino aplicaciones del AppStore, y por tanto no pueden referenciar DLLs antiguas. Y ahí está la movida: no existe actualmente un sustituto válido para DirectInput.

Si uno va a la MSDN, para consultar qué tecnologías de juegos pueden usarse en UWP (https://msdn.microsoft.com/en-us/library/windows/apps/mt282476.aspx), verá una sección específica para Input, en la que pone esto:

Hay un API nuevo rondando desde hace tiempo: Windows.Gaming.Input, pero nuevamente no es, ni de lejos, un sustituto a DirectInput. De nuevo, ni Force Feedback ni soporte para dispositivos de entrada genéricos HID. Solo gamepads.

Así que cuando vi que Forza iba a ser una UWP, enseguida me pregunté cómo se lo iban a montar para dar soporte a los volantes y pedales de alta gama que los aficionados a este tipo de juegos suelen tener en casa. Sistemas que, en algunos casos, se acercan a los 1000 euros.

Y hoy que se ha publicado la BETA, se ha desvelado el misterio: no lo hace. No soporta volantes. At all...

Y claro, la gente está que trina... Los comentarios en la appstore son de risa... 

Supongo que en Microsoft estarán trabajando a destajo para convertir Windows.Gaming.Input en lo que siempre debió ser, pero con Microsoft nunca se sabe... :D