Replace quotation marks

getting_started/first_3d_game/01.game_setup.rst

@@ -3,10 +3,10 @@
 Setting up the game area
 ========================
 
-In this first part, we're going to set up the game area. Let’s get started by
+In this first part, we're going to set up the game area. Let's get started by
 importing the start assets and setting up the game scene.
 
-We’ve prepared a Godot project with the 3D models and sounds we’ll use for this
+We've prepared a Godot project with the 3D models and sounds we'll use for this
 tutorial, linked in the index page. If you haven't done so yet, you can download
 the archive here: `Squash the Creeps assets
 <https://github.com/GDQuest/godot-3d-dodge-the-creeps/releases/tag/1.0.0>`__.
@@ -28,7 +28,7 @@ Click *Import & Edit* to open the project in the editor.
 |image3|
 
 The start project contains an icon and two folders: ``art/`` and ``fonts/``.
-There, you will find the art assets and music we’ll use in the game.
+There, you will find the art assets and music we'll use in the game.
 
 |image4|
 
@@ -38,16 +38,16 @@ belong to these models, and a music track.
 Setting up the playable area
 ----------------------------
 
-We’re going to create our main scene with a plain *Node* as its root. In the
-*Scene* dock, click the *Add Node* button represented by a “+” icon in the
-top-left and double-click on *Node*. Name the node “Main”. Alternatively, to add
+We're going to create our main scene with a plain *Node* as its root. In the
+*Scene* dock, click the *Add Node* button represented by a "+" icon in the
+top-left and double-click on *Node*. Name the node "Main". Alternatively, to add
 a node to the scene, you can press Ctrl a (or Cmd a on MacOS).
 
 |image5|
 
 Save the scene as ``Main.tscn`` by pressing Ctrl s (Cmd s on MacOS).
 
-We’ll start by adding a floor that’ll prevent the characters from falling. To
+We'll start by adding a floor that'll prevent the characters from falling. To
 create static colliders like the floor, walls, or ceilings, you can use
 *StaticBody* nodes. They require a *CollisionShape* node as their child to
 define the collision area. With the *Main* node selected, add a *StaticBody*
@@ -55,7 +55,7 @@ node, then a *CollisionShape*. Rename the *StaticBody* as *Ground*.
 
 |image6|
 
-A warning sign next to the *CollisionShape* appears because we haven’t defined
+A warning sign next to the *CollisionShape* appears because we haven't defined
 its shape. If you click the icon, a popup appears to give you more information.
 
 |image7|
@@ -69,8 +69,8 @@ Shape*.
 The box shape is perfect for flat ground and walls. Its thickness makes it
 reliable to block even fast-moving objects.
 
-A box’s wireframe appears in the viewport with three orange dots. You can click
-and drag these to edit the shape’s extents interactively. We can also precisely
+A box's wireframe appears in the viewport with three orange dots. You can click
+and drag these to edit the shape's extents interactively. We can also precisely
 set the size in the inspector. Click on the *BoxShape* to expand the resource.
 Set its *Extents* to ``30`` on the X axis, ``1`` for the Y axis, and ``30`` for
 the Z axis.
@@ -79,7 +79,7 @@ the Z axis.
 
 .. note::
 
-    In 3D, translation and size units are in meters. The box’s total size is
+    In 3D, translation and size units are in meters. The box's total size is
     twice its extents: ``60`` by ``60`` meters on the ground plane and ``2``
     units tall. The ground plane is defined by the X and Z axes, while the Y
     axis represents the height.
@@ -94,7 +94,7 @@ resource to create a visible cube.
 
 |image11|
 
-Once again, it’s too small by default. Click the cube icon to expand the
+Once again, it's too small by default. Click the cube icon to expand the
 resource and set its *Size* to ``60``, ``2`` ``, and ``60``. As the cube
 resource works with a size rather than extents, we need to use these values so
 it matches our collision shape.
@@ -104,9 +104,9 @@ it matches our collision shape.
 You should see a wide grey slab that covers the grid and blue and red axes in
 the viewport.
 
-We’re going to move the ground down so we can see the floor grid. Select the
+We're going to move the ground down so we can see the floor grid. Select the
 *Ground* node, hold the Ctrl key down to turn on grid snapping (Cmd on MacOS),
-and click and drag down on the Y axis. It’s the green arrow in the move gizmo.
+and click and drag down on the Y axis. It's the green arrow in the move gizmo.
 
 |image13|
 
@@ -118,7 +118,7 @@ and click and drag down on the Y axis. It’s the green arrow in the move gizmo.
 |image14|
 
 Move the ground down ``1`` meter. A label in the bottom-left corner of the
