DEV Community: Pablo Terradillos

Designing enemies

Pablo Terradillos — Thu, 08 Feb 2024 11:35:00 +0000

In this article, I'm going to share my thinking / design process for the human enemies on the game I'm working on (Vectoria)

I probably need to make another post telling a bit more about the game. For now, you just need to know it is a platformer ambiented on a space cruiser where the main characters uses a jetpack and have a laser gun.

The prototype

To start with, I wanted to be able to have something to test on as quickly as possible. So for the prototype, I just copied most of the main character asset and made the enemy start to shoot as soon as it approaches (ie. enters a collision area)

This was… not very good. The player could just fly and avoid the battle all together.
So I made the enemy a bit smarter: it jumps if detects that the player is not on the floor. Now the battle was not avoidable.

That was it for the prototype really. The simple “AI”[1] allowed me to test it with some friends and see how they react: On most of my tests, they found the battle engaging enough. Although it's worth mentioning none of them replayed the game.

Now on the real game

Out of the prototype, I already knew I wanted my enemies to be smarter and keep iterating on how they behave. So while I would just mimic the same behavior as for the prototype to start with, I made it more modular and simpler to extend and modify utilizing a Finite State Machine (FSM)

The first state (Which I called Idle) was simple: the enemy won´t do anything, just wait for the player to appear.

Once the player approaches the enemy, it will start to shoot every fixed amount of time. This was the “Attack” State.

And, of course, if the player tries to flight over the enemy, it will jump and get back to Attack.

Good, I was back to the prototype state, but now with a simpler way to extend the enemy “cleverness” (The source code for the prototype was a real spaghetti).

Once again I tested it again with some friends…. It was good, most people won’t try to cheat on the very first try, but I want these enemies to be repeated several times, and after the first encounter, most people realized a few simple strategies to just kill them without a problem:

Fly and shoot
Attack from a far distance
Shoot indefinitely

These needs to be fixed, I do want this enemies to be simple enough to not being frustrating (remember there will be a lot of them) but also I don’t want them to be trivial to kill to be boring (and so keep the player in the flow).

To fix fly and shoot, I decided to make a key change that also affects other parts of the game but also makes a lot of sense: If the main character is holding the gun, they can’t manipulate the jetpack at the same time. This also affects the level design (which maybe deserves a different post) opening new possibilities and challenges, so I was happy with it.

