Eye in the sky

This week we refactored the flight control system. Heading and velocities are now independent components, allowing us to create entities that rotate and move, like our ship; entities that move but don’t rotate, like… railgun slugs? And entities that rotate but don’t move, like unmanned turrets. We created the later to test our new systems.

They are able to detect nearby targets in range, choose the closest one (AI is just the simplest), set a desired heading so their barrel faces towards the target and rotate:

They don’t shoot, yet. That will depend on the mounted weapon. Firing an energy weapon will require keeping an eye on heat while ballistic/kinetic weapons  require managing ammo and reloading times. We’ll get there.

Fun fact: we can create elite-like gimbal-mounted weapons by simply attaching a turret to our ship and telling what to look for. This one is targeting the planetoid:

mounted turret
R2D2 with a big weapon

 

Furthermore… by separating the current input control system into heading (rotation) and velocity (thrust & strafe) we could easily get manned turrets! And we would be a step closer to this:

Great, kid! Don’t get cocky

 

Across the Universe

Here’s an early prototype of a space flight game we would like to turn into a proper game someday. Plus, it’s also our Christmas and New Year postcard this year! So Happy 2017!

So far we are already able to turn the spaceship with a mouse, accelerate (W), brake (S), strafe left (A) and right (D), fly upwards (Space) and downwards (Left Ctrl) and roll left (Q) and right (E). Yup, it works like a FPS!  We can also shoot our lasers (Left mouse button) and a tractor beam (Right mouse button). We’ll add gamepad control at some point.

Behind the curtains we are also toying with an Entity Component System (ECS) architectural pattern on Unity, and so far we have a good feeling about it. Those gifts swarming around the Christmas tree are nothing but pure data!

Plenty of work ahead and surely lots of fun. And headaches. But that’s what game development is about: solving problems to create fun!

 

Reducing required permissions in Android games (Unity3D)

Two days ago we released Slider for Android devices. First thing you do as soon as your game is available is downloading and installing it, and that’s when we found the following message.

Access to photos/media/files permission

Well, not exactly this one. Our game also asked for WiFi State but we didn’t capture that one.

Ok, WiFi State is not that disturbing. Online leaderboards and Chartboost, the service we use for showing ads, require Internet. Not WiFi, though, 3G is enough. But “This app has access to photos, media or files” is a certainly disturbing warning. With recent events involving photo leaks like The Fappening, users are increasingly more aware of privacy related security. Indeed, when we announced the game in Reddit some users complained about these permissions:

“Looks nice! Why does it need access to my media files and wifi information?”
“Not trying untill dis answered”

Phew!

Slider certainly doesn’t need to access your photos, media or files in any way! What was happening? Well, here’s the answer: Google’s permissions groups! In relation to Photos/Media/Files, Google says:

An app can use files or data stored on your device.
Photos/Media/Files access may include the ability to:

  • Read the contents of your USB storage (example: SD card)
  • Modify or delete the contents of your USB storage
  • Format external storage
  • Mount or unmount external storage

So, that’s it. We commented these two uses-permission lines in the Chartboost Android Manifest (according to their documentation they are just optional, not required)

<uses-permission android:name=”android.permission.ACCESS_WIFI_STATE” />
<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

and also set ‘Write Access” to “Internal Only” in Unity3D’s PlayerSettings. No need to store anything anywhere, anyways.

And that’s it. This is what you get when you try to install Slider now: SLIDER, no permissions required

Way better!

Does your game or app require too many permissions? Take care, it certainly scares users away if they are not required for a good reason!

Ludum Dare 29: Beneath the Surface

LD48 # 29 Beneath the Surface

There are lots of creatures Under the Sea having fun. You know what I mean with fun. As in reproducing. Now Summer is coming and jellies are preparing a new invasion. Help them increase their numbers! Push same-color jellies together, but keep different-color jellies apart, or they’ll fight to death.

Quite a fun idea that unfortunately lacks balance, I fear. Things start slowly and you can tell jellies where to go, avoiding fights and pushing them towards same-color jellies to procreate. When numbers rise and jellies with different colors start colliding, you have to click on them to stop the fight. But with lots of jellies on screen you end up clicking on fights and just letting them look for a mate without help.

It was fun, nevertheless, and I learned a few Unity3D tricks on the way:

a) you can use AnimationCurve as a public parameter in any gameObject, which renders my FreeTweening class useless. Super useful for some tweening!

b) I seriously implemented a finite state machine with coroutines time for the first time in years, following my own tutorial (lol) I added a few ‘life events’ that are used to switch states. Quite useful too.

c) I solved how to handle single events when two entities are involved. In this case, both love-making and fights. The first jellyfish that detects the collision handles it all, telling the other one what to do if both of them want to ‘play’.

Plus, those five hours poured in the animation of the jellyfish. All in all, quite satisfied. I hope you have fun (here’s the entry). Or at least that you find something useful in the source code X)

Hay un montón de criaturas Bajo el Mar divirtiéndose. Y ya sabes lo que quiero decir con ‘divirtiéndose’. En plan reproduciéndose. Y ahora que se acerca el verano las medusas empiezan a preparar una nueva invasión. Ayúdalas a aumentar su población! Une medusas del mismo color pero mantén a la de colores distintos alejadas… o se pelearán a muerte.

Una idea bastante entretenida a la que le hace falta un poco de balanceo, me temo. Las cosas empiezan despacio y puedes decir a las medusas a dónde ir, evitando las peleas y juntando a las del mismo color para procrear. Pero cuando su número aumenta Quite a fun idea that unfortunately lacks balance, I fear. Cuando su número aumenta tienes que hacer click sobre las peleas para separarlas. Pero con un montón de medusas en pantalla las cosas se van de la mano rápidamente y acabas haciendo click sobre las peleas, dejando que ellas encuentren pareja por sí mismas al azar.

En cualquier caso fue divertido, y aprendí un par de trucos de Unity por el camino:

a) se puede usar un AnimationCurve como parámetro público en cualquier GameObject, lo que hace que mi clase FreeTweening sea inútil. Utilísimo para hacer tweening.

b) implementé seriamente una máquina de estados finitos con corrutinas por primera vez en años, siguiendo nuestro propio  tutorial (lol). Añadí un par de ‘eventos de vida’ para controlar el cambio de estados. Bastante útil también.

c) solucioné cómo gestionar eventos únicos en los que están involucradas dos entidades. En este caso, hacer el amor y las peleas. La primera medusa que detecta la colusión se encarga de gestionar el evento, diciéndole a la otra qué hacer si es que ambas tienen ganas de jugar.

Además de las cinco horas invertidas en animar la medusita. En resumen, bastante satisfactorio. Espero que se diviertan (aquí está la entrada). O al menos que encuentren algo útil en el código.