-viewport tells you how much you’re translating the node.
+viewport tells you how much you're translating the node.
 
 |image15|
 
@@ -128,9 +128,9 @@ viewport tells you how much you’re translating the node.
     Ensure you move the *Ground* node, **not** the *MeshInstance* or the
     *CollisionShape*.
 
-Let’s add a directional light so our scene isn’t all grey. Select the *Main*
+Let's add a directional light so our scene isn't all grey. Select the *Main*
 node and add a *DirectionalLight* as a child of it. We need to move it and
-rotate it. Move it up by clicking and dragging on the manipulator’s green arrow
+rotate it. Move it up by clicking and dragging on the manipulator's green arrow
 and click and drag on the red arc to rotate it around the X axis, until the
 ground is lit.
 
@@ -142,7 +142,7 @@ At this point, your project should look like this.
 
 |image17|
 
-That’s our starting point. In the next part, we will work on the player scene
+That's our starting point. In the next part, we will work on the player scene
 and base movement.
 
 .. |image1| image:: img/01.game_setup/01.import_button.png

getting_started/first_3d_game/02.player_input.rst

@@ -4,7 +4,7 @@ Player scene and input actions
 ==============================
 
 In the next two lessons, we will design the player scene, register custom input
-actions, and code player movement. By the end, you’ll have a playable character
+actions, and code player movement. By the end, you'll have a playable character
 that moves in eight directions.
 
 .. TODO: add player animated gif?
@@ -18,7 +18,7 @@ Scene*. Create a *KinematicBody* node as the root and name it *Player*.
 Kinematic bodies are complementary to the area and rigid bodies used in the 2D
 game tutorial. Like rigid bodies, they can move and collide with the
 environment, but instead of being controlled by the physics engine, you dictate
-their movement. You will see how we use the node’s unique features when we code
+their movement. You will see how we use the node's unique features when we code
 the jump and squash mechanics.
 
 .. seealso::
@@ -26,7 +26,7 @@ the jump and squash mechanics.
     To learn more about the different physics node types, see the
     :ref:`doc_physics_introduction`.
 
-For now, we’re going to create a basic rig for our character’s 3D model. This
+For now, we're going to create a basic rig for our character's 3D model. This
 will allow us to rotate the model later via code while it plays an animation.
 
 Add a *Spatial* node as a child of *Player* and name it *Pivot*. Then, in the
@@ -43,14 +43,14 @@ This should instantiate the model as a child of *Pivot*. You can rename it to
 .. note::
 
     The ``.glb`` files contain 3D scene data based on the open-source GLTF 2.0
-    specification. They’re a modern and powerful alternative to a proprietary format
+    specification. They're a modern and powerful alternative to a proprietary format
     like FBX, which Godot also supports. To produce these files, we designed the
     model in `Blender 3D <https://www.blender.org/>`__ and exported it to GLTF.
 
 As with all kinds of physics nodes, we need a collision shape for our character
 to collide with the environment. Select the *Player* node again and add a
 *CollisionShape*. In the *Inspector*, assign a *SphereShape* to the *Shape*
-property. The sphere’s wireframe appears below the character.
+property. The sphere's wireframe appears below the character.
 
 |image3|
 
@@ -58,11 +58,11 @@ It will be the shape the physics engine uses to collide with the environment, so
 we want it to better fit the 3D model. Shrink it a bit by dragging the orange
 dot in the viewport. My sphere has a radius of about ``0.8`` meters.
 
-Then, move the shape up so its bottom roughly aligns with the grid’s plane.
+Then, move the shape up so its bottom roughly aligns with the grid's plane.
 
 |image4|
 
-You can toggle the model’s visibility by clicking the eye icon next to the
+You can toggle the model's visibility by clicking the eye icon next to the
 *Character* or the *Pivot* nodes.
 
 |image5|
@@ -75,8 +75,8 @@ some input actions.
 Creating input actions
 ----------------------
 
-To move the character, we will listen to the player’s input, like pressing the
-arrow keys. In Godot, while we could write all the key bindings in code, there’s
+To move the character, we will listen to the player's input, like pressing the
+arrow keys. In Godot, while we could write all the key bindings in code, there's
 a powerful system that allows you to assign a label to a set of keys and
 buttons. This simplifies our scripts and makes them more readable.
 
@@ -92,9 +92,9 @@ can bind keys to these actions.
 |image7|
 
 Godot projects come with some predefined actions designed for user interface
-design, which we could use here. But we’re defining our own to support gamepads.
+design, which we could use here. But we're defining our own to support gamepads.
 
-We’re going to name our actions ``move_left``, ``move_right``, ``move_up``,
+We're going to name our actions ``move_left``, ``move_right``, ``move_up``,
 ``move_down``, and ``jump``.
 
 To add an action, write its name in the bar at the top and press Enter.
