The Story So Far

The inhabitants of Gorgona 6 are a cosmic contradiction: a technologically advanced civilization that is simultaneously kinda backward intellectually! For example, they visited their own moon before figuring out that they should put wheels on luggage and, more importantly for the purposes here, they can build fast, sleek spaceships, but they are wimpy ships that can’t survive much of anything! Just a bump into a space fish is enough to do them in (and being a peaceful people, the Gorgonians never develop weapons of any sort).

Yes, I said space fish! But I digress.

This situation is problematic for them because their star system has a vermin problem: it’s lousy with spaceborne critters and dangers! They have the gargantuan space fish of the third moon of Valtrax, the naturally occurring sentient machine beings of protoplanet 10101110, space aliens (but who doesn’t have space aliens in their solar system, amiright?), and your basic rogue asteroids tumbling about. These things gum up the works of the shipping lanes and pleasure cruise trails (though how anyone can derive pleasure from a cruise where your piece of garbage ship could be destroyed at any moment by the slightest impact is yet another contradiction embodied by the Gorgonians).

Fortunately, there is a solution to these problems: on the outskirts of the solar system is a massive crystal of unknown origin that emits a special type of energy that kills the space vermin, at least for a little while. The Gorgonians have figured out how to collect this energy, little by little. So, they send out ships that are essentially space tankers (but being Gorgonian ships, they at least look cool!) to collect the energy and return it to the homeworld.

Your job, as one of the brave – some might say hero even – pilots of the “crystal tanker fleet,” is to make your way through the space vermin to extract energy from the crystal and then bring it home. When you collect enough energy, the vermin are destroyed, and you’re a Gorgonian hero!

At least for a little while.

You get some points or something for doing this, of course – let’s call ‘em space credits – with which you can maintain your hallucinogenic Gorgonian lizard-licking habit.

And that, friends, is how you conceive a simple game that you can code up with Flutter. I mean, I’ll say up front that if you’re expecting Apex Legends, Halo, or Red Dead Redemption levels of gameplay, then you’re going to be sorely disappointed. This ain’t gonna be no AAA title, and it’s not a game you’ll want to be repeatedly playing (probably – hey, you could wind up loving it I suppose!). But it’ll be a good learning experience, which of course is the goal here.

So, with the story in place, let’s get to work because those vermin aren’t going to destroy themselves (well, probably – they could be as stupid as the Gorgonians I suppose).

The Basic Layout

So, what does this game look like? Well, if you happened to have ever played an old 8-bit game with, say, a frog that hops across lanes of traffic of various types to get to a goal on the other side, well, this game may or may not be conceptually like that. To be more precise, Figure 9-1 shows what it looks like.

Your ship starts at the bottom of the screen, near the homeworld. You control the ship by placing your finger anywhere on the screen, which becomes the “anchor” point, or zero position, of a virtual joystick. Now, just move your finger in any of the eight compass directions, and your ship moves in that direction. Your goal is to move through the lanes of vermin (asteroids, aliens, sentient machines, and space fish, starting from the bottom). When you reach the top, you touch the crystal, and the energy bar at the top fills. Then, you return through the vermin, touch your homeworld, and the energy is transferred, at which point all the vermin explode, you get some points, and the vermin come back so you can do it all over again. Of course, you explode if you touch anything but the crystal or your homeworld.

As I said, it’s not exactly a complex, top-tier game, but it is a game, and it is made with Flutter, so, mission accomplished (unlike all those Gorgonian ship captains lost in the line of duty – we, the Flutter coders of Earth, salute you!)

Directory Structure and Component Source Files

Let’s begin by talking about the directory structure and, more importantly, some of the files it contains. Figure 9-2 shows you the pertinent details. It’s an entirely standard Flutter application structure as you’ve come to know and, I hope, love. In the assets directory , you’ll find a bunch of images and some audio files. For the images, the names should give away what they each are, but the numbers require some explanation.

As you’ll see soon, each of the images represents part of an object in the game which will be used by a common class called, not surprisingly, GameObject . For example, there is a player GameObject for the player’s ship that uses images player-0.png and player-1.png, and a crystal GameObject for the crystal. This common class includes logic for animating these objects. An animation in this context is just like the old trick when you were a kid where you take a notebook; draw a series of “frames,” maybe a stick figure doing jumping jacks; and then flip the pages to produce the animation. Here, each frame of the animation is denoted by the number in the filename. So, for the crystal, there are four frames of animation (four pages in your notebook, so to speak): crystal-0.png, crystal-1.png, crystal-2.png, and crystal-3.png, and the GameObject class knows how to “flip the pages,” if you will.