For the second issue (Attack from a far distance) I thought of providing some way to deflect the lasers. Adding a shield (or a lightsaber) would probably make the combat a bit more interesting, but don’t align a lot with the plot of the game (again, that's for another post). Also, it would probably complicate things to a whole new level. So I just made the lasers to deflect each other. If a laser enters the player detection area, the enemy will shoot to deflect it. To make things a bit more interesting, the enemy will walk forward to try to see who’s shooting.

Finally, to fix the shoot indefinitely… well, I needed to make it so the player just can’t do it. The gun already has a “pulse the trigger effect” (ie. the player can only fire every 0.5 seconds) but since now the lasers can be used to deflect lasers, you can just hit the trigger like a maniac, and shoots will eventually impact the enemy.
I needed some bullets… but this add more balancing problems: I'd need to make sure the player won’t just deplete their bullets and then not be able to advance the game. Some games fix this by giving you a weaker weapon that you can use indefinitely (like the knife in Resident Evil) or some areas where you can recharge (Like Metroid Dread).
The knife might be good but the gun is also used to open some doors and won’t make a lot of sense to open the doors with a knife.
Recharging areas, on the other hand, requires players to fly away from the combat to get to one of those areas. Given the enemies here are humans it would be unrealistic if they just let you go away… and adding a chase & attack system like in The Last Of Us, would turn this on a completely different game.

Turns out the fix was already there… The jetpack already requires a cooldown period if you try to use it for a long period of time. The laws of energy for this game are already settle so why don’t reuse it for the gun?
That’s it! The gun now has its own energy bar. Same as the jetpack. And given that now you can only use one of the two, makes sense they share the same energy.
This finally makes the combat a bit more interesting… If the player shoots indefinitely, they won’t be vulnerable as they can’t deflect attacks and won’t be able to fly to avoid them as they need the energy to power the backpack as well.

To sum up this combat system: The player has to shoot to attack the enemy and avoid shoots from the enemy.
For the latter they can shoot to deflect the lasers or fly to avoid them. Both actions take energy so they have to be smart enough to make good use of them without running out of energy and left vulnerable to the enemy’s attack.

As a last touch, enemies now can have some personality as they can shoot with different strategies: shoot on different times, only shoot to deflect, jump and move to difficult aiming or any combination of these.

Will I stop there? I don't really know. For a minion like enemy I do think this system is good and fun. I do have in mind a few bosses which will require more tuning, but that's for another round. Now I do have what I need to build a few levels and keep testing.

If you want to talk about Video Game Development and design, reach me out on X at @terradillospab

[1] In the chatGPT era, calling a thing that shoots every certain time and jumps when you jump an AI seems way exaggerated… but it is what it is.

Why I Love Prince Of Persia

Pablo Terradillos — Tue, 03 Aug 2021 01:08:09 +0000

I've always found Prince of Persia a fascinating game. I still play it from start to finish every now and then. If you do the math twice a year ends up adding up.

I refuse to believe that the reason behind this is that it's among the firsts (if not the first) game I have ever played.
I also think a fundamental skill for a game designer is to understand how the games we love have been able to generate the sensations we feel when we play it and, most important, why they are fun.
In this post, I'll analyze this masterpiece, from the point of view of the player and focusing on the sensations it generates without going deep into details.

Disclaimer

The analysis I make here is not free of nostalgia.
While this game has many ports I think the definitive version is the DOS version, using the EGA color mode and the PC internal speakers. The screenshots used on the article came from this version.

Now, let's start.

Story

The plot of the game is extremely simple:

Jaffar, the Sultan's Grand Vizier wants the throne and for that, he needs to marry the Sultan's young daughter. He casts a spell over the princess and she has to marry Jaffar or die. Only "the brave youth she loves" can save her, but he's a prisoner in the castle's dungeons.

And for a good period of my youth, this was basically "save the princess from the evil one". Since rarely I kept all the intro through the end (also, I've been playing this game since before I was able to read and English is not even my mother tongue)

For all it matters, the story gives us purpose: to rescue the princess. But also plays with our anxiety: we know that eventually we will fight Jaffar and get to the princess before the hour runs out.

Both aspects are equally important, exploring the castle is fun, but we also need to be in line with our mission. This tension came into play at different points in the game. Even when this is in most aspects a linear game, you feel all the time that there's a lot to explore. Though most of the time, diverging from the main path will lead you to death ends (though sometimes you'll get rewarded by increasing your max health)

Visuals

We are talking of a game released in 1989 for a machine that was not intended for video games and developed by a small team yet it has its own identity and does a great job setting the atmosphere. The first three levels, the dungeons, makes you feel locked up and afraid. You can feel the darkness and loneliness our young hero might be feeling. Then you discover a much more colorful area, that resembles more the characteristics of the princess's room seen during the intro. This alternation provides a well received freshness just went the visuals might start to feel monotonous.

The character animation requires its own paragraph of course as it feels extremely real (and it is, since it was made from recordings of the author's brother performing the movements) and provides a delightful feedback to the player actions. I always lost a couple of seconds just making the character slide from one side to the other.

Game Mechanics

These are less simpler than the history but not by far if you compare it with most games from today.

You can move left or right either running by default or walking when pressing a key. You can also jump straight or forward and combine the running with the jump.
You also have the combat mode which involves a sword and has a few actions: attack, move right or left, guard or sheath the sword.
Some combats are avoidable if you are clever enough. Well, maybe not too clever, but it's truly rewarding when you make a guard fall into a cliff or get locked behind a door.

Potions deserves a note aside: most of them will just heal you others will damage you and a few will increase your life meter. There are only two of them that have special effects: the one that makes you fall slower and avoid a certain death and the one that inverts the screen and controls.
This is certainly another important aspect of the game: It does not repeat itself, which leads me to the next section.

Music

I've kept music for the last since normally it is something I overlook. But turns out the music in this game (and sound effects in general) are as subtle as any other aspect of the game: There's the main theme, the music for completing a level, the tune played when you die, the one used when you kill a guard and the one played when you drink the fall-slowered potion on level 7.
At any moment the music distracts you as the game doesn't really have a background music. As we discussed for the visuals, the music sets the atmosphere. The absence of music during most of the gameplay adds to the loneliness created by the visuals and helps to empathize with particular events.

There's one particular tune that makes me shiver and it's a great example of this: On level 4, when you find the mirror, you find yourself shocked and intrigued. It's actually scary when you cross it and the shadow guy appears for the first time. After completing the level, you start hearing the classic end level music... but it suddenly gets cut and an upbeat tune is heard, emphasizing the disturbing moment you have just witnessed.

Game events

In every section, we have talked about how each aspect of the games helps to set the tone of the game and how they are wisely used to create an atmosphere or emphasize the Events in the game.
I call Events to those specific moments that appear on each level.

The Events in the game are used as plot devices to move the story forward. Once again, the subtlety on how they are used is the trick here. No Event lasts more than a few seconds and they rarely block the player, they just "happen". If the game was made today, most likely you will get a cut scene for each one of them. Though here you will just continue moving while hearing a particular tone or participating in it.

Each of these Events makes their corresponding level unique. They normally add their own mechanic to the game and are used only once. They surely disrupt you the first time you play the game and make you wonder what's ahead.

Just for reference, let's make a quick summary of them:

Level 1: Get the sword.
Level 2: No events.
Level 3: The Skeleton.
Level 4: The mirror and the shadow.
Level 5: The shadow steals a healing bottle.
Level 6: The Fat Guard and The shadow closes a door making you fall to the dungeons.
Level 7: The floating potion.
Level 8: The passive guard and the mice.
Level 9: The inverse-control potion.
Level 10: No events.
Level 11: The ceiling collapses as you go.
Level 12: Encounter with the shadow.
Level 12+: Fight with Jaffar.
Level 13: Rescue the princess.

Summary

Overall, I think the subtlety each element used in the game is what makes this game a masterpiece. The simple story gives you a purpose, the visuals and the music sets a tone of a thriller that gets you engaged, the mechanics provide the fun and the events make the game to not be repetitive and keep you attached to it until the end.

All things considered, Prince of Persia is a perfect example on how a few elements can be used to create a cohesive experience that, wisely used, provides a simple linear game yet with a lot of re playable value.

If you want to talk about game development, game design or just games in general, please reach me out to @tehsis on Twitter.
For more game development content, follow @alidionstudios so you don't miss out our next publication.

Now, I'll type the magic words, and play some PoP.

C:\> prince ega

Day 1: Planning Ahead

Pablo Terradillos — Sun, 01 Aug 2021 22:08:15 +0000

This is going to be a simple development blog for a game I'm working on.

I'd like to write about the experience but also I don't want to expend a lot of time here and rather be building the real thing.

The game will be some sort of tribute to the original Prince of Persia, for that, I've made an analysis of the game in another blogpost.

The first thing I've built is a prototype. I've used that to learn the basis of Unity and also test the mechanics I plan for the game.
First thing is that I want the game to be fun from the moment it starts. I've slightly based on HERO

I've started with a GDD with a format extracted from Level UP!.
I'll make it public eventually though is nothing complicated, if you want to take a look at it, just let me know.

To summarize, Vectoria: Savior,

Will have 12 levels
Is expected to be ready in 3 months

The prototype of the game can be found here: https://tehsis.itch.io/vectoria

There are a couple of decisions I have already made for the game and won't talk about them right now. For example, I'll be using Unity for the game. Mostly because of the community I have access to.

So, where to go now? I think I have enough elements to build the real thing. Most of the prototype is just throw away code which helped me to get familiarized with Unity and C#.

The elements I need to build to support the game are:

Game mechanics:
- Jetpack
- Gun
- Bombs
- breakable doors
- Floor on fire
Level editor

For each item of the game mechanic I have a description on the GDD, the level editor is something I need to put all elements together. I know there're several plugins on Unity for that so I need to evaluate wether to build one or buy one.
I'll evaluate both options... mostly because the nerd in me tells me to build one.

From React to SwiftUI

Pablo Terradillos — Wed, 16 Dec 2020 13:01:28 +0000

Some time ago, I've started working on TaskMeUp for which I wanted to provide a native experience beyond a web one.

I considered lucky that just one year ago, Apple announced SwiftUI, a framework which, on Apple words:

provides views, controls, and layout structures for declaring your app’s user interface.

Something that might sound similar for those of us comming from the web world, since it's quite similar to React (and some other tools and frameworks, of course)

Truth is that SwiftUI takes a lot of inspiration from React and it's quite similar, though adapted to Apple ecosystem and offering an experience similar to what on the web frontend world would be React + (Mobx)[https://mobx.js.org/README.html] + Storybook + some design system (Apple's own on this case).

Starting with SwiftUI

To start working with SwiftUI we need macOS (on the contrary of the web, Apple's ecosystem is not open)

We open up Xcode
Select "Create new Xcode project"
Choose iOS -> App
We fill in some data, and quite important, select "User interface: SwiftUI"

Xcode will then initialize the project and we will see on its main screen a few files already created. By default, we will have open "ContentView.swift", our first SwiftUI view

import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

We can already compile this and run (cmd + r) on a simulator or even on an device (either iOS, iPadOS or macOS). We can also see to the right or the bottom of the editor (depending on our preferences) a preview of our application/view (most likely you will need to click on "resume" for something to happen, this preview stops working with ease).
Let's take a look at what's going on here:

The first line import SwiftUI is clear, we import that framework (Apple's calls frameworks to all its libraries), bringing to our context all of the names and symbols declared there.

Right after it we see a struct named ContentView which implements a protocol named View

protocols, classes, structs, references, etc

Let's start from the simplest one: a protocol is similar to what in Typescript or Java is called an interface. That is to say, a contract, we are stating our struct will have a set of specific attributes and/or methods. You can't declare types on javascript so there's not an equivalent for this other than documenting (or doing a runtime check) what properties or methods an specific object will have.
By saying that ContentView implements the View protocol, we can use ContentView anywhere a View is expected.

Let's move on to the struct: This is similar to a class in Javascript and an instance of this struct is similar to an object. There's one caveat though: on Swift, structs instances will be always passed as values

What does that means? If we pass our object, via a function call or an assigment, this object will be copied and the function or the new symbol will get a copy of it.
On Javascript, objects are always passed by reference, that means that what we pass is actually a pointer to the memory space that holds the object and not the object itself.

let's take a look

On Javascript,

let user = {
  name: "Pablo"
}

let anotherUser = user

anotherUser.name = "Emiliano"

console.log(user.name) // "Emiliano"
console.log(anotherUser.name) // "Emiliano"

On Swift,


struct User { 
  var name: String
}

var user = User(name: "Pablo")
var anotherUser = user
anotherUser.name = "Emiliano"

print(user.name) // "Pablo"
print(anotherUser.name) // "Emiliano"

While it's not present on the code we are analizing, Swift provides class, which we can say is similar to a struct which values are passed by reference (on the same way than Javascript).
The syntax is quite similar than the previous example,

class User {
  public var name: String

    init(name: String) {
        self.name = name
    }
}

var user = User(name: "Pablo")
var anotherUser = user
anotherUser.name = "Emiliano"

print(user.name) // "Emiliano"
print(anotherUser.name) // "Emiliano"

You can also notice that I had to make two changes: specify the name attribute as public (by default on classes these are private) and define a constructor (yes, init method is to Swift's classes what construct is on Javascript ones)

Let's get back to the initial SwiftUI code. As a sole property of this struct we have body. On this case, the ":" (from var body: some View) are telling us that body conforms to... some view.
We can read this literally, body is some view, we don't care which one.
Once again this is something that won't have a purpose on javascript or any other not strongly typed language, though a valid question is "what's the different between some View and just View if in both cases View is a protocol?
Well, some View is more similar to a generic type. By specyfing some View we are stating that this variable is of an specific View type, not just any View.

For example, the following example will throw an error

protocol Greeter {
    func greet() -> String
}

class Person: Greeter {
    func greet() -> String {
        return "Hello"
    }
}


class User: Greeter {
    func greet() -> String {
        return "Howdy!"
    }
}

// This function is invalid
func test(a: Int) -> some Greeter {
    if a > 5 {
        return User()
    }

    return Person()
}

Here test is trying to return either an User or a Person, both of them implementsGreeterthough by specifiend thattestreturnssome Greeterwe are saying that it returns an specific type and on our example it can be anUseror aPerson, not both. If we clear the wordsome`, the example will compile successfully.

Computed properties

body has more secrets, it immediately opens a curly braces that surrounds a piece of code.
This is known as Computed Properties, which is equivalent to getter and setters methods of javascript.
On this case, since we are not specifying how to assign a new value to body, it's a getter.

`
struct Person {
var name: String
var yearOfBirth: Int

var age: Int {
    2020 - yearOfBirth
}

}

var p = Person(name: "Pablo", yearOfBirth: 1987)

print(p.age) // 33

What's inside the curly braces is just a function. Swift loves to eliminate redundant code, that's why on single line functions, the result of that line is returned (when you have more lines, you'll need to add return 2020 - yearOfBirth)

Last but not least (finally!), body returns Text("Hello world"). If we do "option + click" on Text, we will see that this is a struct that implements View (which was expected since we are declaring that body will return some View)

Views and Components

We can say that Text("Hello world") is a component, like React components. SwiftUI knows exactly how to show it, with which style and on what position (even considering if it's running on an iPhone, Apple Watch, Apple TV, etc).
SwifUI provides of course a lot of components and we can also define our owns. Actually on this example, ContentView is a component just like Text is.

For example, let's surround our Hello World on a List component

`swift
struct ContentView: View {
var body: some View {
List {
Text("Hello, World!")
}
}
}

`
And we can see how our application has changed.

We can also make our Text clickable/tapable using a Button

swift struct ContentView: View { var body: some View { List { Button(action: { print("Hi") }) { Text("Hello, world!") } } } }
Now everyime we click (or tap) our text, we will see "Hi!" on Xcode debug console.

Worth noticing that all views has methods to change their styling. Eg. we can do Text(...).fontWeight(.bold) to show that text in bold.

Extra

parameters labels

As you might have seen, when calling a function in Swift, parameters also indicates its names. Swift allow us to define labels on the parameters ans even define different names for the implemenation and the calling:

`swift
getAvatar(for: "Pablo")

func getAvatar(for user: String) {
// ...
// user -> "Pablo"
}

I can omit the for label and use it as getAvatar(user: "Pablo") or just use an _ to completely omit the name, but it won't read as good.

Functions as last parameter

I'm not exactly sure how this is called, though something that originally confused me on swift, are cases like the one we have in Button above

swift Button(action: { print("Hi!") }) { Text("Hello, World!") }

Like Javascript, Swift can use functions as first class citizens, pass them as values and therefore our functions can accept them as parameters. What's courious is that when the function is also the last argument of the function, you can completely omit the label and write the function outside of the parenthesis:

`swift
func doSomething(value: Int, method: (Int) -> ()) {
method(value)
}

doSomething(value: 5) { val in
print(val) // 5
}
`

We can also be explicit of course

swift doSomething(value: 5, method: { val in print(val) // 5 })

Final thoughts

SwiftUI has a similar premise than React: Our view is a function of our state and views are composed from other views.
Much of the mindset you used on React can be used on SwiftUI as well.
Xcode also provides a lot of guidelines to help us writing our code as well.

Also, SwiftUI makes it easier to follow Apple conventions and write a decent looking UI that adapts to the system (ie. font changes, dark mode, etc) with almost 0 effort from our side.
The major caveat at this point is that the whole platform is not stable as we would like. On each new OS version (or even Xcode versions) things might breaks on mysterious ways or just behave differently, so I think that while is not strictly required, a deeper understanding of the Apple's previous UI framework UIkit is still valuable when working on mid to large sized apps.

If you have reached this far and you are interested on learning about Swift or SwiftUI, these are some great resources:

100 days of SwiftUI by Paul Hudson
Standford CS193p classes on SwiftUI
Apple's introduction to SwiftUI on WWDC 2019
Apple's tutorials on SwiftUI

If you are interested on Software engineering and the web, you can reach me on twitter as @tehsis

Sobre-analizando el hello world de SwiftUI, desde javascript

Pablo Terradillos — Tue, 04 Aug 2020 13:47:34 +0000

Hace unos días comencé a trabajar en un proyecto personal que, por motivos que comentare en otro post, espero, decidí desarrollarlo de forma nativa para iOS (ademas de su versión web, claro)

Por suerte para mí, en 2019, Apple anuncio SwiftUI, un framework que, en palabras de Apple:

"Ofrece vistas, controles y estructuras de diseño para declarar la interface de tus applicaciones".

Una definición, que para los que venimos del mundo web, nos puede sonar a la de React (y bueno, de varios otros frameworks tambien).

Lo cierto es que SwiftUI toma mucho de React y, en esencia, es muy parecido. Claro que, adaptado al ecosistema Apple y ofreciendo una experiencia muy similar a lo que, en el mundo web frontend, seria similar a usar React + Mobx + Storybook + algun "design system" (en este caso, el design system de Apple).

Comenzando

Comenzar con SwiftUI es bastante simple (obviamente, es requerimiento contar con macOS, a diferencia de la web, el ecosistema de Apple no esta pensado para ser abierto):

Abrimos Xcode
Seleccionamos "Create a new Xcode project" / "Crear nuevo proyecto de Xcode"
Elegimos como template "Single View App"
Llenamos un par de datos y, muy importante, seleccionamos "User Interface: SwiftUI"

Xcode inicializa el proyecto y vemos su pantalla principal y varios archivos creados. Por defecto, tendremos abierto "ContentView.swift", nuestra primera vista de SwiftUI.

import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

Esto ya podemos compilarlo y correrlo en un simulador o incluso en un dispositivo iOS/iPadOS/macOS. Ademas veremos a la derecha o debajo del editor, dependiendo del tamaño de la ventana, un preview de nuestra aplicación/vista (seguramente haya que hacer click en "resume" para comenzar a ver algo)
Pero veamos un poco que esta pasando acá.

La primer linea import SwiftUI es bastante clara, incluye dicha librería/framework.

Luego vemos un struct llamado ContentView que implementa un protocol de nombre View:

protocolos, clases estructuras, referencias, etc

Vamos por lo más sencillo: un protocol es, ni más ni menos, lo que en Typescript o Java es una interface. Es decir, un contrato, estamos diciendo que nuestra struct tiene una serie de atributos específicos. Javascript no posee tipos, por tanto no tenemos un equivalente directo más allá de usar un objeto y "confiar" (o chequearlo en runtime) que tendrá un determinado método o propiedad.

Sigamos por el struct: Esto equivale a una class en Javascript y una instancia de este struct equivaldría a un objeto. Pero hay una pequeña trampa.
En Swift las instancias de structs Siempre se pasan por valor.

¿Que quiere decir eso? que si pasamos nuestro objeto, mediante una llamada a una función o una asignación, este objeto se copiará y la función recibirá una nueva copia del mismo.
En Javascript, los objetos siempre se pasan por referencia, es decir, lo que pasamos en realidad es un puntero al espacio de memoria del objeto y no el objeto en sí.

Veamos:

let user = {
  name: "Pablo"
}

let anotherUser = user

anotherUser.name = "Juan"

console.log(user.name) // "Juan"
console.log(anotherUser.name) // "Juan"

Mientras que en Swift:

struct User {
  var name: String
}

var user = User(name: "Pablo")
var anotherUser = user
anotherUser.name = "Juan"

print(user.name) // "Pablo"
print(anotherUser.name) // "Juan"

Si bien no esta presente en el código que estamos analizando, Swift posee class, que podriamos decir es lo mismo que un struct pero cuyos valores son pasados por referencia (sí, de la misma forma que ocurre en Javascript). La sintaxis es prácticamente la misma y el ejemplo anterior podemos verlo simplemente reemplazando struct por class.

class User {
  public var name: String

    init(name: String) {
        self.name = name
    }
}

var user = User(name: "Pablo")
var anotherUser = user
anotherUser.name = "Juan"

print(user.name) // "Juan"
print(anotherUser.name) // "Juan"

Como puede verse, también tuve que hacer dos cosas: especificar que el atributo name es publico (en las clases por defecto son privados) y definir un constructor (sí, el metodo init es similar al construct de las class de Javascript).

Pero volvamos al código inicial de SwiftUI. Como unica propiedad de este struct, tenemos a body. En este caso, los ":" (de var body: some view) nos indica el tipo de body... some View.
Esto podríamos leerlo literalmente: body es "alguna" View, no importa cual.
Nuevamente, en Javascript no tenemos nada parecido, porque no tenemos tipos. Pero pensando en Typescript o Java, podriamos preguntarnos: ¿Cual es la diferencia entre some View o directamente View siendo que View es un protocol?
La respuesta, es que some View es más similar a un tipo genérico (o generics). Al especificar some View estamos diciendo que esa variable es de un tipo especifico de View, no cualquier View.

Por ejemplo, el siguiente ejemplo es invalido:


protocol Greeter {
    func greet() -> String
}

class Person: Greeter {
    func greet() -> String {
        return "Hello"
    }
}


class User: Greeter {
    func greet() -> String {
        return "Howdy!"
    }
}

func test(a: Int) -> some Greeter {
    if a > 5 {
        return User()
    }

    return Person()
}

En este caso, test intenta retornar un User o un Person, ambos implementan Greeter, pero al especificar que test retorna some Greeter, estamos diciendo que retorna un tipo especifico (en el ejemplo, podría ser un User o un Person, pero no ambos.
Si borramos la palabra some, el ejemplo compila correctamente.

Computed properties

Pero body sigue sorprendiendo, ya que directamente abre una llave que encierra un bloque de código.
Esto es lo que Swift llama "Computed properties", equivalentes a los getter y setters de Javascript. En este caso, al no especificar como asignar un nuevo valor a body, es simplemente un getter.

struct Person {
    var name: String
    var yearOfBirth: Int

    var age: Int {
        2020 - yearOfBirth
    }
}

var p = Person(name: "Pablo", yearOfBirth: 1987)

print(p.age) // 33

Lo que esta dentro de las llaves es simplemente una función. A Swift le encanta eliminar código redundante, por lo que en funciones de una sola linea, el resultado de dicha expresión es retornado (si hubiese más lineas, debería poner return 2020 - yearOfBirth).

Por último (¡al fin!), body retorna Text("Hello world"). Si hacemos "option + click" en Text, veremos que es una struct que implementa View (como era de esperarse dado que body es de tipo some View).

Views y Components

Podríamos decir que Text("Hello world") es un componente, como los componentes de React. SwiftUI sabe exactamente como mostrarlo, con que estilo y en que posición. De igual forma, existen varios componentes con distintos fines. Por ejemplo, encerremos nuestro Hello World en un List

struct ContentView: View {
    var body: some View {
        List {
            Text("Hello, World!")
        }
    }
}

y veremos como cambió nuestra aplicación.
También podríamos hacer nuestro Texto "clickeable" usando un Button.

struct ContentView: View {
    var body: some View {
        List {
            Button(action: {
                print("Hi!")
            }) {
                Text("Hello, World!")
            }
        }
    }
}

Ahora, cada vez que clickeemos (o tapeemos) nuestro texto, veremos "Hi!" en la consola de debug.

Casi todas las vistas tienen métodos para cambiar sus estilos. Por ejemplo, podemos hacer Text(...).fontWeight(.bold) para mostrar el texto en negrita.

Curiosidades varias

Etiquetas de parametros

Como habrás visto, al llamar una función en Swift, los parámetros indican el nombre. Swift permite definir etiquetas a los parámetros e incluso definir nombres distintos para la llamada y la implementación:

getAvatar(for: "Pablo")

func getAvatar(for user: String) {
  // ...
  // user -> "Pablo"
}

Si en la definición omito el for, tendria que llamar getAvatar(user: "Pablo").

Funciones como último parametro

No se exactamente como se llama esto, pero algo curioso de Swift y que hizo que inicialmente me cueste leer el código, es el caso de Button más arriba:

  Button(action: {
    print("Hi!")
   }) {
     Text("Hello, World!")
    }

¿Que es exactamente lo que rodea a Text?

Al igual que en javascript, Swift permite pasar funciones como valores y por tanto nuestras funciones pueden aceptar funciones como parámetros. Lo curioso, es que en aquellos casos que el último parámetro de la función sea otra función, podemos usar las llaves por fuera del paréntesis.

Como siempre, mejor un ejemplo:

func doSomething(value: Int, method: (Int) -> ()) {
  method(value)
}

doSomething(value: 5) { val in
  print(val) // 5
}

Tambien podriamos llamar a doSomething siendo explicitos:

doSomething(value: 5, method: { val in
  print(val) // 5
})

Conclusión

SwiftUI parte de una premisa muy similar a la de React: nuestra vista es una función de nuestro estado y las vistas se componen de otras vistas (De igual manera que los componentes se componen de otros componentes). Hacer una transición podría decirse que es relativamente sencilla y podemos re-usar mucho de dicho mundo.
Ademas, Xcode nos dara la suficiente ayuda para entender fácilmente que Views y que modificadores tenemos disponibles para armar nuestra aplicación. (cuando no falla, hay que decirlo).

Si llegaste hasta acá, te recomiendo que mires la introducción oficial de Apple a SwiftUI que seguramente es mucho más clara y extensa que este articulo: https://developer.apple.com/videos/play/wwdc2019/216/

Más adelante veremos como manejar estado dentro de SwiftUI usando el framework "Combine" de Apple (que, siguiendo con analogías, podríamos decir es similar a Mobx)

Si te interesa el desarrollo web y/o apps, ¡hablemos! Podes seguirme en twitter como @tehsis