@@ -105,7 +105,7 @@ Create the five actions. Your window should have them all listed at the bottom.
 
 |image9|
 
-To bind a key or button to an action, click the “+” button to its right. Do this
+To bind a key or button to an action, click the "+" button to its right. Do this
 for ``move_left`` and in the drop-down menu, click *Key*.
 
 |image10|
@@ -119,7 +119,7 @@ Do the same for the A key.
 
 |image12|
 
-Let’s now add support for a gamepad’s left joystick. Click the “+” button again
+Let's now add support for a gamepad's left joystick. Click the "+" button again
 but this time, select *Joy Axis*.
 
 |image13|
@@ -133,13 +133,13 @@ press the *Add* button.
 |image14|
 
 Do the same for the other input actions. For example, bind the right arrow, D,
-and The left joystick’s right axis to ``move_right``. After binding all keys,
+and The left joystick's right axis to ``move_right``. After binding all keys,
 your interface should look like this.
 
 |image15|
 
-We have the ``jump`` action left to set up. Bind the Space key and the gamepad’s
-A button. To bind a gamepad’s button, select the joy button option in the menu.
+We have the ``jump`` action left to set up. Bind the Space key and the gamepad's
+A button. To bind a gamepad's button, select the joy button option in the menu.
 
 |image16|
 
@@ -151,10 +151,10 @@ Your jump input action should look like this.
 
 |image18|
 
-That’s all the actions we need for this game. You can use this menu to label any
+That's all the actions we need for this game. You can use this menu to label any
 groups of keys and buttons in your projects.
 
-In the next part, we’ll code and test the player’s movement.
+In the next part, we'll code and test the player's movement.
 
 .. |image0| image:: img/02.player_input/01.new_scene.png
 .. |image1| image:: img/02.player_input/02.instantiating_the_model.png

getting_started/first_3d_game/03.player_movement_code.rst

@@ -3,7 +3,7 @@
 Moving the player with code
 ===========================
 
-It’s time to code! We’re going to use the input actions we created in the last
+It's time to code! We're going to use the input actions we created in the last
 part to move the character.
 
 Right-click the *Player* node and select *Attach Script* to add a new script to
@@ -12,8 +12,8 @@ button.
 
 |image0|
 
-Let’s start with the class’s properties. We’re going to define a movement speed,
-a fall acceleration representing gravity, and a velocity we’ll use to move the
+Let's start with the class's properties. We're going to define a movement speed,
+a fall acceleration representing gravity, and a velocity we'll use to move the
 character.
 
 ::
@@ -29,15 +29,15 @@ character.
 
 These are common properties for a moving body. The ``velocity`` is a 3D vector
 combining a speed with a direction. Here, we define it as a property because
-we’re going to build upon its value frame after frame.
+we're going to build upon its value frame after frame.
 
 .. note::
 
     The values are quite different from 2D code because distances are in meters.
     While in 2D, a thousand units (pixels) may only correspond to half of your
-    screen’s width, in 3D, it’s a kilometer.
+    screen's width, in 3D, it's a kilometer.
 
-Let’s code the movement now. We start by calculating the input direction vector
+Let's code the movement now. We start by calculating the input direction vector
 using the global ``Input`` object, in ``_physics_process()``.
 
 ::
@@ -58,9 +58,9 @@ using the global ``Input`` object, in ``_physics_process()``.
        if Input.is_action_pressed("move_up"):
            direction.z -= 1
 
-Here, we’re going to make all calculations using the ``_physics_process()``
+Here, we're going to make all calculations using the ``_physics_process()``
 virtual function. Like ``_process()``, it allows you to update the node every
-frame, but it’s designed specifically for physics-related code like moving a
+frame, but it's designed specifically for physics-related code like moving a
 kinematic or rigid body.
 
 .. seealso::
@@ -70,14 +70,14 @@ kinematic or rigid body.
 
 We start by initializing a ``direction`` variable to ``Vector3.ZERO``. Then, we
 check if the player is pressing one or more of the ``move_*`` inputs and update
-the vector’s ``x`` and ``z`` components accordingly. These correspond to the
-ground plane’s axes.
+the vector's ``x`` and ``z`` components accordingly. These correspond to the
+ground plane's axes.
 
 These four conditions give us eight possibilities and eight possible directions.
 
 In case the player presses, say, both W and D simultaneously, the vector will
 have a length of about ``1.4``. But if they press a single key, it will have a
-length of ``1``. We want the vector’s length to be consistent. To do so, we can
+length of ``1``. We want the vector's length to be consistent. To do so, we can
 call its ``normalize()`` method.
 
 ::