The MP3 files are audio for various events, the names again hopefully being self-explanatory, but if not, they will be clear when we see them used.

Beyond that, you’ve got a small handful of source files in lib aside from the required main.dart file , and we’ll get to each of those in turn, though like the assets, the names should give you a good clue what they are.

Before any of that though, let’s talk about the pubspec.yaml a bit.

Configuration: pubspec.yaml

This is a game, and most games have audio, so we should probably have some audio too! At the time of this writing, Flutter, perhaps surprisingly, doesn’t have a good API for audio, at least not in the way you need for a game in terms of just being able to play arbitrary sound files included in the project any time you want (and sometimes simultaneously). So, we’ll need a plugin for that. Fortunately, there are a few choices, but perhaps the most popular is the audioplayers plugin ( https://pub.dartlang.org/packages/audioplayers ). This is a fork of an earlier plugin named audioplayer (yes, the new one just has an added s on the end!) that extends the functionality of the old one. This plugin allows us to play audio files stored remotely on the Internet, locally from the user’s device or, critically for us, as assets in our project. With this plugin, you can play files, control their playback (pause, stop, seek to a specific location in the audio), loop the audio if you like (good for background music), and listen for events during playback so you could, for example, show a progress bar if you wanted to.

For FlutterHero, we won’t need most of that! We’ll just need to be able to play our sounds when specific events occur. We’ll look at the API for this plugin when we hit the first sound usage, but as you’ll see, it’s quite minimal.

Aside from that dependency, the assets directory is referenced in the catch-all way you’ve seen previously, so all of our assets are available, image and audio alike. I considered splitting them into assets/images and assets/audio, but that would require a tad more work in terms of getting audioplayers to be able to find them, and given the relatively small number of assets required, I decided to just dump them all in the single assets directory.

The GameObject Class

Now, we start to get to some code! Usually, I would begin with main.dart, but in this case, I want to talk about that GameObject class I mentioned earlier first. Some of what you’ll see here might not immediately be clear, but it will quickly become so when you see this class and its subclasses used.

Speaking of subclasses, that’s right, GameObject is a parent class to two others, as Figure 9-3 shows.

The vermin and player need to be hideable at certain times, and the visible property determines when a game object is visible or not.

Pretty straightforward, right? All the incoming arguments get stored in the appropriate properties, and then we need to load the animation frames. Here, you can see how each is an Image widget, loaded with its asset() constructor and using the baseFilename to construct the filename for each frame to load. This again is primarily done for performance: only loading the frames once is a good idea. Flutter may be smart enough to cache them if we were to load the same image twice, but it’s much better not to assume that and instead architect our app to ensure it – it also makes the animation code easier to write in my opinion.

The logic is simple: every time this is called – which you’ll see later is once per main game loop tick, which means 60 times a second – the frameCount is bumped up. When that value reaches the frameSkip value, then we increment to the next frame. When we reach the end of the frames, we reset it back to the first frame and, if one is supplied, call the animationCallback.

Not to jump the gun, but we’ll be using a Stack widget as the parent to all our game objects. That’s because within a Stack, you can have Positioned widgets which can be positioned absolutely inside the Stack. If the Stack covers the entire screen then, effectively, we’ve got ourselves a canvas perfectly suitable for game development because we can control the precise location of everything on the screen down to the pixel level. That’s exactly what we’re going to do, so draw() needs to return a Positioned widget that wraps the Image widget associated with the current animation frame of the object. In addition, an object can be hidden. How you do this is something you may find a little weird about Flutter. To hide a widget, regardless of what it is, you simply don’t include it in the widget true! There’s no hidden:true or something like that on widgets as seen in many other frameworks, no hide() method to call. However, as you’ll see later, returning null from this method, as would probably be your first thought, wouldn’t work because it would break the widget tree it’ll eventually be a part of. So instead, an empty Container is returned when this game object isn’t visible. That accomplishes the goal, even if in a somewhat weird way (I know it seemed a little weird to me at first at least!)

Extending from GameObject: The Enemy Class

The movement of an enemy is simple though: it just moves either left or right and at a given speed (where speed here means how many pixels it moves per main game loop tick). So, that’s what the speed and moveDirection properties denote. The value of moveDirection will be 0 for left or 1 for right.

Now, since this class extends GameObject, it means that it supports all the same properties as GameObject, so those need to be set too. That’s where the super() call comes into play. As you can see, the signature of the Enemy constructor includes everything the GameObject constructor does plus the items specific to Enemy, so first the super() call sets the properties common to GameObject, then the code inside the Enemy constructor sets the additional properties specified to Enemy.

You can now see why the width and height of the screen are needed: that’s how we know when a given enemy has moved off the screen when it’s moving in either direction. Then, it helps us set its new location. So, to go through this conceptually: a given enemy fish is moving right across the screen (the first if branch). When it’s beyond the right edge of the screen (the second if branch), its x location is set to a negative value, which puts it on the left of the screen. Then it continues moving as before and does this again. For left movement (the else branch), the same is done, but in reverse. That’s all there is to the enemy movements, very simple.

Extending from GameObject: The Player Class

One of the things that makes game development somewhat unique is that you are almost always looking for little tricks to optimize things, to save some memory or cycles here or there. In this case, there are two tricks to be played with the player’s ship. First, the ship should always be pointed in the direction of movement (or remain in whatever position it was going when it last stopped). So, that would mean that we need eight different images: one each for when moving up, down, left, right, up/left, up/right, down/left, and down/right. But, since the ship is animated, and assuming all use two frames, that would mean we need 16 different images! That seems inefficient. So instead, as you saw earlier when we looked at the assets, there’s only two, one for each frame. In order to provide the eight different orientations, those two images will be rotated in real time to the correct orientation. Flutter provides several means to rotate an image, but we’ll get to how to actually rotate the image shortly. Before that, the second trick comes in, and that’s to avoid some calculations. As you’ll see, to rotate the ship, we’ll need to tell Flutter how much to rotate it, and that’s provided in radians. But, from our perspective, we really want to rotate it some number of degrees. So, we could, of course, do a degrees-to-radians calculation every time we need to rotate, but avoiding that calculation saves us some cycles, so that’s what we’ll do! The simplest approach is to just precalculate the radians for each angular degree measure we want to rotate by and store those values in a map for easy lookup, and that’s precisely what the anglesToRadiansConversionTable property is for. The actual number of radians rotated is something we’ll need to keep track of too, and that’s where the radians property comes in. You’ll see both in use very soon.

Since Player extends from GameObject, we need to call the GameObject constructor first, and then set the speed, which is the only value specific to the Player that needs to be set during construction. Note the null as the last argument to the GameObject constructor – that’s the animation callback, which isn’t needed for the player, hence passing null.

A check is performed for each of the four cardinal directions, plus the four combinations, to determine which way the player is moving. Once that’s determined, a lookup into anglesToRadiansConversionTable is done and the resultant radians stored in the radians property. It’s not fancy code, but it gets the job done nicely and, again, all while avoiding a potentially costly mathematical operation here.

This will be called once per main game loop tick. We do horizontal movement direction, and then vertical movement, separately. Recall that there are eight possible directions the player can be moving. The four cardinal directions are handled obviously, but the other four that represents the combinations are also handled by virtue of horizontal and vertical movement being handled separately. Since it’s possible for one of the if statements dealing with x to fire while one of those dealing with y also fires, that yields a combination of vertical and horizontal movement. Of course, we must ensure that the player doesn’t go off the screen too, which is what the bounds checks in each of the if statements do for us. These consider the side of the player as well as the space for the score and energy bar as well.

Where It All Starts: main.dart

The services.dart module is something new. This module provides us some device service access for things like interacting with the clipboard, generating haptic feedback (device shaking), playing system sounds, and selecting text, just to name a few. Something else it lets us do is control the “chrome” that is visible around our app, that is, the system status bar at the top and, on Android at least, the row of soft input buttons at the bottom. If you jump down to the top-level FlutterHero class here, in its build() method, you’ll see a call to SystemChrome.setEnabledSystemUIOverlays(). This is provided by the services module, and this method allows us to pass it an array of chrome identifiers to enable. Here, I specifically enable the SystemUiOverlay.bottom element , which are the soft navigation buttons in Android. Since that’s all that’s in the array, the status bar at the top will be hidden, providing our game a (nearly) full-screen experience.

Of course, before that, you’ll notice that we’re building a stateful widget in GameScreen, which is the home screen defined in the MaterialApp of the FlutterHero class, a pattern you’ve seen before, and the necessary main() method is defined above that.

For this app, we’re not going to use scoped_model and instead just use the basic state facilities that Flutter provides. But, in addition to the State stuff, this class has something new: the TickerProviderStateMixin . We’ll get to what that’s all about in the next section, but just as a preview I’ll tell you that it has to do with the main game loop that will tick by 60 times a second throughout the lifetime of the game.

The build() method begins with a check of the gameLoopController, which you’re going to see is part of the GameCore.dart file. Ignoring for the moment what that is, if it’s null, then a call to firstTimeInitialization() is made, passing it the BuildContext and also a reference to the GameScreenState class itself using this. That function too will be examined in the next section, but I’m sure you can guess from the name that it performs some tasks that happen the first time the build() method executes (remember that build() will fire many times throughout this game). The issue here is that there are some tasks that must be done to set up the game that can only occur when we have that BuildContext. So, those tasks must be done in the build() method. But, they must only happen once, hence why that check of gameLoopController is done.

But like I said, we’ll get to all of that in the next section!

After the background is another Positioned wrapping a Text this time. That’s our score display. As you can see, this widget is placed at x/y location 4/2 as per the left and top properties. That’s the whole point of using a Stack: we can absolutely position these elements as we see fit. The Stack will by default fill its parent, which happens to be the screen, so we have absolute positioning capability across the entire screen. Handy for a game, don’t you think?!

The valueColor property is important here because by default, a progress indicator in Flutter, whether linear or circular, wants to animate. It will spin if it’s circular, or fill up if it’s linear. But, that’s not what we want. We want a bar that fills up little by little when the ship is in contact with the crystal and empties little by little when in contact with the planet to indicate energy filling or draining to and from the ship, all under the control of our code, not what Flutter wants to do with it (waah, this is my game, do it my way, Flutter!). So, rather than specifying just a single color to indicate what color to make the filled portion of the indicator, we instead use an instance of the AlwaysStoppedAnimation widget . This is a special widget that the progress indicator classes know how to deal with that provides an indicator that isn’t constantly animating, precisely as we need! Of course, what color the filled portion should be is still important information, so it’s passed to the AlwaysStoppedAnimation constructor. Note too that the width of the Positioned that the LinearProgressIndicator is in is set dynamically using the width of the screen minus the space the score takes up. This way, the energy bar fills whatever space is left after the score.

The crystal is also added here, which is the last element in the list that’s added during its declaration (inline, if you will).

There’s three of each, so it’s a simple loop – but this loop is the primary reason we needed to build this list in the first place! Trying to do it all inline would have meant having to write out 12 enemy references here since we couldn’t use a loop construct.

It’s important to realize that with a Stack, there is a z-axis at play. That means that elements added later in the list will appear on top of those added before. So, we have to ensure that, to the extent it matters in this game, we add things in the proper order. So, the player must be added after the planet, for example, so that the ship isn’t occluded by the planet when the player flies near it. The ship should remain visible, on top of the planet. Hence it needs to be higher in the z-order and so has to be added after the planet.

Recall that if any given game object isn’t currently visible, its draw() method will return an empty Container. Explosions are when that’s most obvious because while most of the game objects are nearly always visible, explosions are obviously transient in nature. So, this loop may be drawing a bunch of empty Container widgets most of the time, but that’s fine, that’s just the way visibility is controlled in Flutter.

The body of the Scaffold returned isn’t the Stack directly, as you might have anticipated. We’re going to need to work some method for the player to control his ship in, and given that most modern mobile devices are touchscreen-oriented, it makes sense that touch will be our control mechanism. So, we need a widget to recognize touch events, and that’s exactly what the GestureDetector widget is for.

This widget recognizes all sorts of various gestures, taps and such, and one such gesture is a pan. This is simply the user putting their finger down and then moving it around. If you were developing a web site where users use a mouse most of the time, then you would recognize events like mouseDown, mouseMove, and MouseUp. But, we don’t have those here, even though conceptually those are what we need. But, three pan events conceptually mimic those (taking the player’s finger to be basically what the mouse pointer is): onPanStart for mouseDown, onPanUpdate for mouseMove, and onPanEnd for mouseUp. The code that handles those events represents the functionality that the InputController class encapsulates, but we’ll get to that later. Before that though, you can see that the Stack is the child of the GestureDetector, which means that gestures anywhere on the screen will be handled because recall that the Stack takes up the whole screen (it fills its parent by default, as does its parent GestureDetector). Finally, as previously mentioned, the children of the Stack references the list that was built up before here.

Remember that everything we just talked about is inside the build() method of the top-level widget, and remember that we’re dealing with a stateful widget. That means that any time state changes, build() will be called again and the screen re-rendered. That’s the key to making this all work as a game. Next, we need to talk about that main game loop I’ve mentioned several times, as well as the core logic that makes up the game, all of which ties into this build() method because ultimately, all of this logic mutates state and triggers this build() method being executed over and over again to move all our game objects.

The Main Game Loop and Core Game Logic

The core logic of the game is contained within the GameCore.dart file, and it begins, as always, with import:

Checking for Collisions

Most video games require the ability to detect when two objects collide with each other. Here, we need to know when the ship hits any of the vermin. There are several ways to do this, each having their pluses and minuses. One simple approach is called bounding boxes. This method simply checks the four bounds of the objects, and if the corner of one object is within the bounds of the other, then a collision has occurred.

As illustrated in the example in Figure 9-4, each game object has a square/rectangular area around it called its bounding box. This box defines the boundaries of the area the object occupies. Note in the diagram how the upper-left corner of object 2’s bounding box is within the bounding box of object 1. This represents a collision. You can detect a collision by running through a series of simple tests comparing the bounds of each object. If any of the conditions are untrue, then a collision cannot possibly have occurred. For instance, if the bottom of object 1 is above the top of object 2, then there’s no way a collision could have happened. In fact, since you’re dealing with a square or rectangular object, you have only four conditions to check, any one of which being false precludes the possibility of a collision.

This algorithm does not yield perfect results though. For example, you will sometimes see the ship “hitting” an object when it clearly did not really touch. Other times, they may appear just barely to collide, but it won’t register as a collision. The rotation of the ship also plays a role in this because this simple version of the algorithm can’t handle the altered geometry of the ship from something that isn’t (roughly) square and aligned perfectly vertically or horizontally. This could be fixed with a more complex version of the algorithm, or with pixel-level detection, meaning checking each pixel of one object against all the pixels in the other (or at least the pixels on their edges). However, the bounding boxes approach shown here gives an approximation that yields "good enough" results in many cases – the game isn’t unplayable even with this margin of error – so all is right with the world.

With all that explained, let’s see that collision() function that was referenced in the previous section:

bool collision(GameObject inObject) {

  if (!player.visible || !inObject.visible) { return false; }

  num left1 = player.x;

  num right1 = left1 + player.width;

  num top1 = player.y;

  num bottom1 = top1 + player.height;

  num left2 = inObject.x;

  num right2 = left2 + inObject.width;

  num top2 = inObject.y;

  num bottom2 = top2 + inObject.height;

  if (bottom1 < top2) { return false; }

  if (top1 > bottom2) { return false; }

  if (right1 < left2) { return false; }

  return left1 <= right2;

If the player isn’t visible, or if the object we’re checking for collision with isn’t visible, then there’s no need to check for a collision because game objects are only ever not visible when they’re exploding. After that, we calculate the values to be compared, which means the coordinates of the top, bottom, left, and right bounds of the player and the target object. Finally, it’s just the four simple checks described to tell you if a collision has occurred.

Transferring Energy

When the ship “collides” with the crystal or planet, energy must be transferred to or from the ship. The transferEnergy() function is called for that purpose:

void transferEnergy(bool inTouchingCrystal) {

  if (inTouchingCrystal && player.energy < 1) {

If the caller indicates that the crystal is being touched, then we have to ensure that the ship isn’t already full. The values run from 0 to 1 because that’s what the LinearProgressIndicator widget wants for its value range. However, I found that if a check isn’t done to be sure the value never goes over one then the bar “bounces” at the end a little bit, which looks bad.

When the first contact occurs, we need to play the appropriate sound:

    if (player.energy == 0) { audioCache.play("fill.mp3"); }

At the first touch, the energy would be zero, of course, that’s why this condition is checked.

After that, it’s a simple matter of incrementing the energy and capping it at one:

    player.energy = player.energy + .01;

    if (player.energy >= 1) {

      player.energy = 1;

      randomlyPositionObject(crystal);

    }

Also, when the ship is full, the crystal gets randomly repositioned so that the ship is no longer sucking energy (not that it would anyway with the conditions checked for here, but this way it visually isn’t there to be siphoned from).

The else if branch comes next and that’s for contact with the planet:

  } else if (player.energy > 0) {

This only has an effect when the ship has energy onboard of course, so we check for that.

Then, similar to the first contact with the crystal, we want to play a different sound upon the first contact with the planet, so:

    if (player.energy >= 1) {

      audioCache.play("delivery.mp3");

    }

And, as with the crystal, the energy on the ship is adjusted:

    player.energy = player.energy - .01;

Of course, with the energy being adjusted and state being set, the bar will fill or unfill as appropriate, just like we want.

Now, there’s some other logic we need to implement when depositing energy to the planet, and that’s when all the energy is delivered:

    if (player.energy <= 0) {

      player.energy = 0;

      audioCache.play("explosion.mp3");

      score = score + 100;

      for (int i = 0; i < 3; i++) {

        Function callback;

        if (i == 0) {

          callback = () { resetGame(true); };

        }

        fish[i].visible = false;

        GameObject explosion = GameObject(screenWidth,

          screenHeight, "explosion", 50, 50, 5, 4, callback);

        explosion.x = fish[i].x;

        explosion.y = fish[i].y;

        explosions.add(explosion);

        robots[i].visible = false;

      }

    }

Here, we ensure that the energy is at zero, not below, and the explosion sound is played, and the player’s score bumped up. That’s because it’s time to blow up the vermin! The loop executes and for each vermin, it’s hidden, and an explosion shown in its place. Note that the animation callback you saw earlier when looking at the GameObject class now is used: the first (and only the first) vermin has this callback hooked up so that when the animation cycles completes, we can reset the game, including resetting the position of the enemies.

Note

The code you see here for the fish is repeated for the robots, aliens, and asteroids, so I saved a little space by not showing them here.

The result of all of this is shown in Figure 9-5: beautiful vermin carnage!

Of course, they come right back, so it’s a short-lived victory for our hero ☹

Taking Control: InputController.dart

After what I would think are obvious imports, we have three variables. The way the control scheme works is that the player places their finger any where on the screen and that becomes the “anchor point.” Picture a video game joystick in your mind. The center position represents this anchor point. Now, any time the player moves their finger, the new position relative to that anchor point represents movement in that direction. If their finger is, say, 20 pixels above the anchor point, then they want to move the ship up. If they lift their finger and put it somewhere else, then we have a new anchor point. They can, in a sense, create a “virtual joystick” anywhere on the screen that is convenient for them. So, we need two variables to record the X and Y location of the anchor point. We also need to know how many pixels away from the anchor point will register a move, a “sensitivity” setting if you will, and after some experimenting, I landed on 20 being a pretty good value: not too touchy but not too difficult to register a move either.

The task here is simple: record the new anchor point and ensure the player isn’t moving. The object passed into this method is a DragStartDetails object that contains a few pieces of information, most critically to us being globalPosition.dx and globalPosition.dy for the horizontal (x) and vertical (y) position of the drag event.

It may look like a lot of code, but it’s straightforward: if the horizontal location of the drag update event, as indicated by the DragUpdateDetails object’s globalPosition.dx property, is more than 20 pixels to the left of the anchor point, then the player’s moveHorizontal value is -1, and the call to player.orientationChanged() results in the proper rotation being applied. Similarly, if the event happened more than 20 pixels to the right, then the player is moving right (moveHorizontal gets a value of one). If neither of those conditions applies, then there is no horizontal movement (moveHorizontal is set to zero). Then, the same logic is applied for the vertical position but using the inDetails.globalPosition.dy property. The result is the movement control mechanics described, the virtual joystick, so to speak.

All we need to do here is stop any movement that may be occurring, and we have a fully controllable player and a fully playable game thanks to Flutter!

Summary

That’s it! You made it! Three complete Flutter apps, the final one a game! In this chapter, you learned about some new things such as the Positioned widget, Random number generation, handling pan input events, AnimationController, Tween and Animation for performing – after a fashion – animation, and audio. You also, if it was something you hadn’t seen before, learned a little bit about how to architect a game.

It is my sincerest hope that you’ve enjoyed Practical Flutter and that you’ve learned a lot from it. The goal was never to make you an absolute expert in all things Flutter – it’s way too big of a thing for a single book to pull that off! But, if I’ve done my job even close to properly, then you now have a solid foundation on which to build your Flutter knowledge, and with luck, I’ve provided you the necessary building blocks to start creating your own Flutter apps.

So, get to it, start twiddling some bits, go forth and create greatness thanks to Flutter and, in some small part I hope, this book!