@@ -98,12 +98,12 @@ up direction. In this case, we can use the ``Vector3.UP`` constant.
 
 .. note::
 
-    A node’s local coordinates, like ``translation``, are relative to their
-    parent. Global coordinates are relative to the world’s main axes you can see
+    A node's local coordinates, like ``translation``, are relative to their
+    parent. Global coordinates are relative to the world's main axes you can see
     in the viewport instead.
 
-In 3D, the property that contains a node’s position is ``translation``. By
-adding the ``direction`` to it, we get a position to look at that’s one meter
+In 3D, the property that contains a node's position is ``translation``. By
+adding the ``direction`` to it, we get a position to look at that's one meter
 away from the *Player*.
 
 Then, we update the velocity. We have to calculate the ground velocity and the
@@ -129,14 +129,14 @@ delta time every frame. Notice the use of the ``-=`` operator, which is a
 shorthand for ``variable = variable - ...``.
 
 This line of code will cause our character to fall in every frame. This may seem
-strange if it’s already on the floor. But we have to do this for the character
+strange if it's already on the floor. But we have to do this for the character
 to collide with the ground every.
 
 The physics engine can only detect interactions with walls, the floor, or other
 bodies during a given frame if movement and collisions happen. We will use this
 property later to code the jump.
 
-On the last line, we call ``KinematicBody.move_and_slide()``. It’s a powerful
+On the last line, we call ``KinematicBody.move_and_slide()``. It's a powerful
 method of the ``KinematicBody`` class that allows you to move a character
 smoothly. If it hits a wall midway through a motion, the engine will try to
 smooth it out for you.
@@ -144,11 +144,11 @@ smooth it out for you.
 The function takes two parameters: our velocity and the up direction. It moves
 the character and returns a leftover velocity after applying collisions. When
 hitting the floor or a wall, the function will reduce or reset the speed in that
-direction from you. In our case, storing the function’s returned value prevents
+direction from you. In our case, storing the function's returned value prevents
 the character from accumulating vertical momentum, which could otherwise get so
 big the character would move through the ground slab after a while.
 
-And that’s all the code you need to move the character on the floor.
+And that's all the code you need to move the character on the floor.
 
 Here is the complete ``Player.gd`` code for reference.
 
@@ -185,12 +185,12 @@ Here is the complete ``Player.gd`` code for reference.
        velocity.y -= fall_acceleration * delta
        velocity = move_and_slide(velocity, Vector3.UP)
 
-Testing our player’s movement
+Testing our player's movement
 -----------------------------
 
-We’re going to put our player in the *Main* scene to test it. To do so, we need
-to instantiate the player and then add a camera. Unlike in 2D, in 3D, you won’t
-see anything if your viewport doesn’t have a camera pointing at something.
+We're going to put our player in the *Main* scene to test it. To do so, we need
+to instantiate the player and then add a camera. Unlike in 2D, in 3D, you won't
+see anything if your viewport doesn't have a camera pointing at something.
 
 Save your *Player* scene and open the *Main* scene. You can click on the *Main*
 tab at the top of the editor to do so.
@@ -211,7 +211,7 @@ center of the viewport.
 Adding a camera
 ~~~~~~~~~~~~~~~
 
-Let’s add the camera next. Like we did with our *Player*\ ’s *Pivot*, we’re
+Let's add the camera next. Like we did with our *Player*\ 's *Pivot*, we're
 going to create a basic rig. Right-click on the *Main* node again and select
 *Add Child Node* this time. Create a new *Position3D*, name it *CameraPivot*,
 and add a *Camera* node as a child of it. Your scene tree should look like this.
@@ -223,8 +223,8 @@ Notice the *Preview* checkbox that appears in the top-left when you have the
 
 |image4|
 
-We’re going to use the *Pivot* to rotate the camera as if it was on a crane.
-Let’s first split the 3D view to be able to freely navigate the scene and see
+We're going to use the *Pivot* to rotate the camera as if it was on a crane.
+Let's first split the 3D view to be able to freely navigate the scene and see
 what the camera sees.
 
 In the toolbar right above the viewport, click on *View*, then *2 Viewports*.
@@ -242,8 +242,8 @@ one).
 
 |image7|
 
-Here’s where the magic happens. Select the *CameraPivot* and rotate it ``45``
-degrees around the X axis (using the red circle). You’ll see the camera move as
+Here's where the magic happens. Select the *CameraPivot* and rotate it ``45``
+degrees around the X axis (using the red circle). You'll see the camera move as
 if it was attached to a crane.
 
 |image8|
@@ -254,7 +254,7 @@ character.
 |image9|
 
 We can see some empty space around the character due to the perspective
-projection. In this game, we’re going to use an orthographic projection instead
+projection. In this game, we're going to use an orthographic projection instead
 to better frame the gameplay area and make it easier for the player to read
 distances.
 

getting_started/first_3d_game/04.mob_scene.rst

@@ -113,7 +113,7 @@ the "velocity ".
        move_and_slide(velocity)
 
 Similarly to the player, we move the mob every frame by calling
-``KinematicBody``\ ’s ``move_and_slide()`` method. This time, we don't update
+``KinematicBody``\ 's ``move_and_slide()`` method. This time, we don't update
 the "velocity "every frame: we want the monster to move at a constant speed
 and leave the screen, even if it were to hit an obstacle.
 
@@ -159,7 +159,7 @@ Leaving the screen
 ------------------
 
 We still have to destroy the mobs when they leave the screen. To do so, we'll
-connect our *VisibilityNotifier* node’s ``screen_exited`` signal to the *Mob*.
+connect our *VisibilityNotifier* node's ``screen_exited`` signal to the *Mob*.
 
 Head back to the 3D viewport by clicking on the *3D* label at the top of the
 editor. You can also press F2.

getting_started/first_3d_game/05.spawning_mobs.rst

@@ -3,15 +3,15 @@
 Spawning monsters
 =================
 
-In this part, we’re going to spawn monsters along a path randomly. By the end,
+In this part, we're going to spawn monsters along a path randomly. By the end,
 you will have monsters roaming the game board.
 
 |image0|
 
 Double-click on ``Main.tscn`` in the *FileSystem* dock to open the *Main* scene.
 
-Before drawing the path, we’re going to change the game resolution. Our game has
-a default window size of ``1024x600``. We’re going to set it to ``720x540``, a
+Before drawing the path, we're going to change the game resolution. Our game has
+a default window size of ``1024x600``. We're going to set it to ``720x540``, a
 nice little box.
 
 Go to *Project -> Project Settings*.
@@ -26,16 +26,16 @@ In the left menu, navigate down to *Display -> Window*. On the right, set the
 Creating the spawn path
 -----------------------
 
-Like you did in the 2D game tutorial, you’re going to design a path and use a
+Like you did in the 2D game tutorial, you're going to design a path and use a
 *PathFollow* node to sample random locations on it.
 
-In 3D though, it’s a bit more complicated to draw the path. We want it to be
+In 3D though, it's a bit more complicated to draw the path. We want it to be
 around the game view so monsters appear right outside the screen. But if we draw
-a path, we won’t see it from the camera preview.
+a path, we won't see it from the camera preview.
 
-To find the view’s limits, we can use some placeholder meshes. Your viewport
+To find the view's limits, we can use some placeholder meshes. Your viewport
 should still be split into two parts, with the camera preview at the bottom. If
-that isn’t the case, press Ctrl 2 (Cmd 2 on MacOS) to split the view into two.
+that isn't the case, press Ctrl 2 (Cmd 2 on MacOS) to split the view into two.
 Select the *Camera* node and click the *Preview* checkbox in the bottom
 viewport.
 
@@ -44,8 +44,8 @@ viewport.
 Adding placeholder cylinders
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Let’s add the placeholder meshes. Add a new *Spatial* node as a child of the
-*Main* node and name it *Cylinders*. We’ll use it to group the cylinders. As a
+Let's add the placeholder meshes. Add a new *Spatial* node as a child of the
+*Main* node and name it *Cylinders*. We'll use it to group the cylinders. As a
 child of it, add a *MeshInstance* node.
 
 |image4|
@@ -54,8 +54,8 @@ In the *Inspector*, assign a *CylinderMesh* to the *Mesh* property.
 
 |image5|
 
-Set the top viewport to the top orthogonal view using the menu in the viewport’s
-top-left corner. Alternatively, you can press the keypad’s 7 key.
+Set the top viewport to the top orthogonal view using the menu in the viewport's
+top-left corner. Alternatively, you can press the keypad's 7 key.
 
 |image6|
 
@@ -70,15 +70,15 @@ toggle it by clicking the magnet icon in the toolbar or pressing Y.
 
 |image8|
 
-Place the cylinder so it’s right outside the camera’s view in the top-left
+Place the cylinder so it's right outside the camera's view in the top-left
 corner.
 
 |image9|
 
-We’re going to create copies of the mesh and place them around the game area.
+We're going to create copies of the mesh and place them around the game area.
 Press Ctrl D (Cmd D on MacOS) to duplicate the node. You can also right-click
 the node in the *Scene* dock and select *Duplicate*. Move the copy down along
-the blue Z axis until it’s right outside the camera’s preview.
+the blue Z axis until it's right outside the camera's preview.
 
 Select both cylinders by pressing the Shift key and clicking on the unselected
 one and duplicate them.
@@ -89,10 +89,10 @@ Move them to the right by dragging the red X axis.
 
 |image11|
 
-They’re a bit hard to see in white, aren’t they? Let’s make them stand out by
+They're a bit hard to see in white, aren't they? Let's make them stand out by
 giving them a new material.
 
-In 3D, materials define a surface’s visual properties like its color, how it
+In 3D, materials define a surface's visual properties like its color, how it
 reflects light, and more. We can use them to change the color of a mesh.
 
 We can update all four cylinders at once. Select all the mesh instances in the
@@ -122,7 +122,7 @@ visibility by clicking the eye icon next to *Cylinders*.
 |image15|
 
 Add a *Path* node as a child of *Main*. In the toolbar, four icons appear. Click
-the *Add Point* tool, the icon with the green “+” sign.
+the *Add Point* tool, the icon with the green "+" sign.
 
 |image16|
 
@@ -140,11 +140,11 @@ Your path should look like this.
 
 To sample random positions on it, we need a *PathFollow* node. Add a
 *PathFollow* as a child of the *Path*. Rename the two nodes to *SpawnPath* and
-*SpawnLocation*, respectively. It’s more descriptive of what we’ll use them for.
+*SpawnLocation*, respectively. It's more descriptive of what we'll use them for.
 
 |image19|
 
-With that, we’re ready to code the spawn mechanism.
+With that, we're ready to code the spawn mechanism.
 
 Spawning monsters randomly
 --------------------------
@@ -154,8 +154,8 @@ Right-click on the *Main* node and attach a new script to it.
 We first export a variable to the *Inspector* so that we can assign ``Mob.tscn``
 or any other monster to it.
 
-Then, as we’re going to spawn the monsters procedurally, we want to randomize
-numbers every time we play the game. If we don’t do that, the monsters will
+Then, as we're going to spawn the monsters procedurally, we want to randomize
+numbers every time we play the game. If we don't do that, the monsters will
 always spawn following the same sequence.
 
 ::
@@ -203,14 +203,14 @@ Connect it to the *Main* node.
 This will take you back to the script, with a new empty
 ``_on_MobTimer_timeout()`` function.
 
-Let’s code the mob spawning logic. We’re going to:
+Let's code the mob spawning logic. We're going to:
 
 1. Instantiate the mob scene.
 2. Sample a random position on the spawn path.
-3. Get the player’s position.
+3. Get the player's position.
 4. Add the mob as a child of the *Main* node.
-5. Call the mob’s ``initialize()`` method, passing it the random position and
-   the player’s position.
+5. Call the mob's ``initialize()`` method, passing it the random position and
+   the player's position.
 
 ::
 
@@ -230,7 +230,7 @@ Let’s code the mob spawning logic. We’re going to:
        mob.initialize(mob_spawn_location.translation, player_position)
 
 Above, ``randf()`` produces a random value between ``0`` and ``1``, which is
-what the *PathFollow* node’s ``unit_offset`` expects.
+what the *PathFollow* node's ``unit_offset`` expects.
 
 Here is the complete ``Main.gd`` script so far, for reference.
 
@@ -260,7 +260,7 @@ move in a straight line.
 
 |image25|
 
-For now, they bump and slide against one another when their paths cross. We’ll
+For now, they bump and slide against one another when their paths cross. We'll
 address this in the next part.
 
 .. |image0| image:: img/05.spawning_mobs/01.monsters_path_preview.png

getting_started/first_3d_game/06.jump_and_squash.rst

@@ -3,8 +3,8 @@
 Jumping and squashing monsters
 ==============================
 
-In this part, we’ll add the ability to jump, to squash the monsters. In the next
-lesson, we’ll make the player die when a monster hits them on the ground.
+In this part, we'll add the ability to jump, to squash the monsters. In the next
+lesson, we'll make the player die when a monster hits them on the ground.
 
 First, we have to change a few settings related to physics interactions. Enter
 the world of :ref:`physics layers
@@ -20,7 +20,7 @@ Masks control the layers that a body will listen to and detect. This affects
 collision detection. When you want two bodies to interact, you need at least one
 to have a mask corresponding to the other.
 
-If that’s confusing, don’t worry, we’ll see three examples in a second.
+If that's confusing, don't worry, we'll see three examples in a second.
 
 The important point is that you can use layers and masks to filter physics
 interactions, control performance, and remove the need for extra conditions in
@@ -30,12 +30,12 @@ By default, all physics bodies and areas are set to both layer and mask ``0``.
 This means they all collide with each other.
 
 Physics layers are represented by numbers, but we can give them names to keep
-track of what’s what.
+track of what's what.
 
 Setting layer names
 ~~~~~~~~~~~~~~~~~~~
 
-Let’s give our physics layers a name. Go to *Project -> Project Settings*.
+Let's give our physics layers a name. Go to *Project -> Project Settings*.
 
 |image0|
 
@@ -52,7 +52,7 @@ Assigning layers and masks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the *Main* scene, select the *Ground* node. In the *Inspector*, expand the
-*Collision* section. There, you can see the node’s layers and masks as a grid of
+*Collision* section. There, you can see the node's layers and masks as a grid of
 buttons.
 
 |image2|
@@ -64,11 +64,11 @@ one. Then, toggle off the *Mask* by clicking on it.
 |image3|
 
 As I mentioned above, the *Mask* property allows a node to listen to interaction
-with other physics objects, but we don’t need it to have collisions. The
-*Ground* doesn’t need to listen to anything; it’s just there to prevent
+with other physics objects, but we don't need it to have collisions. The
+*Ground* doesn't need to listen to anything; it's just there to prevent
 creatures from falling.
 
-Note that you can click the “...” button on the right side of the properties to
+Note that you can click the "..." button on the right side of the properties to
 see a list of named checkboxes.
 
 |image4|
@@ -76,34 +76,34 @@ see a list of named checkboxes.
 Next up are the *Player* and the *Mob*. Open ``Player.tscn`` by double-clicking
 the file in the *FileSystem* dock.
 
-Select the *Player* node and set its *Collision -> Mask* to both “enemies” and
-“world”. You can leave the default *Layer* property as the first layer is the
-“player” one.
+Select the *Player* node and set its *Collision -> Mask* to both "enemies" and
+"world". You can leave the default *Layer* property as the first layer is the
+"player" one.
 
 |image5|
 
 Then, open the *Mob* scene by double-clicking on ``Mob.tscn`` and select the
 *Mob* node.
 
-Set its *Collision -> Layer* to “enemies” and its *Collision -> Mask* to both
-“player”.
+Set its *Collision -> Layer* to "enemies" and its *Collision -> Mask* to both
+"player".
 
 |image6|
 
 These settings mean the monsters will move through one another. If you want the
-monsters to collide with and slide against each other, turn on the “enemies”
+monsters to collide with and slide against each other, turn on the "enemies"
 mask.
 
 .. note::
 
-    The mobs don’t need to mask the “world” layer because they only move
-    on the XZ plane. We don’t apply any gravity to them by design.
+    The mobs don't need to mask the "world" layer because they only move
+    on the XZ plane. We don't apply any gravity to them by design.
 
 Jumping
 -------
 
 The jumping mechanic itself requires only two lines of code. Open the *Player*
-script. We need a value to control the jump’s strength and update
+script. We need a value to control the jump's strength and update
 ``_physics_process()`` to code the jump.
 
 After the line that defines ``fall_acceleration``, at the top of the script, add
@@ -129,37 +129,37 @@ called ``move_and_slide()``.
 
        #...
 
-That’s all you need to jump!
+That's all you need to jump!
 
 The ``is_on_floor()`` method is a tool from the ``KinematicBody`` class. It
-returns ``true`` if the body collided with the floor in this frame. That’s why
+returns ``true`` if the body collided with the floor in this frame. That's why
 we apply gravity to the *Player*: so we collide with the floor instead of
 floating over it like the monsters.
 
-If the character is on the floor and the player presses “jump”, we instantly
+If the character is on the floor and the player presses "jump", we instantly
 give them a lot of vertical speed. In games, you really want controls to be
 responsive and giving instant speed boosts like these, while unrealistic, feel
 great.
 
-Notice that the Y axis is positive upwards. That’s unlike 2D, where the Y axis
+Notice that the Y axis is positive upwards. That's unlike 2D, where the Y axis
 is positive downward.
 
 Squashing monsters
 ------------------
 
-Let’s add the squash mechanic next. We’re going to make the character bounce
+Let's add the squash mechanic next. We're going to make the character bounce
 over monsters and kill them at the same time.
 
 We need to detect collisions with a monster and to differentiate them from
-collisions with the floor. To do so, we can use Godot’s :ref:`group
+collisions with the floor. To do so, we can use Godot's :ref:`group
 <doc_groups>` tagging feature.
 
 Open the scene ``Mob.tscn`` again and select the *Mob* node. Go to the *Node*
 dock on the right to see a list of signals. The *Node* dock has two tabs:
-*Signals*, which you’ve already used, and *Groups*, which allows you to assign
+*Signals*, which you've already used, and *Groups*, which allows you to assign
 tags to nodes.
 
-Click on it to reveal a field where you can write a tag name. Enter “mob” in the
+Click on it to reveal a field where you can write a tag name. Enter "mob" in the
 field and click the *Add* button.
 
 |image7|
@@ -178,7 +178,7 @@ Coding the squash mechanic
 Head back to the *Player* script to code the squash and bounce.
 
 At the top of the script, we need another property, ``bounce_impulse``. When
-squashing an enemy, we don’t necessarily want the character to go as high up as
+squashing an enemy, we don't necessarily want the character to go as high up as
 when jumping.
 
 ::
@@ -189,13 +189,13 @@ when jumping.
 
 Then, at the bottom of ``_physics_process()``, add the following loop. With
 ``move_and_slide()``, Godot makes the body move sometimes multiple times in a
-row to smooth out the character’s motion. So we have to loop over all collisions
+row to smooth out the character's motion. So we have to loop over all collisions
 that may have happened.
 
 In every iteration of the loop, we check if we landed on a mob. If so, we kill
 it and bounce.
 
-With this code, if no collisions occurred on a given frame, the loop won’t run.
+With this code, if no collisions occurred on a given frame, the loop won't run.
 
 ::
 
@@ -213,7 +213,7 @@ With this code, if no collisions occurred on a given frame, the loop won’t run
                    mob.squash()
                    velocity.y = bounce_impulse
 
-That’s a lot of new functions. Here’s some more information about them.
+That's a lot of new functions. Here's some more information about them.
 
 The functions ``get_slide_count()`` and ``get_slide_collision()`` both come from
 the :ref:`KinematicBody<class_KinematicBody>` class and are related to
@@ -222,7 +222,7 @@ the :ref:`KinematicBody<class_KinematicBody>` class and are related to
 ``get_slide_collision()`` returns a
 :ref:`KinematicCollision<class_KinematicCollision>` object that holds
 information about where and how the collision occurred. For example, we use its
-``collider`` property to check if we collided with a “mob” by calling
+``collider`` property to check if we collided with a "mob" by calling
 ``is_in_group()`` on it: ``collision.collider.is_in_group("mob")``.
 
 .. note::
@@ -261,9 +261,9 @@ destroy the mob.
 We will use the signal to add points to the score in the next lesson.
 
 With that, you should be able to kill monsters by jumping on them. You can press
-F5 to try the game and set ``Main.tscn`` as your project’s main scene.
+F5 to try the game and set ``Main.tscn`` as your project's main scene.
 
-However, the player won’t die yet. We’ll work on that in the next part.
+However, the player won't die yet. We'll work on that in the next part.
 
 .. |image0| image:: img/06.jump_and_squash/02.project_settings.png
 .. |image1| image:: img/06.jump_and_squash/03.physics_layers.png

getting_started/first_3d_game/index.rst

@@ -7,7 +7,7 @@ project of your own like the animated gif below.
 
 |image0|
 
-The game we’ll code here is similar to :ref:`doc_your_first_game`, with a twist:
+The game we'll code here is similar to :ref:`doc_your_first_game`, with a twist:
 you can now jump and your goal is to squash the creeps. This way, you will both
 **recognize patterns** you learned in the previous tutorial and **build upon
 them** with new code and features.
@@ -26,15 +26,15 @@ You will learn to:
 And more.
 
 This tutorial is for beginners who followed the complete getting started series.
-We’ll start slow with detailed instructions and shorten them as we do similar
-steps. If you’re an experienced programmer, you can browse the complete demo’s
+We'll start slow with detailed instructions and shorten them as we do similar
+steps. If you're an experienced programmer, you can browse the complete demo's
 source code here: `Squash the Creep source code
 <https://github.com/GDQuest/godot-3d-dodge-the-creeps/>`__.
 
 .. note::
 
     You can follow this series without having done the 2D one. However, if
-    you’re new to game development, we recommend you to start with 2D. 3D game
+    you're new to game development, we recommend you to start with 2D. 3D game
     code is always more complex and the 2D series will give you foundations to
     follow along more comfortably.
 
@@ -42,10 +42,10 @@ We prepared some game assets so we can jump straight to the code. You can
 download them here: `Squash the Creeps assets
 <https://github.com/GDQuest/godot-3d-dodge-the-creeps/releases/tag/1.0.0>`__.
 
-We will first work on a basic prototype for the player’s movement. We will then
-add the monsters that we’ll spawn randomly around the screen. After that, we’ll
+We will first work on a basic prototype for the player's movement. We will then
+add the monsters that we'll spawn randomly around the screen. After that, we'll
 implement the jump and squashing mechanic before refining the game with some
-nice animation. We’ll wrap up with the score and the retry screen.
+nice animation. We'll wrap up with the score and the retry screen.
 
 Contents
 --------