diff options
Diffstat (limited to 'teaching/gameofcode')
11 files changed, 0 insertions, 3291 deletions
diff --git a/teaching/gameofcode/01-libgdx-game-of-codes-the-setup-basics.md b/teaching/gameofcode/01-libgdx-game-of-codes-the-setup-basics.md deleted file mode 100755 index c43613f..0000000 --- a/teaching/gameofcode/01-libgdx-game-of-codes-the-setup-basics.md +++ /dev/null @@ -1,365 +0,0 @@ -Title: 01. (LibGDX) Game of Codes: The Setup & Basics -Category: Game of Codes -Tags: Guides -Slug: 01-libgdx-game-of-codes-the-setup-basics -Status: published - -Hey everybody and welcome to a new/ old series on this blog about LibGDX. - -LibGDX is a Java game development framework based on LWJGL and OpenGL which makes it relatively easy to make a game from scratch without requiring a big engine. It supports Desktop, Android, iOS and HTML as export targets which means that your game is automatically cross platform. - -Getting to know the framework can be challenging in the beginning, which is why I wanted to make a little series about it. Before I moved my blog to a static site generator I had a rather popular series about LibGDX called "Game of Codes". Unfortunately large parts of the guides are now outdated and no longer relevant. And the Wordpress export destroyed most of the formatting. - -Which is why I decided to rewrite them. Here it is: the Game of Codes! - -NOTE: This tutorial requires a basic level of programming/ scripting skills. General Java knowledge is required or at the very least knowledge of how coding works. If you don't know that yet then I -recommend [Bucky Roberts Java Programming series on Youtube](https://www.youtube.com/watch?v=Hl-zzrqQoSE&list=PLYJQBQw9Wdiid6eT1_DqBP3lnbJCzo3s8). -It's very good! - - -### Setting up LibGDX - - -Now that we've got that out-of-the-way let's set up our workspace to -make some neat games. - -1. First of all you'll need to have Java and an IDE installed on your computer. I recommend Eclipse. For pointers on how to install those please use Google. -2. Go to [http://libgdx.badlogicgames.com/](http://libgdx.badlogicgames.com/) Downloads and download the framework. You can either go for a nightly build (that will contain more awesome features but probably bugs) or the stable version. Current stable at the time of writing this is 0.9.9 and the version that I will be using (and am using for all my projects). -3. Save and extract the libgdx-0.9.9.zip file somewhere on your computer and open up the folder. You'll see a multitude of things. Now…we could set up an Eclipse project, import all the right files and write some dummy code but there is an easier way to do this and it's called the Setup-UI. The following two screenshots will explain the basics. This should be trivial but I'll still go over it. Feel free to skip to the next part below. - - - -The following steps will be conducted in the .Jar setup UI. On the upcoming window click on CREATE and then fill out the information on the next screen. Everything you need to consider is being marked as red in the next screenshot. - - - -Make sure you already have the directory created that you want to put the project in. The java UI can NOT create folders. Be sure to disable the iOS project. It won't break anything if you leave it ticked but we won't be working with it. - -During the selection of the libraries you need to select the folder icon and then point the application at the archived .zip file you downloaded in the beginning for LibGDX and press the other little arrow button for the Universal Tween Engine to download it. The Jar isn't included in the LibGDX package by default but it can come in handy later. When you're ready to continue everything should light up green. Click on OPEN THE GENERATION SCREEN to continue, click LAUNCH and watch the magic happen. - - -### Working with LibGDX - -Now that we have an auto generated LibGDX project it's time to import it into Eclipse and look at the actual code. Go into Eclipse, File --\> Import. Select General --\> "Existing Projects into Workspace". Navigate to the path and check that all your LibGDX projects are shown as in the screenshot below. Afterwards you should be set to do some serious coding! - - - -NOTE: LibGDX works very close with Android and when you import the -project you will see the Android project having exploded because of -various issues. Make sure that you have Android set up on your computer. -If you don't, may I refer you to an older blog post of mine: This will -explain the setting up of Android. - -That's important, as LibGDX uses the Android assets folder as a link to -the main project. You can change that, if you want. But we'll leave it -as is for now! If you're having issues with this step, post your problem -in the comments below and I'll try to help you resolve it. - - - -Now that everything should be ready to go, let's check what kind of code -we have here and understand the basic structure of LibGDX. As you've -already seen there are several projects that were just created: three -projects with suffixes (-android, -desktop, -html) and a core project -without a suffix. All the actual coding will be done in the core project -while the other projects are called "deployment projects". In them you -can adjust platform specific code to deploy your software. But for now, -we will only be working with the Core project and use the desktop -deployment for debugging. - -NOTE: Make sure that you leave your Android project open, as LibGDX uses -the androids Assets folder for all the other projects. - - - -Now, that we have this figured out, go to your core project and open up -the only class that there should currently be in there. Mine is called -TutorialsLauncher and it has a certain layout of methods in it that -LibGDX always uses. - -- **public void create()** - Called when the game is created -- **public void resize()** - Called after create and every time the - window is resized (if that is allowed) -- **public void render()** - Starts calling after create() and - resize() and will be recalled every frame. This is your game loop! -- **public void pause()** - Called when the game is closed on Android -- **public void resume()** - Called when the game is re-opened on - Android -- **public void dispose()** - Called when the game is closed. - -This layout allows for very structured code to be written. An -interesting thing to note is that this layout comes from the -implementation of the **ApplicationListener** interface. So when you -create your own main game class you just implement that interface and -it'll suggest the code layout for you automatically. - -Before we look at the code in more detail and see what it actually does -we should launch the application though and see what it looks like. For -that you'll need to create a Run Configuration for a Java Application -and point it at the Main class in your \*\*-Desktop project. A new -window will open and TADA! The dummy "game" :) - - - -Now let's look at the actual code that does stuff: - -``` {.width-set:false .lang:java .decode:true title="Create Method"} - @Override - public void create() { - float w = Gdx.graphics.getWidth(); - float h = Gdx.graphics.getHeight(); - - camera = new OrthographicCamera(1, h/w); - batch = new SpriteBatch(); - - texture = new Texture(Gdx.files.internal("data/libgdx.png")); - texture.setFilter(TextureFilter.Linear, TextureFilter.Linear); - - TextureRegion region = new TextureRegion(texture, 0, 0, 512, 275); - - sprite = new Sprite(region); - sprite.setSize(0.9f, 0.9f * sprite.getHeight() / sprite.getWidth()); - sprite.setOrigin(sprite.getWidth()/2, sprite.getHeight()/2); - sprite.setPosition(-sprite.getWidth()/2, -sprite.getHeight()/2); - } -``` - -First thing the code does is log the current resolution of the game and -store them in two float variables. - -Next up we create a camera, set up with the ratio of the resolution we -just stored in the variables. (We'll talk more in-depth about cameras -later) - -The next block loads a texture from the data folder which is stored in -the Androids assets folder and applies a linear filter (If you want to -learn more on that click -[here](http://gaming.stackexchange.com/questions/48912/whats-the-difference-between-bilinear-trilinear-and-anisotropic-texture-filte)). -Don't worry if the rest of that class looks like alien text. I'll -explain renderings, drawings, textures etc. in more detail in a later -article. For now you just need to know: it's setting up a sprite -(texture). - -Next up in the code we have dispose: - -``` {.width-set:false .lang:java .decode:true} - @Override - public void dispose() { - batch.dispose(); - texture.dispose(); - } -``` - -Objects that use anything with OpenGL need to be disposed (should. it's -good practise). It's not that important if you quit the application but -rather when changing screens (more on that later too). - -Which brings us to the main method doing stuff in this "game". Render(): - -``` {.width-set:false .lang:java .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - sprite.draw(batch); - batch.end(); - } -``` - -The first two calls are OpenGL specific and absolutely need to be in -there. It clears the screen completely and then draws over with a colour -(actually ClearColor only sets a colour and the glClear clears the -screen and draws the colour but more to that later too). - -Then comes the tricky part. - -"batch" is the SpriteBatch that was created earlier in the create(); -method. It's essentially handling texture mapping to the screen and uses -the cameras viewport (aka what the camera is looking at and how many -pixels it contains) to properly map the texture to the screen. It's -begun, then a sprite is drawn and then it's ended. (That's how you draw -things low-level with OpenGL). And that's the game loop. - -Depending on how the window is scaled this means that the texture will -always look (more or less) right because it's being adjusted to the -camera viewport (which is essentially just the entirety of the -application window. - - - -I know that this was a lot to take in for now. But I'll touch these -topics in later articles (again). And if I don't then there are plenty -of great resources out there (probably better than these :) to help you -around. - -However, I want to do one more thing here and that is give this Game a -more Game-y feeling. First of all you should head to the image processor -of your choice (in my case Photoshop) and sketch up something that might -look like a spaceship. - - - -Make sure that the size of the image is by the power of 2 (so 2, 4, 8, -16, 32, 64, 128, 256, 512, 1024, 2048, 4096, etc. because that's how -LibGDX works. - -What you say? You're too lazy? You don't have an image processing -application? You managed to delete Paint from your computer? Kudos. Use -[this](http://www.spacekookie.de/downloads/Tutorials/LibGDX1/USS_Pixel.zip "USS Pixel") -then! Next up we want a picture of space. I'm not gonna make something -myself here. And neither will you (most likely). How about -[this](http://www.wallsave.com/wallpapers/1024x1024/galaxies/236804/galaxies-cool-galaxy-and-space-ipad-236804.jpg "Space")? - -Save both of these on your computer and import them into your -Android-projects assets folder (copy, not link!) Next up we want to -adjust a bit of our code. If you use external resources they always need -to be as power-of-two pictures. And to overcome that there is a thing -called a TextureAtlas (SPOILERS). But I'll touch that later. - -For now, we just need to change the path in one line: - -``` {.width-set:false .lang:java .decode:true} -texture = new Texture(Gdx.files.internal("space.jpg")); -``` - -I made it easy on me and just renamed the picture into "space" and moved -it into the assets folder which in LibGDX internal files is being -referenced as root. If you compile this you'll see two white bars on the -sides. So first, we might want to change that to black to make it -more…space-y but secondly we might want to change the starting -resolution of the game. If you were observant before you know where to -change the OpenGL colour. That's right. Here: - -``` {.width-set:false .lang:java .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); -``` - -It uses R-G-B composition colours referenced with floats. The fourth is -the alpha channel. So to get Black we want to set it to - -``` {.width-set:false .lang:java .decode:true} -Gdx.gl.glClearColor(0, 0, 0, 1); -``` - -For the resolution we need to check our platform-specific launcher. In -our case we have to check the Main method in the \*\*-Desktop project -and adjust two things. First, we want the starting resolution to be -800x600 as that's what the TextureRegion cuts from the original texture. -And we want to disable the ability for the window to be resized (for -now) as it adds a whole mess to take care of. - -``` {.width-set:false .lang:java .decode:true} - cfg.resizable = false; - cfg.width = 800; - cfg.height = 600; -``` - -So essentially we need to add one line to the configuration and change -two. - -However, we're not done yet. We gave the texture the new path to import. -But that's not all. We need to tell the texture region what part of the -cake to slice from the original texture. And we also need to change some -of the positioning that happens. Essentially you want your code to look -like this: - -``` {.width-set:false .lang:java .mark:6,12,15 .decode:true} - @Override - public void create() { - float w = Gdx.graphics.getWidth(); - float h = Gdx.graphics.getHeight(); - - camera = new OrthographicCamera(w, h); - batch = new SpriteBatch(); - - texture = new Texture(Gdx.files.internal("space.jpg")); - texture.setFilter(TextureFilter.Linear, TextureFilter.Linear); - - TextureRegion region = new TextureRegion(texture, 0, 0, 800, 600); - - sprite = new Sprite(region); - sprite.setPosition(-sprite.getWidth() / 2, -sprite.getHeight() / 2); - } -``` - -I changed the camera setup to just simply use the width and height as -it's viewport, told the texture region to cut a 800x600 part from our -1024x1024 texture and removed the size and origin manipulation. Now -compile this and BOOM. - - - -Shiny! \<3 Now we need some slick advertisement and EA will sell this -for 60\$ (+ DLC of course). - -Now…we have that ship. Let's just quickly add the ship in idle state in -the middle of the screen before this post gets too long. You should know -how to add the space ship texture by now: - -``` {.width-set:false .lang:java .mark:4-5,21-25,32,43 .decode:true} -public class TutorialLauncher implements ApplicationListener { - private OrthographicCamera camera; - private SpriteBatch batch; - private Texture texture, shipTexture; - private Sprite sprite, ship; - - @Override - public void create() { - float w = Gdx.graphics.getWidth(); - float h = Gdx.graphics.getHeight(); - - camera = new OrthographicCamera(w, h); - batch = new SpriteBatch(); - - texture = new Texture(Gdx.files.internal("space.jpg")); - texture.setFilter(TextureFilter.Linear, TextureFilter.Linear); - TextureRegion region = new TextureRegion(texture, 0, 0, 800, 600); - sprite = new Sprite(region); - sprite.setPosition(-sprite.getWidth() / 2, -sprite.getHeight() / 2); - - shipTexture = new Texture(Gdx.files.internal("USS_Pixel/ship_idle.png")); - - TextureRegion shipRegion = new TextureRegion(shipTexture, 0, 0, 64, 64); - - ship = new Sprite(shipRegion); - } - - @Override - public void dispose() { - batch.dispose(); - texture.dispose(); - shipTexture.dispose(); - } - - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - sprite.draw(batch); - ship.draw(batch); - batch.end(); - } -``` - -And voila :) - - - -But this is it for today. I will start working on the next post -immediately where we will discuss input and movement on the screen (all -very basic) as well as TextureAtli (maybe, if you're lucky) - -Until then have a good day/night, - -Kate - - diff --git a/teaching/gameofcode/02-libgdx-game-of-codes-input-movement.md b/teaching/gameofcode/02-libgdx-game-of-codes-input-movement.md deleted file mode 100755 index aa76302..0000000 --- a/teaching/gameofcode/02-libgdx-game-of-codes-input-movement.md +++ /dev/null @@ -1,345 +0,0 @@ -Title: 02. (LibGDX) Game of Codes: Input & Movement -Date: 2013-12-18 18:45 -Category: Game of Codes -Tags: Guides -Slug: 02-libgdx-game-of-codes-input-movement -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we learned how to set up LibGDX in our -Java project and draw pictures onto the screen. We used Textures to -import the image and then drew a Sprite from a specific TextureRegion. -This would allow for multiple assets to be saved in a single texture and -thus saving time when loading assets. - -In this edition I want to show you LibGDXes abilities to handle input -and move things on the screen. This will be all very basic but hang in -there with me. Let's begin. - -Two ways of registering input ------------------------------ - -There are two ways to register input events. The first one is to -directly listen to input events in your main game loop and execute code -depending on what happens. - -[](http://www.spacekookie.de/wp-content/uploads/2013/12/input_raw.png) - - - -The other method is to create an input processor that sorts through all -the input (not just certain types), allows for more complex features -(like dragging gestures on Android) - - - - - -For now, we'll just use the first method. It'll make the process of -input handling very clear. In the second part of this tutorial we'll -have a look at input processor that are mostly needed for mouse and -gesture tracking. - - - -Listening for simple button events ----------------------------------- - -The easiest way to listen for a button-pressed event is by calling - -``` {.lang:java .decode:true} -Gdx.input.isKeyPressed(Keys.W) -``` - -where Keys is an enum index that contains all keys on a regular -keyboard, excluding international characters (Like Ö, æ or å). This -method returns a boolean that can simply be the argument of an -if-statement: - -``` {.lang:java .decode:true} - if (Gdx.input.isKeyPressed(Keys.W)) { - } -``` - -Will run, when the a-key is pressed, if we put this into our games -"render" method. By polling the state of the boolean for the Key "W" -every frame we can get its status whenever the game is running. However -note that this is getting the value indirectly. When a button is pressed -this triggers an event listener to set the boolean to "true" and to -"false" again, once the listener detects that the button has been -released. - -But back to our example. In our case we want the spaceship to fly up, -whenever the "W" key is pressed. Let's take a look at the render method -of our game. - -``` {.lang:java .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - sprite.draw(batch); - ship.draw(batch); - batch.end(); - } -``` - -We already use the "ship" sprite in the method. All we need to do now is -update the position before drawing it onto the screen. Unfortunately -there is no direct way to add values to the position of a sprite, only -to overwrite it. So we need to fetch the position first, add our desired -value and then set that new position. The code for that looks something -like that (using the example above where we want the "W" Key to move the -ship up): - -``` {.lang:java .decode:true} -if (Gdx.input.isKeyPressed(Keys.W)) { - Vector2 updated = new Vector2(ship.getX(), ship.getY() + 5); - ship.setPosition(updated.x, updated.y); - } -``` - -Now compile this and press the "W" key and watch what happens. The ship -is moving up. Why? Because with each frame it is being checked if the -"W" key is pressed and if that is the case we add 5 pixels to the -Y-coordinate of the ship sprite. - -We can now continue and do this for all four directions: - -``` {.lang:java .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - if (Gdx.input.isKeyPressed(Keys.W)) { - Vector2 updated = new Vector2(ship.getX(), ship.getY() + 5); - ship.setPosition(updated.x, updated.y); - } - if (Gdx.input.isKeyPressed(Keys.S)) { - Vector2 updated = new Vector2(ship.getX(), ship.getY() - 5); - ship.setPosition(updated.x, updated.y); - } - if (Gdx.input.isKeyPressed(Keys.D)) { - Vector2 updated = new Vector2(ship.getX() + 5, ship.getY()); - ship.setPosition(updated.x, updated.y); - } - if (Gdx.input.isKeyPressed(Keys.A)) { - Vector2 updated = new Vector2(ship.getX() - 5, ship.getY()); - ship.setPosition(updated.x, updated.y); - } - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - sprite.draw(batch); - ship.draw(batch); - batch.end(); - } -``` - -Note that the "updated" vector is only a local variable inside the -if-statement and can't be used outside of it. Re-using the name inside -each if-block won't have any weird side effects or break the code. - -If you now compile this you'll see that you can move the ship around on -both axis and in all directions but this isn't really a great game yet. -Why? Well...while this might be enough for a retro-side-scroller where -the player only faces up (down) or right (left) for tall intention -purposes, we want the ship to fly around more realistically. So it's -time to introduce rotation to our little game. - -As you might have expected we can simply choose two other keys on our -keyboard (let's take Q and E) and use them to check for other if -statements. In addition to that there is a sprite-method called -"rotate". It should be fairly obvious now :) - -``` {.lang:java .decode:true title="Add this to your render() method!"} - if (Gdx.input.isKeyPressed(Keys.Q)) { - ship.rotate(-5f); - } - if (Gdx.input.isKeyPressed(Keys.E)) { - ship.rotate(5f); - } -``` - -And that's it. Compile and see what happens. Fly around a bit. I'll be -waiting here. - ------------------------------------------------------------------------- - -Oh. You're back quickly. Do I see a hint of disappointment on your face? -:) That's okay. See…we might have changed the rotation in the code, -however the displacement vectors (aka the direction that the ship will -be moved into) isn't in correlation with the rotation, just x and y -values. So the rotation doesn't matter, pressing "W" will move the ship -up, etc. - -Now...there is an easy way to do this and a hard one. I want you to be -familiar with the mathematical basics first before I show you the easy -way. - -[caption id="" align="aligncenter" -width="256"] -x = tan(α) \* y[/caption] - -For each movement the angle of the ship needs to be considered before -moving the ship into the direction of the rotation-vector. Now the easy -way: - -First create a new global vector that holds the speed of the ship and -the direction that the speed should be applied to. In this case 5 pixels -on the Y-axis. - -``` {.lang:java .decode:true} -Vector2 move = new Vector2(0f, 5f); -``` - -Now you need to add a bit of code to the if-statement that checks if the -"W" key is pressed. - -``` {.lang:java .mark:3 .decode:true} - if (Gdx.input.isKeyPressed(Keys.W)) { - Vector2 temp = new Vector2(ship.getX(), ship.getY()); - temp.add(move); - ship.setPosition(temp.x, temp.y); - } -``` - -We're almost done. The last thing we need is to actually rotate the -movement vector by the amount that the ship has rotated. - -``` {.lang:java .mark:2 .decode:true} - if (Gdx.input.isKeyPressed(Keys.A)) { - move.rotate(5f); - ship.rotate(5f); - } -``` - -You can adjust the if-statement to check if the "S" key is pressed but I -removed it from my code for now. - -So this is the full code - -``` {.lang:java .mark:1,9,13-14,17-18 .decode:true} -Vector2 move = new Vector2(0f, 5f); - -@Override -public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - if (Gdx.input.isKeyPressed(Keys.W)) { - Vector2 temp = new Vector2(ship.getX(), ship.getY()); - temp.add(move); - ship.setPosition(temp.x, temp.y); - } - if (Gdx.input.isKeyPressed(Keys.A)) { - move.rotate(5f); - ship.rotate(5f); - } - if (Gdx.input.isKeyPressed(Keys.D)) { - move.rotate(-5f); - ship.rotate(-5f); - } - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - sprite.draw(batch); - ship.draw(batch); - batch.end(); -} -``` - -Compile the game and enjoy flying around a bit. This is a very elegant -way to handle rotation of an object because the movement logic (move -vector) is disconnected from the rendering logic (Sprite). - -One last thing I want to add in this post is some eye candy. In the next -post we'll have a look at the InputAdapter and get some mouse -interaction into our game. - -First you should add three more texture regions: shipIdle, shipFly1 and -shipFly2 and refactor the code for the textures and the regions a bit to -be less confusing. My refactored code below as reference but you don't -have to do it exactly as I do. - -``` {.lang:java .mark:4-6,22-27 .decode:true .crayon-selected} -public class TutorialLauncher implements ApplicationListener { - private OrthographicCamera camera; - private SpriteBatch batch; - private Texture background; - private Sprite space, ship; - private TextureRegion shipIdle, shipFly1, shipFly2; - - @Override - public void create() { - float w = Gdx.graphics.getWidth(); - float h = Gdx.graphics.getHeight(); - - camera = new OrthographicCamera(w, h); - batch = new SpriteBatch(); - - background = new Texture(Gdx.files.internal("space.jpg")); - background.setFilter(TextureFilter.Linear, TextureFilter.Linear); - TextureRegion region = new TextureRegion(background, 0, 0, 800, 600); - space = new Sprite(region); - space.setPosition(-space.getWidth() / 2, -space.getHeight() / 2); - - shipIdle = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_idle.png")), 0, 0, 64, 64); - shipFly1 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly1.png")), 0, 0, 64, 64); - shipFly2 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly2.png")), 0, 0, 64, 64); - - ship = new Sprite(shipIdle); - } - - @Override - public void dispose() { - batch.dispose(); - background.dispose(); - } -``` - -So we're essentially creating three TextureRegions and mapping the -different pictures of the USS Pixel to it. Lastly, we want the game to -randomly pick one of these three textures when the ship is flying around -to generate an animation effect. For that purpose you should change some -code in the if-statement that checks whether the "W" key is pressed. - -``` {.lang:java .mark:11-20 .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - if (Gdx.input.isKeyPressed(Keys.W)) { - Vector2 temp = new Vector2(ship.getX(), ship.getY()); - temp.add(move); - ship.setPosition(temp.x, temp.y); - - int i = new Random().nextInt(2); - if (i == 0) - ship.setRegion(shipIdle); - else if (i == 1) - ship.setRegion(shipFly1); - else if (i == 2) - ship.setRegion(shipFly2); - - } else { - ship.setRegion(shipIdle); - } -``` - -Now compile this and enjoy. - - - -You should now know how to handle basic keyboard input, how to properly -process it and also to move things on the screen more intelligently than -just to adjust their pixel coordinates manually. In the next issue I -want to introduce you to the InputAdapter but I feel that it would drag -this post out too much. So until next time, keep coding. diff --git a/teaching/gameofcode/03-libgdx-game-of-codes-input-movement-2-0.md b/teaching/gameofcode/03-libgdx-game-of-codes-input-movement-2-0.md deleted file mode 100755 index 6f5e208..0000000 --- a/teaching/gameofcode/03-libgdx-game-of-codes-input-movement-2-0.md +++ /dev/null @@ -1,476 +0,0 @@ -Title: 03. (LibGDX) Game of Codes: Input & Movement 2.0 -Date: 2013-12-19 13:12 -Category: Game of Codes -Tags: Guides -Slug: 03-libgdx-game-of-codes-input-movement-2-0 -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we learned how to listen for keyboard -input, move things on the screen and do some basic game logic with -vectors. In this issue I want to re-touch that subject, but in a more -advanced manner. This time we'll have a look at InputProcessors and -their ability to listen for any kind of input, including mouse and -touchscreen gestures. If you haven't already worked through the last -issue of this tutorial series, you should do that -[now](http://www.spacekookie.de/02-libgdx-game-of-codes-input-movement/ "02. (LibGDX) Game of Codes: Input & Movement")! -I'll wait here. - -Oh, you stayed. Well then, let's get started. - - - -First of all we'll want to create a new class that extends the -InputAdapter. - -``` {.lang:java .decode:true} -package de.spacekookie.libgdxtutorial; - -import com.badlogic.gdx.InputAdapter; - -public class InputHandler extends InputAdapter { - -} -``` - -You can name yours whatever you want, I chose InputHandler, as for any -managing class that HANDLES things in my software :) Handlers and -Dealers, the criminal underworld in my source code is real. - -We will add things to this class later, first of all we should tell our -game that it exists. And we can do that by adding the following code -into the games creation method. - - - -``` {.lang:java .decode:true} - private InputHandler handler; - - @Override - public void create() { - - . . . - - handler = new InputHandler(); - Gdx.input.setInputProcessor(handler); - - . . . - } -``` - -Great. Now that we told our game to actually use the InputAdapter we -created we can start and add some actual code to it. If you look at the -class that we're extending you can see a few methods that we can -override. Why don't you add this method to the InputAdapter class. - -``` {.lang:java .decode:true} - @Override - public boolean keyDown(int keycode) { - return true; - } -``` - -Remember when I told you in the last post that polling -Gdx.input.isKeyPressed(. . .); was only an indirect way to get the -status of a key and would only react to a listener event? Well guess -what...that's an event listener that will react t ANY key-down event. -The keycode passed into the listener specifies the key in question. - -Go ahead and check if keycode is the same as the integer representing a -key (Keys.\*) like SPACE. - -``` {.lang:java .decode:true} -if (keycode == Keys.SPACE) { - System.out.println("If this game had gravity I would want to JUMP!"); -} -``` - -If you compile this you'll see that the game will of course still -recognize the inputs handled in the Games render() method but in -addition to that will react to keystrokes being handled in our -InputAdapter. However...we have a problem. To actually handle the input -in the Adapter we need to pass on some information into it. We can -either pass the Sprite along but I would say something much better is to -create a custom Object to hold all the important information to render, -move and manipulate the ship (or other entities we might add later). So -why don't you go ahead and create a new class called "Entity". I went -ahead and added some code to it to actually make it useful. - -``` {.lang:java .decode:true} -package de.spacekookie.libgdxtutorial; - -import java.util.Random; - -import com.badlogic.gdx.Gdx; -import com.badlogic.gdx.graphics.Texture; -import com.badlogic.gdx.graphics.g2d.Sprite; -import com.badlogic.gdx.graphics.g2d.SpriteBatch; -import com.badlogic.gdx.graphics.g2d.TextureRegion; -import com.badlogic.gdx.math.Vector2; - -public class Entity { - - public static enum EntityType { - PLAYER, ENEMY; - } - - public static enum ShipState { - IDLE, MOVING, DEAD; - } - - private EntityType type; - private Sprite self; - private TextureRegion shipIdle, shipFly1, shipFly2; - - private Vector2 moveVector = new Vector2(0f, 1f); - private float speed = 5f; - - public Entity(EntityType type) { - this.type = type; - moveVector.scl(speed); - loadResources(); - } - - public void loadResources() { - if (type.equals(EntityType.PLAYER)) { - shipIdle = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_idle.png")), 0, 0, 64, - 64); - shipFly1 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly1.png")), 0, 0, 64, - 64); - shipFly2 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly2.png")), 0, 0, 64, - 64); - - self = new Sprite(shipIdle); - } - } - - public void idle() { - self.setRegion(shipIdle); - } - - public void fly() { - int i = new Random().nextInt(2); - if (i == 0) - self.setRegion(shipIdle); - else if (i == 1) - self.setRegion(shipFly1); - else if (i == 2) - self.setRegion(shipFly2); - } - - /** Used to get access to methods */ - public Sprite getSelfSprite() { - return self; - } - - public Vector2 getMovement() { - return moveVector; - } - - public void setMovement(Vector2 moveVector) { - this.moveVector = moveVector; - } - - /** Will be called in the @render() method */ - public void draw(SpriteBatch batch) { - self.draw(batch); - } - -} -``` - -If you actually look at the code you won't see anything you haven't seen -before. What I did was move all the texture loading, sprite setup and -region swapping when flying and idling into this class as well as -creating a few getters to access the information from outside the class. - -The only two new things are the two enums, ShipState and EntityType -which will become more useful in the future. But laying the groundwork -now for a more complex game will become handy later. - -Next up we need to take a look at the InputAdapter and change it in a -way that it uses flags on keyDown and keyUp (as in setting a flat to -"true" on down and "false" to up). Then move all the movement logic into -a method called "update()" that will be called in the games render() -method. - -Here is my code as reference. - -``` {.lang:java .decode:true} -package de.spacekookie.libgdxtutorial; - -import com.badlogic.gdx.Input.Keys; -import com.badlogic.gdx.InputAdapter; -import com.badlogic.gdx.math.Vector2; - -public class InputHandler extends InputAdapter { - - private Entity entity; - private boolean moving, clock, counterClock; - - public InputHandler(Entity entity) { - this.entity = entity; - } - - @Override - public boolean keyDown(int keycode) { - if (keycode == Keys.W) { - moving = true; - } - if (keycode == Keys.A) { - counterClock = true; - } - if (keycode == Keys.D) { - clock = true; - } - return true; - } - - @Override - public boolean keyUp(int keycode) { - if (keycode == Keys.W) { - moving = false; - } - if (keycode == Keys.A) { - counterClock = false; - } - if (keycode == Keys.D) { - clock = false; - } - return true; - } - - public void update() { - if (moving) { - Vector2 temp = new Vector2(entity.getSelfSprite().getX(), entity - .getSelfSprite().getY()); - temp.add(entity.getMovement()); - entity.getSelfSprite().setPosition(temp.x, temp.y); - - entity.fly(); - } else { - entity.idle(); - } - if (counterClock) { - entity.getMovement().rotate(5f); - entity.getSelfSprite().rotate(5f); - } - if (clock) { - entity.getMovement().rotate(-5f); - entity.getSelfSprite().rotate(-5f); - } - } -} -``` - -And the games render() method. - -``` {.lang:java .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - handler.update(); - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - space.draw(batch); - player.draw(batch); - batch.end(); - } -``` - -Make sure to remove all calls from the main game class that we have -already moved to our Entity. And that's it. Compile this and see what we -made (a huge mess, I know). - -So? Well done, we just remade what we already had, just in less -clustered and more shiny. But this isn't very impressive, is it now? -Sure this code looks much cleaner than before but InputAdapters are a -lot more powerful than that. Why don't you go ahead and add a new method -to our InputAdapter. - -``` {.lang:java .decode:true} - @Override - public boolean mouseMoved(int screenX, int screenY) { - System.out.println(screenX + " : " + screenY); - return false; - } -``` - -When you compile this you'll see the coordinates of your mouse output in -the console as you move the cursor over the game window. That's because -the listener is being called every time the mouse is moved and without -any further filtering it of course. Now it's gonna get rough, so put on -your thinking hats and try not to go mad. Because we'll have to go and -mock around with Vectors quite a bit and I will have to introduce you to -camera vectors already. I will only brush the subject here and retouch -it in a later version to go more in depth. - -First up we need to change a few things in our main game class. First, -change the OrthographicCamera variable to "static". - -``` {.lang:java .decode:true} -private static OrthographicCamera camera; -``` - -And then write a little getter for that camera variable that's also -static, so that we can access it without having to worry about a -constructor. - -``` {.lang:java .decode:true} - public static OrthographicCamera getCameraInstance() { - return camera; - } -``` - - - -Now, go ahead and create three more global variables in the -InputAdapter. - -``` {.lang:java .decode:true} - private boolean clicked; - private Vector3 vec; - private Vector3 target; -``` - -The boolean will be used to flag whether the mouse button has been -clicked and the ship is still en-route. The two 3D vectors will be used -to pinpoint the target we're trying to approach and the movement vector -that the ship will be using. They need to be Vector3 objects (3D -vectors) because they need to interact with our camera, which is a 3D -object. Don't forget! LibGDX is a 3D game development framework, so we -need to ignore the third dimension most of the time. Just set it to "0"! - -Now we need to handle the mouse actions. Go and delete that line of code -from the mouseMoved method and create a touchDown() method. It will be -used to register mouse events but can also be used to register touches -on Android devices. - -``` {.lang:java .decode:true} - @Override - public boolean touchDown(int x, int y, int pointer, int button) { - if (pointer == 0) { - if (button == 0) { - - } - } - return false; - } -``` - -The pointer is "0" in case of the mouse but can be something else, when -we're dealing with touchscreen input. The button "0" is the left mouse -button, "1" is the right one. Nest those two if-statements, so that both -need to be true for our code to be executed. I will go through what we -do here line by line because it's not exactly trivial. - -``` {.lang:java .decode:true} -vec = new Vector3(x, y, 0); -``` - -First we take that Vector3 (vec) we created before and put some -information into it. X and Y are the mouse coordinates that are passed -into the listener (where the click occurred) and put 0 for the -Z-Coordinate. - -``` {.lang:java .decode:true} -TutorialLauncher.getCameraInstance().unproject(vec); -``` - -Next up, we need to call that static method we created in our main game -class to get the camera and call "unproject" onto it. Unprojecting means -associating a coordinate in the camera space with a pixel coordinate on -the screen. When the camera is moving around it will change the -coordinates quite drastically. So a camera coordinate (5000, 10000) -could still correlate to a pixel coordinate that's more like (255, 128), -etc. Unprojecting the camera and passing our Vector3 object into it -aligns the camera space with the pixel space on-screen. We WILL talk -about cameras and matrix projection in a later issue. For now, I hope -that this is at least somewhat clear. - -Next up, store the unprojected vector in our target Vector3 that we -created, set the boolean and return from the method. - -``` {.lang:java .decode:true} -target = new Vector3(vec); -clicked = true; -return true; -``` - -The target Vector3 will not change and serve as a reference where the -original click was made and when we want our ship to stop flying. We're -almost done. We already flag our button clicks in the listener, now we -just need to use that flag in our update() method that gets called every -frame. - -``` {.lang:java .decode:true} - if (clicked) { - entity.fly(); - } else { - entity.idle(); - } -``` - -You should understand what that does, just registering the clicked flag -and setting the textures accordingly. - -``` {.lang:java .decode:true} - Vector2 temp = new Vector2(entity.getSelfSprite().getX(), - entity.getSelfSprite().getY()); -``` - -Log the current position of our sprite and save it in the temp Vector. -And now it's getting kinda tricky. There is a Vector method called lerp, -which interpolated two vectors. We will touch Vectors again in a later -issue. If you want to read the mathematical principles of interpolation -you can click [here](http://en.wikipedia.org/wiki/Linear_interpolation). -(If you're masochistic like that). - -``` {.lang:java .decode:true} - temp.lerp(new Vector2(vec.x, vec.y), 0.1f); - entity.getSelfSprite().setPosition(temp.x, temp.y); -``` - -Vec starts as the target and gets shorter and shorter as the temp vector -approaches the target more and more. Afterwards we do the normal jazz -and adjust the entities Sprite position with the new temp vector (which -isn't the target position but rather the first step on the way to the -target. - -Lastly we need to deactivate the ships engines when the ship has reached -the target position (that's why we saved it in the target vector :) ) - -``` {.lang:java .decode:true} - if (target.dst(temp.x, temp.y, 0) < 2) - clicked = false; -``` - -Add this to the end of the if(clicked)-statement. dst(. . .) returns the -range between two vectors (target and temp, where we only look at the X -and Y coordinates) and we can then compare that range to a number, in my -case 2. So when the temp vector gets into a range of 2 pixels to the -target vector the if-statement is true and sets the clicked boolean to -"false" and stops moving the ship (and then the else-statement is called -and sets the texture to idle again). It also corrects the rotation -correction that we used before. - - - -And that's that. Compile the game and try out the two methods of -movement we now have. Rotating the ship properly when clicking would be -too long and difficult for this tutorial so I left it out. (Well -actually rotating isn't too difficult but making the click-rotation and -the keyboard rotation compatible is a bit tricky). - -What we did in this issue was refactor our input handling and add some -more code to interact with the game using the mouse. I don't know what -we'll touch on next but I think we'll end this issue here. I hope you -learned something and until next time, keep coding! - - diff --git a/teaching/gameofcode/04-libgdx-game-of-codes-textures-and-asset-management.md b/teaching/gameofcode/04-libgdx-game-of-codes-textures-and-asset-management.md deleted file mode 100755 index 08248ab..0000000 --- a/teaching/gameofcode/04-libgdx-game-of-codes-textures-and-asset-management.md +++ /dev/null @@ -1,216 +0,0 @@ -Title: 04. (LibGDX) Game of Codes: Textures and asset management -Date: 2013-12-19 19:18 -Category: Game of Codes -Tags: Guides -Slug: 04-libgdx-game-of-codes-textures-and-asset-management -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we learned how to use InputAdapters and -used the keyboard and mouse to order our little space-ship around on the -screen. In this issue I want to take a step back from our actual game -and have a look at our surroundings. Data files, assets and resource -imports. Where to put them to make the game code as practical and -readable as possible. LibGDX has a few quirks and also tools to make -asset management as easy as it can be. So without further ado, let's -begin. - -Collecting all Asset imports in one class {style="text-align: justify;"} ------------------------------------------ - -The first thing we'll want to do is create a new package in our project. -I named mine "Util" to symbolize that everything in there has to do with -utility classes and tools that don't have a direct effect on gameplay -but are substantially important in using the game. If you're not -familiar with naming conventions for packages here is the rundown. - -``` {.lang:java .decode:true} -SUFFIX.DOMAIN.PROJECT.PACKAGE.SUB-PACKAGE - -In my case: - -de.spacekookie.libgdxtutorial.util -``` - -If you don't have website where you would publish your code just use -your name with a com or de or whatever your language code is (or you -want it to be to confuse people). - - - -Be sure to select your source folder to create the package. And then in -the next dialogue type the entire package tree, not just the name of the -end package you want to name. Because Eclipse will create folders from -these sub-trees. - -[](http://www.spacekookie.de/wp-content/uploads/2013/12/Screen-Shot-2013-12-19-at-15.19.16.png)And -to not confuse us in the long run r-click on that other package that so -far holds all other classes and add the subpackage-name "core" to it. It -will symbolize that it holds our darkest secrets (aka the most important -classes in our game, like the main game class or the InputAdapter). - -When you're done with that go ahead and create a new class in the "util" -package named along the lines of "ResourceLoader" or "TextureLoader" or -whatever takes your fancy. I'm gonna call it "**ResPack**" short for -"ResourcePacker", because it will be filled with static variables that -we will have to call from all over the game...LOTS of times. So I want -it to be as short as it can be. Once created go and fill it up with our -texture loading and save them into "public static final" variables. We -wan them to be accessible from anywhere in the game "public static" but -we also want them to be fixed and never changed again (by accident or by -an evil hacker that uses texture hacks) aka "final". - -``` {.lang:java .decode:true} -package de.spacekookie.libgdxtutorial.util; - -import com.badlogic.gdx.Gdx; -import com.badlogic.gdx.graphics.Texture; -import com.badlogic.gdx.graphics.g2d.TextureRegion; - -/** Class to load all assets for the game */ -public class ResPack { - - public static final TextureRegion shipIdle = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_idle.png")), 0, 0, 64, 64); - - public static final TextureRegion shipFly1 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly1.png")), 0, 0, 64, 64); - - public static final TextureRegion shipFly2 = new TextureRegion(new Texture( - Gdx.files.internal("USS_Pixel/ship_fly2.png")), 0, 0, 64, 64); -} -``` - -Alright, that's that so far. In addition to that I've made a little -texture called "blast\_small" that we will be adding later, which is -essentially just a little laser shot. You can download it -[here](http://www.spacekookie.de/downloads/Tutorials/LibGDX1/blast_small.png) -and add it to your USS\_Pixel folder in the assets directory. - -But you can already see a problem, the texture isn't in power of two -measurements and we would have to manually cut out the blast from a, say -32x32 texture. But we don't really want that, do we? We're gonna have a -lot more textures later on and if we have to cut out each one -individually we're gonna have a hard time. And that's why we have such a -handy thing called the -[TextureAtlas](http://en.wikipedia.org/wiki/Texture_atlas). - -Working with TextureAtli {style="text-align: justify;"} ------------------------- - -A TextureAtlas is essentially a file that contains all resources in it -packed into one image and an .atlas file that keeps tabs on what -resource can be found at what exact pixel location (and it's size, etc). -To create a TextureAtlas we need a TexturePacker which isn't included in -its GUI form in the LibGDX distribution (we can learn how to use the -command-line class from within our game later). Go -[here](https://code.google.com/p/libgdx-texturepacker-gui/downloads/list) -to download the GUI and add it somewhere in your project folder, why not -inside the asset folder. - -The texturepacker is a .jar that can be run as a UI application that -needs no setting up. Run it and get a look around. First we want to -create a new pack, so do that on the top-left corner of the window. -Select a project name, an input, an output directory and of course a -file-name pattern. Input is the USS\_Pixel folder in our assets folder, -the output is the assets folder itself (in my case). Leave all the other -settings as they are. Then select "Pack 'em all" and wait for a -confirmation to pop up. - - - -Go and check the output folder where you should see a .png and an .atlas -file. If you have a look at the .png you will see that all the single -textures we had in our USS\_Pixel directory have been molded into a -single file that has the power-of-two resolution so that our game won't -die on us. The .atlas file should just be a bunch of numbers and words -with parameters. We'll have a look at those in a minute. First I want -you to update Eclipse so that it sees the new files in our asset folder -and direct your attention back at the ResPack class that we started in -the beginning of this tutorial. - -We'll want to create a TextureAtlas object, private, static and final -and give it the .atlas file to read. I will call mine "\_PIXEL" - -*(It's my naming convention to give variables that are only used in very -very (VERY) specific context an underscore as a beginning so that they -show up first on the list of recommended variables but also to filter -them out quickly and give them somewhat of a specific look. You don't -have to do it this way, I think it's even considered bad practise. But -it's something that I like to do).* - -After we have our private static and final TextureAtlas we can find -textures in it by calling "findRegion(. . .)" on it. Here is some code -as reference. - -``` {.lang:java .decode:true} - private static final TextureAtlas _PIXEL = new TextureAtlas( - Gdx.files.internal("USS_Pixel.atlas")); - - public static final TextureRegion shipIdle = _PIXEL - .findRegion("ship_idle"); -``` - -As you can see we no longer have to bother around with pixel coordinates -in our textures because they've all be stored in the .atlas file by the -TexturePacker. All there is left to do now is remove the TextureRegion -calls from our Entity class and change it the fly() and idle() methods -as well. - -``` {.lang:java .decode:true} - public void loadResources() { - if (type.equals(EntityType.PLAYER)) { - - self = new Sprite(ResPack.SHIP_IDLE); - } - } - - public void idle() { - self.setRegion(ResPack.SHIP_IDLE); - } - - public void fly() { - int i = new Random().nextInt(2); - if (i == 0) - self.setRegion(ResPack.SHIP_IDLE); - else if (i == 1) - self.setRegion(ResPack.SHIP_FLY1); - else if (i == 2) - self.setRegion(ResPack.SHIP_FLY2); - } -``` - -And that's that. Isn't it neat? We cleaned up our code and even made the -loading of textures easier and more efficient as well. The only downside -is that you will have to re-pack your TextureAtlas for every texture -that you add. In practise I usually have 2-3 atli that hold different -kinds of textures together to keep some orientation over the textures -involved. - -For that purpose I created three more textures, the Deep\_Pixel\_Nine, -the Pixel\_Sun and Pixel\_Earth to be part of an "environment" atlas (as -well as a more low-profile space picture :p ). You can download the -whole .zip file with everything inside -[here](http://www.spacekookie.de/downloads/Tutorials/LibGDX1/world.zip)! -Go and add that to the ResPacker. You should know how ;) - -After setting up your ResPacker to properly import all the -TextureRegions you should go and change the image that we're currently -using and clean up your code in a way that it won't crash and doesn't -contain calls that aren't being used anymore. With the ResPacker you -have all your resources in one place and collected in two Texture Atli. - -Lastly, I went ahead and refactored the assets folder a little to be -less clustered and deleted some of the files that we didn't need any -more. Also note that I'm always keeping the raw files in case I need to -update something. - - - -And that's that for our rather short issue this time (I would want to -say this week but I'm writing these so quickly right now). Next time I -want to have a look at...I'm not sure yet. Probably cameras, controlling -cameras, moving cameras around, etc. And of course some lovely camera -theory. But until then have a lovely day and keep coding! diff --git a/teaching/gameofcode/05-libgdx-game-of-codes-cameras-their-controllers-and-more-input.md b/teaching/gameofcode/05-libgdx-game-of-codes-cameras-their-controllers-and-more-input.md deleted file mode 100755 index d52c107..0000000 --- a/teaching/gameofcode/05-libgdx-game-of-codes-cameras-their-controllers-and-more-input.md +++ /dev/null @@ -1,455 +0,0 @@ -Title: 05. (LibGDX) Game of Codes: Cameras, their controllers and more Input -Date: 2013-12-20 02:21 -Category: Game of Codes -Tags: Guides -Slug: 05-libgdx-game-of-codes-cameras-their-controllers-and-more-input -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we learned how to use Texture Atli and -sort our assets in a way that we don't get lost in them (and also import -them all in one place, our ResourcePacker). In this issue I promised you -something about cameras and I realised that this would be the perfect -opportunity to add some more action into our game. Let's begin! - -The first thing we'll want to do is create a new class in our utility -package and call it something along the lines of CameraController, -CameraInputAdapter or CameraManager. Let the class extend the -InputAdapter and already create a few variables in it. An -OrthgraphicCamera called camera and 4 Vector3 objects called current, -mouse, last and delta. We'll need these to handle the scrolling logic -for our camera. - -``` {.lang:java .decode:true} -public class CameraController extends InputAdapter { - final OrthographicCamera camera; - - private final Vector3 current = new Vector3(); - private final Vector3 mouse = new Vector3(); - private final Vector3 delta = new Vector3(); - private final Vector3 last = new Vector3(-1, -1, -1); - -} -``` - -Be sure to give last three "-1" values and the rest you can leave empty. -That's that, now create a constructor that takes the camera and stores -it into the camera variable in our controller. - -Add the highlighted code into your games create() method to set up the -CameraController. **Notice how we replaced the InputAdapter as the Input -Processor and are now using the camController!!!** - -``` {.lang:java .mark:3-4 .decode:true} - camera = new OrthographicCamera(); - camera.setToOrtho(false, w, h); - camController = new CameraController(camera); - Gdx.input.setInputProcessor(camController); - camera.update(); -``` - -And that's where we'll take a step back and look at cameras for a -moment. I already mentioned "unprojecting" in a previous tutorial and -the term "Orthographic" has been flying around quite a lot recently. So -I actually wanted to take the time and explain a few things about -cameras because they'll make the whole ordeal less complicated (and also -give you the ability to come up with your own camera code). - - - -These are the two camera types, left perspective and right orthographic. -The main difference is that the perspective camera actively uses the -third dimension to create the effect of depth while orthographic cameras -will project everything onto the screen in a straight line. The third -dimension can be used to move things behind one another but there is no -effect of depth. Two objects could be apart by 500 pixels in the z-axis -and still have the same size on-screen. - - - -Camera projection is a bit tricky but it boils down to using two -different coordinate sets. When you draw something on the screen every -point in your window has a pixel coordinate from an origin (either top -left or top right corner). But when you're using a camera that camera -can scroll around, it can zoom and move. Therefor every point in the -camera space has a different coordinate than the pixel coordinates on -the screen. In the example of the picture above it is visible that the -point on the screen (in pink) has a different coordinate on the map than -on the screen (because the map and screen origin aren't the same). - -When registering clicks, drags or any kind of interaction all those -coordinates will be in the screen-coordinate system. But we don't want -the game to just set place in one screen width/ height so we move around -and by calling "unproject" with a Vector3 we can translate the screen -coordinates (with help of the camera) into world coordinates. Those two -can be the same if the origins are the same but they can also be vastly -different when on the other side of the game world. - -Don't forget to remember this! Your camera space will always move around -while your pixel space will stay the same. - -If you have questions about that, post them in the comments below. But I -hope this should be clear now. Now we should get back to the matter at -hand. - -Controlling the Camera {style="text-align: justify;"} ----------------------- - -We're gonna have a look at zooming the camera first and limiting zoom -range so that the player can't zoom out to see the entire world or zoom -too far in that one pixel of the ship takes up the entire screen. But -first up, I want you to do one things: go into the games Main method -(the one that starts the Desktop client) and change three things. - -``` {.lang:java .decode:true} - cfg.useGL20 = true; - cfg.width = 1280; - cfg.height = 720; -``` - -Using OpenGL2 isn't important for now but we should do it anyways. It -will make things look smoother and work faster but not be compatible -with older (Android) devices. The second thing is just upgrading the -game to 720p resolution which in 2013 is probably better. Aaaaaand JUST -like that we have the same resolution as the Xbox One :') - -``` {.lang:java .decode:true} - @Override - public boolean mouseMoved(int screenX, int screenY) { - mouse.set(screenX, screenY, 0); - return false; - } - - @Override - public boolean scrolled(int amount) { - float newZoom = camera.zoom * (1 + (amount < 0 ? 0.1f : -0.1f)); - changeZoom(newZoom, mouse.x, mouse.y); - return true; - } -``` - -Add these two methods to our camera controller. The mouseMoved method -should be fairly trivial, we only log the current mouse location into -our lovely vector, with the z-axis set to "0" and return with false. - -The second method is the scrolled(. . .) method that gets passed in an -amount (-1 or 1, depending on the mouse-wheel direction) and executes -some code to calculate the zoom. - -First up we create a new float called newZoom and take the current -camera zoom and multiply it by 1 + either 0.1 or -0.1, depending on -whether amount was 1 or -1. This is a general syntax that can be used, a -shortened if-statement: - -``` {.lang:java .decode:true} -(a < b ? 1 : 2) - -means: -"Is a smaller than b? If that's the case return 1, if not, return 2" -``` - -We could have written a whole nestation of if-statements for it but why -do that if we can just write one line. - -The next line calls "changeZoom" which is a method that we have yet to -implement and gives it the newZoom value, as well as the latest -mouse-pointer-coordinates. This means that the picture will zoom towards -the mouse, like in any decent game. If you wanted it to zoom towards the -center of the screen you could use this. - -``` {.lang:java .decode:true} -changeZoom(newZoom, Gdx.graphics.getWidth() / 2, Gdx.graphics.getHeight() / 2); -``` - -Now let's have a look at what we need to do in the changeZoom(. . .) -method we have yet to write. - -- We need to log the current screen position to translate the screen - by amount x and y to fit the new zoom position -- We need to check if zoom should be applied (aka if inside the zoom - boundaries) -- Apply the zoom, update the camera and check the new camera position -- Then calculate how to move the camera to its new position - -So there will be a tiny tiny delay between zooming and panning to a side -but in practise it's not noticeable. So let's get to work. - -First you should add another vector to the list, this time just a -Vector2, that will hold our zoom boundaries for us. I just went with two -hardcoded values that I found worked out quite well in practise. But -you're free to experiment around. - -``` {.lang:java .decode:true} - /* x = min, y = max */ - Vector2 zoomBounds = new Vector2(0.45f, 0.75f); -``` - -Next up, we can go create our method and tackle the first two bulletins -on our list. - -``` {.lang:java .decode:true} - public void changeZoom(float zoom, float x, float y) { - - Vector3 before = new Vector3(x, y, 0); - camera.unproject(before); - - if (zoom <= zoomBounds.x || zoom >= zoomBounds.y) { - return; - } - } -``` - -Returning from a void method with no value will just jump out of the -method. It's an easier why than to nest the entire algorithm into an if -or the following else-statement. The statement just checks if the zoom -value that we pass into the method. - -Now that we've shown that the zoom is valid we can apply it and update -the camera. Then we can store the new location vector, unproject it and -afterwards translate the camera from the old position to the new by -subtracting the two vectors and thus getting the connection vector. - -``` {.lang:java .decode:true} - camera.zoom = zoom; - camera.update(); - Vector3 after = new Vector3(x, y, 0); - camera.unproject(after); - - camera.translate(before.x - after.x, before.y - after.y, 0); -``` - -Go ahead and try that for a bit. You'll see that the camera won't zoom -past our barriers which means that the player can be focused on their -ship and the environment at times and still zoom out a bit and get some -sort of overview. It was important to having implemented this first -because now we're gonna tackle the much harder subject of scrolling -around (by clicking and dragging) and also setting boundaries around the -map that limit the player from scrolling past our beautiful star map and -into the nothingness that is the white background colour :O - -Start by adding two more methods: touchDragged, touchUp and update(). - -``` {.lang:java .decode:true} - @Override - public boolean touchDragged(int x, int y, int pointer) { - camera.unproject(current.set(x, y, 0)); - return false; - } - - @Override - public boolean touchUp(int x, int y, int pointer, int button) { - return false; - } - - public void update() { - - } -``` - -And start by setting the current vector to the x and y values passed -into the method as they'll be updating the current vector. Then -unproject that bad girl to get the world coordinates of the actions. - -Next we want to check if we've already dragged. And that's why I wanted -you to give the last vector the value (-1,-1,-1) because this now allows -us to use this value as a flag. See, because we're only using 0 in the -z-dimention we can assume that if it's set to -1 it's one of our flags. -So go ahead and check if last is (-1,-1,-1) and if it is NOT! set the -delta vector to the last coordinates and unproject that as well. - -``` {.lang:java .decode:true} -if (!(last.x == -1 && last.y == -1 && last.z == -1)) { - camera.unproject(delta.set(last.x, last.y, 0)); - } -``` - -Afterwards add two more things: we want delta to be the difference -between the last point and our current point, so we need to subtract the -two. And lastly we want to apply that manipulated delta vector to the -camera so that it actually moves from our last position to the current -position (on the delta vector). (Full if-statement to prevent confusion, -I will add the full code again afterwards. This is really non-trivial). - -``` {.lang:java .decode:true} - if (!(last.x == -1 && last.y == -1 && last.z == -1)) { - camera.unproject(delta.set(last.x, last.y, 0)); - delta.sub(current); - camera.position.add(delta.x, delta.y, 0); - } -``` - -After we're done with this we want the last vector to be set to our -current coordinates because in the next call those need to be updated -(as current will have been updated to our next position). Then we return -with false because we want the event to trickle through every listener -we have. What is that? I know...I'm getting ahead of myself, I will -explain that in a bit! - -Now we can scroll around the camera but there is one thing we need to do -and that is set last to (-1,-1,-1) again so that it can't activate the -if-statement on the first call of touchDragged and gets assigned with -the current coordinates. - -``` {.lang:java .decode:true} - @Override - public boolean touchUp(int x, int y, int pointer, int button) { - last.set(-1, -1, -1); - return false; - } -``` - -And here the full touchDragged(. . .) again as reference. - -``` {.lang:java .decode:true} - @Override - public boolean touchDragged(int x, int y, int pointer) { - camera.unproject(current.set(x, y, 0)); - - if (!(last.x == -1 && last.y == -1 && last.z == -1)) { - camera.unproject(delta.set(last.x, last.y, 0)); - delta.sub(current); - camera.position.add(delta.x, delta.y, 0); - } - last.set(x, y, 0); - return false; - } -``` - -Now...if you try this out you'll see that we can zoom and scroll around -on our lovely landscape. But the problem is that there are no bounds to -keep us inside the landscape and the player can easily scroll too far -and see the white background. Yikes. - -To fix this we need to go back to our main game class for a second and -change the render() method a tiny bit. - -``` {.lang:java .mark:6-7 .decode:true} - @Override - public void render() { - Gdx.gl.glClearColor(1, 1, 1, 1); - Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT); - - handler.update(); - camController.update(); - - batch.setProjectionMatrix(camera.combined); - batch.begin(); - space.draw(batch); - player.draw(batch); - batch.end(); - } -``` - -What did I do here? I stopped updating the camera in the render method -but instead started calling that update() method we created in the -CameraController. We could of course have this code in the render method -but it's good practise to not cluster that thing up too much. Go back to -the camera controller and add that camera.update() call to the update() -method again so that we don't break everything. - -And that's the point where I will once again bore you with mathematical -theorems. (Actually it's not too bad). The subject at hand is clamping. -For everybody familiar with this, go ahead and skip this paragraph. For -everybody that is not, let me quote Wikipedia for you: - -*"In computer graphics, clamping is the process of limiting a position -to an area. Unlike wrapping, clamping merely moves the point to the -nearest available value."* - -So essentially we have a method called clamp(value, min, max); and the -method tries to keep our value between the minimum and the maximum. In -LibGDX this is done by calling the MathUtils class and asking for (the -drunken) clamp. - -We will be clamping the cameras x and y position manually but we have -another problem. See...we have our origin in the bottom left, but the -camera position is measured at its center. And because we're zooming in -and out the center doesn't always have the same position. So we need to -adjust the boundaries for the camera dynamically. And we can do that by -taking the size of the screen, multiplying it with the camera zoom and -then dividing it by 2 to get the center. - -In code example. - -``` {.lang:java .decode:true} -camera.position.x = MathUtils.clamp(camera.position.x, (Gdx.graphics.getWidth() * camera.zoom) / 2, max); -``` - -Now..for the maximum, we want the camera to stop on the other side of -the texture, so we need to get the size of the texture from the -ResPacker. But we also need to take the same offset we added to the -minimum, because the center is still moved to its center. So instead of -adding to "0" we now subtract from the size of the texture. - -``` {.lang:java .decode:true} -ResPack.WORLD_BACKGROUND.getRegionWidth() - (Gdx.graphics.getWidth() * camera.zoom) / 2 -``` - -And that's that. Here is the full code if you wanna check that you did -it right. Of course we want to do this for both the X and the Y axis and -we of course want to take the HEIGHT for the Y axis, not the width -(looks at self in shame after not having found a bug with this). - -``` {.lang:java .decode:true} - public void update() { - camera.position.x = MathUtils.clamp(camera.position.x, (Gdx.graphics.getWidth() * camera.zoom) / 2, - ResPack.WORLD_BACKGROUND.getRegionWidth() - (Gdx.graphics.getWidth() * camera.zoom) / 2); - camera.position.y = MathUtils.clamp(camera.position.y, (Gdx.graphics.getHeight() * camera.zoom) / 2, - ResPack.WORLD_BACKGROUND.getRegionHeight() - (Gdx.graphics.getHeight() * camera.zoom) / 2); - camera.update(); - } -``` - -is now our update method and it's glorious, isn't it? Try it out and -marvel at our limitless glory and genius. And then realise that you can -no longer move the ship. Well....remember? We kinda replaced the -InputAdapter as our InputProcessor. But don't worry, there is a way -around it! Remember when I spoiled you a few lines ago with trickle down -something? Well..turns out that LibGDX offers you a way to add multiple -InputProcessors with something called a *Multiplexer*. - - - -Go into our main game class and add a new Object - -``` {.lang:java .decode:true} -private InputMultiplexer plex; -``` - -And then in the create() method. - -``` {.lang:java .mark:6,12-14 .decode:true} - @Override - public void create() { - - . . . - - plex = new InputMultiplexer(); - - handler = new InputHandler(player); - camController = new CameraController(camera); - - /* Input Controllers */ - plex.addProcessor(camController); - plex.addProcessor(handler); - Gdx.input.setInputProcessor(plex); - } -``` - -Adding the CameraController first will give it a higher priority in the -MultiPlexer. Meaning that it will first trigger the events in the -CameraController and then trickle down to the other controllers. That's -why I didn't want to return true in our drag-methods because that would -stop the event and not pass it onto the next InputProcessor. - -And that's that, compile this and you'll see that you can fly the ship -around and drag the camera over the map at the same time. And this is -where I'll end this tutorial, I think I've loaded your brain with enough -new stuff right now. - -Next time I want to take a look at actual gameplay. Letting the camera -pan after the ship, letting the ship also have boundaries (same as the -camera) and placing those other textures I made around in the world, as -well as some well needed refactoring if we're gonna expand our feature -list. But until next time, keep coding! diff --git a/teaching/gameofcode/06-libgdx-game-of-codes-creating-a-world-more-refactoring.md b/teaching/gameofcode/06-libgdx-game-of-codes-creating-a-world-more-refactoring.md deleted file mode 100755 index 3b44c52..0000000 --- a/teaching/gameofcode/06-libgdx-game-of-codes-creating-a-world-more-refactoring.md +++ /dev/null @@ -1,333 +0,0 @@ -Title: 06. (LibGDX) Game of Codes: Creating a world & more refactoring -Date: 2014-01-10 22:30 -Category: Game of Codes -Tags: Guides -Slug: 06-libgdx-game-of-codes-creating-a-world-more-refactoring -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we learned how to write a camera input -processor (which is really just like a normal input processor) and do -some freaky matrix calculations in order to move around. In this issue I -want to go back to the roots (so to say) and work on features. Our code -is already pretty slick but I think it can be improved in order to make -room for more features. Let’s begin! - -First off we should change a few things in our Entity class. Remember -that EntityType that I added despite you shaking your and saying "what -the hell is she up to again?" Well...go in there and add some more -values into the enum. And also create a public getter for the type and a -private setter. This is only a temporary solution, in the long run we -want things to be saved in a database. But it'll do for now! - -``` {.lang:java .decode:true} - public static enum EntityType { - PLAYER, ENEMY, STATION, PLANET, STAR; - } - - . . . - - public EntityType getType() { - return type; - } - - private void setType(EntityType type) { - this.type = type; - } -``` - -Right now we only have one station, one planet and one star. So if we -ever decide to create more bodies we'll have to come up with a new -system (Plot twists: I already have, I'm just not telling you ;) ) - -Next up we want to do something else. Go ahead and create a new package -called objects (Remember to name it with the full package-tree so that -it's a child of "libgdxtutorial" and not "src") We'll use this package -to store all our gameplay objects in here. Go ahead and drag the -"Entity" into it as well before creating a new class called "World". - -This is what your project tree should look now. Well...more or less. - - - -Our world class will have an overview of all entities in existence, -coordinate collision detection with the player (later maybe between -non-player entities as well) and generally just know everything -important. For that to work we need to give it all the entities there -are. So go ahead and create a new Set and a few methods to actually use -those. My code, as always, as reference below. - -``` {.lang:java .decode:true} -package de.spacekookie.libgdxtutorial.objects; - -import java.util.HashSet; -import java.util.Set; - -import com.badlogic.gdx.Gdx; - -public class World { - - private Set entities; - - public World() { - entities = new HashSet(); - } - - public Set getEntities() { - return entities; - } - - public Entity getEntitityWithType(Entity.EntityType type) { - for (Entity e : entities) { - if(e.getType() == type) - return e; - } - return null; - } - - public void addEntity(Entity e) { - if (!entities.contains(e)) - entities.add(e); - else - Gdx.app.log("World", "Entity already in Set!"); - } - - public void removeEntitity(Entity e) { - if (entities.contains(e)) - entities.remove(e); - else - Gdx.app.log("World", "Error! No such entity in world!"); - } -} -``` - -The constructor just initializes the HashSet, we have a few getters and -setters, a way to individually add a single entity (e.g. if we're -spawning a pirate ship, maybe?) We'll be expanding on this code heavily -in the future but it's as complex as it needs to be right now. (Note how -I'm using Gdx.app.log to log two cases when adding and removing -entities. That's not required but it's a good way to keep tabs of -potential errors when playing the game or debugging something.) - -Next, we should go into our main game class and start using the World -object. Make sure to actually use OUR world object, not the Box2D world -(which is great for physics and lighting and we might use it later but -not right now!) - -``` {.lang:java .decode:true} - world = new World(); - world.addEntity(new Entity(EntityType.PLAYER, new Vector2(200, 150))); -``` - -And we of course need to teach our InputProcessor to use the world to -handle input! - -``` {.lang:java .decode:true} - handler = new InputHandler(world); -``` - -And in the InputHandler we need to change the constructor and some -methods. - -``` {.lang:java .decode:true title="Constructor"} - public InputHandler(Object o) { - - if (o instanceof World && o != null) - this.world = (World) o; - - if (o instanceof Entity && o != null) { - this.e = (Entity) o; - return; - } - - for (Entity e : world.getEntities()) { - if (e.getType() == EntityType.PLAYER) { - this.e = e; - } - else { - Gdx.app.log("InputHandler", "NO PLAYER IN WORLD!"); - } - } - } -``` - -(Be sure to rename the entity in that class to "e") - -And that should be all the changes we need to make. If I missed anything -or something is unclear, just leave me a comment below and I'll get back -to you. If you compile this it should still be the same game as before, -with the difference that under the hood it has a lot more horsepower -(kilowatts) and we'll be able to do some really cool things with this in -a moment. - -Here is an idea. Why don't we go ahead and plan our solar system a -little. I know, I know, you're lazy again. I get it. You just wanna read -these, absorb the knowledge via a USB3 port in your skull and eat -Cheerios all night. Still. I hope you can be bothered to check out the -picture below :) - - - -You can see the background image that is currently our game world and -our other objects scattered around the world. The grid lines in -Photoshop (Adjustable under Preferences --\> Guides, Grids & -Sliders --\> Grid) will give us a little help when trying to find places -to place these objects. But for that to happen we need to add a little -more to our Entity class. - -See, right now we just check if the EntityType is the player and if it -is we draw the space ship. But what we really want to do is also take a -set of coordinates in the constructor to pass down to the rendering. In -fact, we kinda want the pixel coordinate to be saved in the object -itself rather than having to check the sprite for information. Because -that's what the object is for, to hold all the information needed and -provide a sort of "interface" to access and store the information. We -don't want to be digging around in a sub-object or OpenGL logic object -to get information. - -So I added a new vector called position, created a new constructor that -now also takes a vector (left the old one to not break things) and -created a method called "updatePosition()" that takes the position -vector and gives the coordinates to the sprite. - -``` {.lang:java .decode:true} - private Vector2 position; - - public Entity(EntityType type) { - this.type = type; - moveVector.scl(speed); - position = new Vector2(); - } - - public Entity(EntityType type, Vector2 position) { - this.type = type; - this.position = position; - moveVector.scl(speed); - updatePosition(); - } - - public void updatePosition() { - self.setPosition(position.x, position.y); - } - - . . . - - public Vector2 getPosition() { - return position; - } - - public void setPosition(Vector2 position) { - this.position = position; - } -``` - -Next up we want the loadResources method to be able to not just load the -ship textures but check all the EntityTypes and load textures -accordingly. For that I changed the whole thing to a Switch statement. -If you're not familiar with Switch...get familiar with -[Switch](http://docs.oracle.com/javase/tutorial/java/nutsandbolts/switch.html). -It's awesome! - -``` {.lang:java .decode:true} - public void loadResources() { - switch (type) { - case PLAYER: - self = new Sprite(ResPack.SHIP_IDLE); - break; - case PLANET: - self = new Sprite(ResPack.WORLD_EARTH); - self.setScale(2f); - break; - case STATION: - self = new Sprite(ResPack.WORLD_STATION1); - self.setScale(1.5f); - break; - case STAR: - self = new Sprite(ResPack.WORLD_SUN); - self.setScale(2f); - break; - - default: - Gdx.app.log("Entity", "EntityType not found!"); - break; - } - } -``` - -I added the "setScale" in order to simulate size. A star should -be \*slightly\* larger than a space station. This is only a temporary -measure but I think it'll look better this way. You can of course leave -it out. - -There is one thing we'll have to do to restore the game as it was before -and that is to actually use the "updatePosition" method that we created. -So in the input processor, instead of calling "setPosition" on the -sprite we should use our object methods. - -``` {.lang:java .decode:true} - if (moving) { - Vector2 temp = new Vector2(e.getPosition().x, e.getPosition().y); - temp.add(e.getMovement()); - e.setPosition(temp); - e.updatePosition(); - e.fly(); - } -``` - -So far so good. Our code can now handle different types of objects, -though we will still need to create the objects at some point. And -because we want the world to keep tabs on everything going on we'll have -to update some code in our world method. See, we can add entities by -calling that 2nd lovely constructor and passing them into our world -object. We do that by calling. - -``` {.lang:java .decode:true} -world.addEntity(new Entity(ENTITY_TYPE, ENTITY_POSITION)); -``` - -Where Type and Position are of course one of our lovely EntityTypes that -we defined and the position is a Vector2 object. And where will we use -this dark magic you ask? Well simple. Where do we already add the player -to our world. - -``` {.lang:java .mark:8-10 .decode:true} - @Override - public void create() { - float w = Gdx.graphics.getWidth(); - float h = Gdx.graphics.getHeight(); - - world = new World(); - world.addEntity(new Entity(EntityType.PLAYER, new Vector2(200, 150))); - world.addEntity(new Entity(EntityType.STATION, new Vector2(600, 300))); - world.addEntity(new Entity(EntityType.PLANET, new Vector2(1200, 600))); - world.addEntity(new Entity(EntityType.STAR, new Vector2(650, 750))); - } -``` - -In our main game create() method. Now render this and marvel at its -glory. You can of course change the coordinates. Note that those are -camera-world coordinates, not pixel-coordinates. Compile this, it -shouldn't throw any errors. (Unless I forget to mention something in the -post ;) - - - -And well...that's it for this time, really. I hope that you learned a -thing or two and have also seen that the BEST way of implementing a new -feature is often to take a step back, look at the big picture and then -think about how it would be easiest to do something. Next issue I want -to show you how to UI which is an important thing when it comes to -creating a game. Also note, that all of my source code can be viewed on -my open repository on -[BITBUCKET](https://bitbucket.org/LaGemiNi/star-chaser "BITBUCKET") (which -is the name I've given to this name). There is also a video on my -[youtube](http://www.youtube.com/watch?v=ocYqXyM9v2Y "youtube") channel -from a week ago or so. Go check both things out. - -Sorry that it took me a bit longer to get this one out. I had a lot on -my plate the last week. I'll try bring out two posts on here per week. I -have something slightly special planned for next Tuesday. Hint, it -involves a lot of hardware, FreeBSD and a RAID :) - -But until next time, keep coding! diff --git a/teaching/gameofcode/07-game-of-codes-user-interfaces-and-the-power-of-scene2d.md b/teaching/gameofcode/07-game-of-codes-user-interfaces-and-the-power-of-scene2d.md deleted file mode 100755 index c3d76d0..0000000 --- a/teaching/gameofcode/07-game-of-codes-user-interfaces-and-the-power-of-scene2d.md +++ /dev/null @@ -1,359 +0,0 @@ -Title: 07. (LibGDX) Game of Codes: User Interfaces and the power of Scene2D -Date: 2014-01-14 21:31 -Category: Game of Codes -Tags: Guides -Slug: 07-game-of-codes-user-interfaces-and-the-power-of-scene2d -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we added new features to our game and -learned that the best step forward is often a step to the side (or back) -to get a view over what's going on. In this tutorial I want to show you -something that has absolutely nothing to do with features but will be -among the most important things in the game: the UI. We'll talk about -stages (like the acting stages, not rocket stages), UI elements and -something called Scene2D. Let's begin! - -Any game will be composed of several layers. In the background you want -to draw a map or textures to let the players know where they are -(relatively). In the actual scene you want to draw all sorts of objects -including the player themselves to show what's going on. And in the -foreground you want to draw the UI with which the player can interact to -manipulate the game. Sure, we already have our input listeners set up in -a way that we can manoeuvre around our ship. But what about a UI? -Buttons? An inventory? This is something we'll tackle in this tutorial. -It's gonna be a long one too so be sure to bring some time and maybe -re-read it at a later point again. - -In LibGDX we can use a UI-package called "Scene2D" which is perfect for -anything UI. It uses a layer of our game called the "Stage" that will be -populated by "Actors". In the beginning we'll stick with standard actors -but we can soon expand and write our own Actors by expanding that -superclass and doing own things with it. The stage will gladly welcome -our new Actor object into its ranks and manage everything there is to -manage about it. Just like our world-class. So you can see that it's -always a good idea to implement a managing parent class, followed by a -bunch of child objects. - - - -But before we get some stuff done with Scene2D and the stage I need to -explain you a few things about skins. A skin is a way to tell the game -how a UI should look. It includes fonts, graphics and textures to -describe how things have to be drawn. And creating beautiful skins is a -tutorial of its own (with which I'm honestly not very familiar. I'm a -programmer, not a designer ;) ). But luckily the creators of LibGDX -provide us with a standard skin that we can just download and use. It's -not exactly pretty and I wouldn't recommend using it in your games end -release. But it'll get the job done until then. And if you at a later -stage decide that you want to use your own skin, you will only have to -change the skin files and everything else remains the same. Pretty cool, -eh? - ------------------------------------------------------------------------- - -So first off we'll need some files that make up the skin: - -[A -FONT](https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-android/assets/data/default.fnt) - -[AND IT'S -RESOURCE](https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-android/assets/data/default.png) - -[A TEXTURE -FILE](https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-android/assets/data/uiskin.png) - -[AND IT'S -ATLAS](https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-android/assets/data/uiskin.atlas) - -[A JSON -FILE](https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-android/assets/data/uiskin.json) - -(To actually download the text-files just view their content in "Raw" -and copy them into a text editor of your choice. However use something -that let's you set your own file types. TextWrangler or TextMate on macs -and Notepad++ on Windows) - ------------------------------------------------------------------------- - -Download these from the LibGDX github repository. In general, if you're -ever stuck or want to look at some samplecode or just get to know what's -under the hood of the latest nightly build, check the github repository -for answers. It's a great tool! Put them all into a new folder in your -assets directory called "Skin" or something and then go into your -Resource packer class and create a new public final static object there. - -``` {.lang:java .decode:true} - public static final Skin _SKIN = new Skin(Gdx.files.internal("data/skin/uiskin.json")); -``` - -And that's that. LibGDX will do the rest. From now on, every time we -want to use anything related to the UI we will have to pass in this skin -to make it work (and look the same as the rest of the game). Now we'll -be doing some stuff in LibGDX's Scene2D. It's all very basic but -necessary to understand. Again...I might not cover everything. But if -you google "Scene2D + anything" you'll find your answers quite quickly. -90% of coding: googling how to do things :) - -Basics of Tables ----------------- - -We'll want to go into our main game class and create a new object called -"Stage". Make it private and initialize it just after the camera. And -then set the viewport in the resize method. Confused? Look below. - -``` {.lang:java .decode:true} - /** UI */ - private Stage stage; - - @Override - public void create() { - - . . . - - /** UI */ - stage = new Stage(); - - . . . - - } - . . . - - @Override - public void resize(int width, int height) { - stage.setViewport(width, height); - } -``` - -This way the stage will be resized every time we resize the viewport of -the game. Which currently is only at launch because we don't allow for -user resizes. But that could change. That's a pretty good idea, we -should actually do the same with our camera. So remove our two variables -"w" and "h" and move "camera.setToOrtho(...)" to the resize method so it -looks like this. - -``` {.lang:java .decode:true} - @Override - public void resize(int width, int height) { - stage.setViewport(width, height); - camera.setToOrtho(false, width, height); - } -``` - -Now...enough spontanious refactoring, let's actually get into our -tables. The stage itself is an invisible object, much like our world. It -won't draw anything unless we actually add some actors and then act out -the stage in our render method. - -Why don't we create a button that says "Menu" in the top-right corner? I -think that's a nice start to our UI and actually useful. In LibGDX there -are many button implementations, including some with pictures and an -abstract type that you can implement your own types on. But the regular -"TextButton" is sufficient for us at this time. So go create a global -variable of the type TextButton, give it a name and then, after -initializing the stage, initialize the button. How? Like this. - -``` {.lang:java .mark:1,10 .decode:true} - private TextButton menu; - - @Override - public void create() { - - . . . - - /** Setting up the UI */ - stage = new Stage(); - menu = new TextButton("Menu", ResPack._SKIN); - - . . . - } -``` - -You can see that the button wants a string to display on itself and of -course a skin. So far so good. But how do we tell it to go to the -top-right corner of the screen? Well...that's not so simple and I -actually want to show you this way first so you NEVER think about doing -this manually again :) We will need to take the size of the stage and -then substract the size of the button from it and set that as its new -position. - -``` {.lang:java .decode:true} - menu.setPosition(stage.getWidth() - menu.getWidth(), stage.getHeight() - menu.getHeight()); - stage.addActor(menu); -``` - -Pretty complicated, eh? That second line adds the menu-button to the -stage. It's essentially the same thing that we're doing with our world: -creating a bunch of objects and passing them into a large-scale manager. -But, if you remember correctly, our world needs something in the render -method to work. And the same applies to our stage. First we need to act -out the stage which means moving things that need to be moved, animating -things that need to be animated, etc. And then draw the stage. So in our -render method we add. - -``` {.lang:java .decode:true} - stage.act(); - stage.draw(); -``` - -Be sure to put this at the very bottom of our rendering so that it ends -up on TOP of our stack. (Laying a stack of papers, the sheet you put -onto it first will be on the bottom (the background) while the one you -put on last will be on top (the UI). - - - -Now compile this and marvel at its glory. Well...kind of. See...when we -now need to add a second button to that menu maybe titled "Inventory" -we'll have to do very complicated mathematics in order to line up the -buttons. Which isn't great and which is why Tables were created. - -Just after creating your button, why don't you go and create a "Table" -object, initialize it after the stage and then add the button to the -table and the table to the stage. - -``` {.lang:java .mark:1,10,12-13,16 .decode:true} - private Table buttons; - - @Override - public void create() { - - . . . - - /** Setting up the UI */ - stage = new Stage(); - buttons = new Table(ResPack._SKIN); - - buttons.setFillParent(true); - buttons.top().right(); - - menu = new TextButton("Menu", ResPack._SKIN); - buttons.add(menu); - - stage.addActor(buttons); -``` - -So instead of adding the button to the stage we add it to the table, we -tell it to fill its parent (which is important for the validation of the -table during render) and then call "top" and "right"...see, instead of -working with pixel coordinates here we can just tell the table to go to -any corner of the window (center, top, bottom, left, right). And the -coolest thing is that the table will try to stay on-screen, even if we -add more buttons. Let's do that now honestly, create a new button called -"Inventory" and add it to the table just as the menu button. Note that -the table will be populated from left to right meaning that if you want -the Inventory button to be to the left of the menu button you'll have to -add it first. - -And that's that for tables for now. There are more advanced things -concerning tables but I won't cover them here (and now). If you're -curious or this isn't specific enough for what you have planned, why -don't you go [here](https://github.com/EsotericSoftware/tablelayout) and -read about it :) - -Handling input --------------- - -Something you might have noticed is that our current buttons don't react -to any kind of input. That has to do with the fact that we never -register the stage as an input processor. Usually you call -Gdx.input.setInputProcessor(stage) but as we already have an input -multiplexer set up we can just add the stage to that. - -``` {.lang:java .decode:true} - plex.addProcessor(stage); -``` - -And voila you'll see that the buttons now react to our clicks, even with -just a red glow. Because to actually HANDLE the input we need something -to listen to it. In our input processors we have listeners to certain -events, like moving the mouse or pressing a certain button. And we use -these events to manipulate our game. For the UI it's no different. -Well...it's slightly different. We don't want to create a UI -InputProcessor. It's not only completely ridiculously complicated but -actually inadvisable. Instead we'll set up the listeners for each button -manually in our game class and tuck them away in a method somewhere at -the bottom of the class to be out of sight and out of mind. - -``` {.lang:java .decode:true title="Clicklistener - innertype"} - private void setupListeners() { - menu.addListener(new ClickListener() { - - public void touchUp(InputEvent event, float x, float y, int pointer, int button) { - Gdx.app.log("Stage", "Menu button pressed"); - } - }); - } -``` - -What you see above is known as an inner-type. If you've worked with my -Android series before you'll know them. it's essentially a way to create -a class inside another class (in the parameter brackets of a method) to -define how a passed down to the "addListener" method. - -The ClickListener extends the InputListener where we can manually -override one of the listeners. In my case I decided to override the -"touchUp" method with all the parameters it takes and log the case. Now -create a second listener for the second button, just as the one I showed -you above. Compile it and see what happens. Pretty cool, eh (again)? - -Okay, maybe not that cool. Initially I wanted to go on here and make -options and inventory screens but I think we should do this at a later -time because it would take hours and not really have anything to do with -Scene2D anymore. Let's just check out some other elements we have in -Scene2D before wrapping this up. - -So create a new table with a name of your choosing and add a few thing -to it. - -``` {.lang:java .decode:true} - temp = new Table(ResPack._SKIN); - temp.setFillParent(true); - TextureRegionDrawable trd = new TextureRegionDrawable(new TextureRegion(new Texture( - Gdx.files.internal("graphics/image_button.png")))); - imageButton = new ImageButton(trd); - checkbox = new CheckBox("This is a checkbox", ResPack._SKIN); - field = new TextField("This is a textfield", ResPack._SKIN); - - temp.add(imageButton); - temp.row(); - temp.add(checkbox); - temp.add(field); - temp.top().left(); - stage.addActor(temp); -``` - -Oh boy, I know. Let's go trough it line by line. Temp is just a table -that we set to fillparent = true. The next thing we do isn't really -important for now, just note that we're doing it. A -TextureRegionDrawable extends a Drawable that we need for our button. -Ideally you want to have all your button images in your skin. But the -default skin doesn't. So because I didn't want to add stuff to the skin -I went with the "hard" but quick way. Afterwards we initiate a checkbox -and a textfield. - -[](http://www.spacekookie.de/wp-content/uploads/2014/01/image_button.png) - -Note how we're adding things to the table and using "row()" only once. -Each time you call row() it will create a new row. So in effect the -first item will be on it's own row and then the checkbox and textfield -on another. If you put another row between them that will change of -course. Above you have the button image that I used. Go import that into -your project if I want it to work OR of course just create your own -Button image. - -I hope that this tutorial has shown you how powerful Scene2D can be. -With just a few lines of code we created a whole layout and added -listeners to it. The process remains that easy and you ca of course -still add and subtract offsets to tables to fine-tune their position. If -you have further questions about Scene2D, go ahead and post them below. -But in general the API is relatively well documented and if you have -questions you can always check out the LibGDX forums or the IRC. - -Thats it for today, I'll continue with this next time but we'll have our -focus on something called Screens. They're nifty little things that can -make our life a whole lot easier (and more difficult actually ;) ). -I actually wanted to do something \*slightly\* different today (that -involved computer hardware) but I actually ordered a wrong part. So -that'll be delayed. Not sure when it'll come out. So until next time, -keep coding. diff --git a/teaching/gameofcode/08-libgdx-game-of-codes-screens-subscreens.md b/teaching/gameofcode/08-libgdx-game-of-codes-screens-subscreens.md deleted file mode 100755 index de696a9..0000000 --- a/teaching/gameofcode/08-libgdx-game-of-codes-screens-subscreens.md +++ /dev/null @@ -1,381 +0,0 @@ -Title: 08. (LibGDX) Game of Codes: Screens & Subscreens -Date: 2014-01-19 09:30 -Category: Game of Codes -Tags: Guides -Slug: 08-libgdx-game-of-codes-screens-subscreens -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last edition we looked at user interfaces with Stages -and Scene2D. Today I want to show you how to make your game a LOT better -and more functional by adding *Screens *(I already spoiled this last -tuesday ;) ). Let's begin! - -First of all we should take a step back and look at our game. We have -our main-game class that currently extends "ApplicationListener" and -does a whole lot of stuff. It's the main game loop, it populates and -updates the world and handles input. So essentially it's a class that is -tied into everything that LibGDX does to make a game runnable. Well...an -"Application". That's a very broad term and there is another subclass of -that main class that we currently extend, that we need to use in the -future. it's almost the same as the ApplicationListener but \*slightly\* -different. And we need that. The class is called "Game". So what I want -you to do now is go into the main "Game" class and change the extend -from "ApplicationListener" to "Game". In my case it's the line below. - -``` {.lang:java .decode:true} -public class StarChaser extends Game { -``` - -Eclipse might give you some trouble with implementing the new methods. -Usually you just have to clean your project (Project --\> Clean --\> -All) and it'll calm down. In the worst case scenario just copy all your -code into a different editor, delete all the code from the class (except -the class definition and package of course, let Eclipse import -everything for you again, implement the methods and then paste your code -into the methods it create (that will be EXACTLY the same as the ones we -had before. But you know...Eclipse is weird sometimes :) ). - -What did this get us? Well...if you added the sources to your Libraries -you can right-click that "extends Game" and show it's declaration to see -the Game class that we now extend. It extends the ApplicationListener -and adds something we want to use now: a *Screen!* - -A screen is a layer of our game. It gets shown, rendered, paused and -destroyed. It acts very much like a fragment on Android (if you're -familiar with the Android API) and can be an overlay or replacement of -the entire game. using screens is a much better solution in switching -between "screens" than creating new games or trying to use a lot of -booleans and flags to determine what part of which GUI is supposed to be -visible. - -So why don't you go and create a new package called "screens" and add a -new class to it and let it implement "Screen". I called mine -"MenuScreen". - -``` {.lang:java .decode:true} -package de.spacekookie.starchaser.screens; - -import com.badlogic.gdx.Gdx; -import com.badlogic.gdx.Screen; -import com.badlogic.gdx.scenes.scene2d.Stage; - -public class MenuScreen implements Screen { - - /** UI */ - private Stage stage; - - @Override - public void render(float delta) { - stage.act(); - stage.draw(); - } - - @Override - public void resize(int width, int height) { - stage.setViewport(width, height); - } - - @Override - public void show() { - stage = new Stage(); - } - - @Override - public void hide() { - - } - - @Override - public void pause() { - - } - - @Override - public void resume() { - - } - - @Override - public void dispose() { - - } - -} -``` - -This is what your class should look like (more or less). I took the -liberty of already adding a stage to it because we want to draw a menu -screen, something with buttons and text and the easiest way to do that -is with Scene2D (as we've learned in the last tutorial). - -Next up we'll want to populate that stage. I prepared something and am -just gonna paste it in here. You can arrange your buttons in whatever -order you want. I went for something very simple and centric. - -``` {.lang:java .mark:25 .decode:true} - @Override - public void show() { - stage = new Stage(); - - table = new Table(ResPack._SKIN); - - table.setFillParent(true); - table.center(); - - title = new Label("MAIN MENU", ResPack._SKIN); - title.setFontScale(2.5f); - - resume = new TextButton("RESUME GAME", ResPack._SKIN); - options = new TextButton("OPTIONS", ResPack._SKIN); - exit = new TextButton("RAGE QUIT", ResPack._SKIN); - - table.add(title).center().pad(25f); - table.row().height(75); - table.add(resume).center().width(500).pad(5f); - table.row().height(75); - table.add(options).center().width(500).pad(5f); - table.row().height(75); - table.add(exit).center().width(500).pad(5f); - stage.addActor(table); - Gdx.input.setInputProcessor(stage); - } -``` - -You should understand what I'm doing here and it's nothing more advanced -than what we did in the last tutorial. Except that I set a row height, -give buttons a specific size and add padding around them to make it look -more smooth. - -<span style="text-decoration: underline;">Note how we overwrite the -input processor from the main game to the stage. This means that the -game will be unresponsive, We'll have to change that back later!</span> - -So far so good. But what do we now actually do with this? We want to add -this screen to the main game class in a way that we don't have to create -new instances of it all the time. So go ahead and create a global -variable in the main game class and initialize it on create(). - -``` {.lang:java .decode:true} - /** Screens */ - private MenuScreen menuScreen; - - @Override - public void create() { - - . . . - - /** Setting up support screens */ - menuScreen = new MenuScreen(); - - . . . - } -``` - -And another global variable we'll have to create is "self" which has the -type of our main game class (which in my case is "StarChaser"). We can -do that by creating an object with the class name and initializing it -with the following. - -``` {.lang:java .decode:true} - private StarChaser self = this; -``` - -We will need this global variable in our click-listener, because -there the scope is different. See, while we can easily call "this" or -"super" in our main game class to access anything in the class or that -we inherit from, in the Clicklistener we're technically in a different -class (the ClickListener class) and thus we can't access things we -inherited outside of it. To circumvent this we add a global variable -that we can still see, access and Boya! - -In the ClickListener you can throw out the Log call and add this. - -``` {.lang:java .decode:true} -self.setScreen(menuScreen); -``` - -When you now compile this you'll see that you don't see anything. :) -Because we're not actually rendering the screen. For that to happen you -have to add this line of code to the bottom (the very end) of your -render() method (in the main game class that is). - -``` {.lang:java .decode:true} -super.render(); -``` - -This will ensure that if there is a screen visible that their -appropriate render method is being called at the right time (You can -look at the super-render() method when you look at the super-class. It's -sometimes interesting). - -Now compile this and see, that we have a neat overlay of our buttons -over the game. And we can no longer move our ship around and we're also -kinda stuck in that menu screen because we haven't set up any listeners -yet. Now...resetting the screen works in a very similar way: we take our -main game, call setScreen(null) on it and the screen will disappear. -However...we don't have that inheritance in our Screen object, do we? -No. So we'll have to pass it in via the constructor. - -So first we create a constructor in the MenuScreen class. - -``` {.lang:java .decode:true} - public MenuScreen(StarChaser self) { - this.parent = self; - } -``` - -And of course a global variable in the class called "parent" or -"cupcake" or whatever you want to store the information. Also make sure -to update the constructor call (in the ClickListener) from no parameters -to "self". - -With this new variable in our screen we can go ahead and create a new -Clicklistener for one of our lovely buttons. I only chose the "Resume" -one for now but we can add functionality to the other ones as we move -along with our game. - -``` {.lang:java .decode:true} - resume.addListener(new ClickListener() { - - public void touchUp(InputEvent event, float x, float y, int pointer, int button) { - parent.setupInput(); - parent.setScreen(null); - } - }); -``` - -You'll probably go "Woooah, easy there girl, what's that setInput()??" -and well...you're right. See, when we get back to our game and the -screen is hidden somewhere in memory we can't control the game anymore. -We haven't told our game yet that we want to resume using the input -Multiplexer so that we can actually control our ship again. - -For that to happen I created this public method that sets the input to -the Multiplexer and sets up the Stage-listeners (for our buttons). In -the main game simply call this method instead of the actual calls (so -after adding things to the Multiplexer). Because the InputAdapters still -exist in memory, we don't want to re-initialize them. That'd be a waste -of resources and memory. - -``` {.lang:java .mark:10,13-17 .decode:true} - @Override - public void create() { - - . . . - - /** Input Controllers */ - plex.addProcessor(stage); - plex.addProcessor(camController); - plex.addProcessor(handler); - this.setupInput(); - } - - public void setupInput() { - Gdx.input.setInputProcessor(plex); - this.setupListeners(); - } -``` - -And that's it. If you compile this you'll have a functional button that -takes you to the MenuScreen and back again when you press the -appropriate button. I hope you understand the logic behind this. We show -a screen, we use it, we hide it. Think of the screens like overlays that -you put over your main "game-layer". But just because we can -conveniently draw over our main layer that doesn't mean that we won't -have to change a few things, pass parameters along and manually reset -the input (as an example). LibGDX is a framework that allows for the -complicated stuff to be easy (the drawing a new screen over the current -game etc.). The rest is up to you, how you want to handle it, how you -want your game (or just application) to look. Below is a picture that -shows the current setup we have. - - - -Speaking of looks...I don't actually like how that menu screen is -looking. I'd much rather have it be semi-transparent in the background -so the game gets grayed out. Luckily that's easily possible. -Well...possible :) - -First you should create a Camera object in our MenuScreen and get the -camera from the main game in the constructor. (We already have a static -method called "getCameraInstance()" that we used a couple of issues back -for our input processor to do things. After that create a -"ShapeRenderer" and initialize it in the "show()" method. - -``` {.lang:java .mark:1,2,5,13 .decode:true} - private Camera camera; - private ShapeRenderer render; - - public MenuScreen(StarChaser self) { - this.camera = StarChaser.getCameraInstance(); - this.parent = self; - } - - . . . - - @Override - public void show() { - render = new ShapeRenderer(); - - . . . - - } -``` - -ShapeRenderers are used to draw very simple polygon shapes onto the -screen. In our case we want a rectangle, filled with a colour, that -spans over the entire screen (+10 pixels or so for border) and blends -the background colours with our colour that we give an alpha channel. -Confused? Don't worry, check out the code below (the new render method) -and then I'll go over it bit by bit. - -``` {.lang:java .decode:true} - @Override - public void render(float delta) { - - Gdx.gl20.glEnable(GL20.GL_BLEND); - render.setProjectionMatrix(camera.combined); - render.begin(ShapeType.Filled); - render.setColor(0, 0, 0, 0.5f); - render.rect(-10, -10, Gdx.graphics.getWidth() + 20, Gdx.graphics.getHeight() + 20); - render.end(); - - stage.act(); - stage.draw(); - } -``` - -First we have to call an OpenGL function called "glEnable" which will -enable certain features during render. We pass in the "GL\_BLEND" -parameter (in the GL2.0 package) which will trigger OpenGL to blend -colours together (so allowing two colours to merge slowly instead of -being absolute values). - -Afterwards we take the projection matrix from our camera and set it for -the renderer so that the drawn shapes are in the same reference frame as -the rest of our game. And then we begin the magic. - -We set the Type (Filled), we set a colour (black with 50% alpha), we set -the border (the screen + 10 pixels padding over the screen). And then we -end the renderer. That's it. - -Compile this and look at how it looks. In my opinion a lot better! For -reference, this is what my menu now looks like. Again...you can have -your buttons in different orders, sizes, whatever. - - - -But I hope you understand now how you can create different screens to -make have different tasks. And in the same way that we've now created -this Menuscreen we can make an options screen (We just need to pass -along the Game again and call "setScreen(whatever)" when we're done). - -And at some point I want to make an inventory and trade screen like -this. But that's a long way out. Because next up I actually want to do -some bug-fixing. Things that I missed a few "episodes" ago and thought -it'd be a good learning opportunity. And also teaching you about game -structure a bit more. - -I hope you enjoy this series so far, leave me your feedback in the -comments and I'll see you guys (and gals) next time. Keep coding! diff --git a/teaching/gameofcode/09-libgdx-game-of-codes-modifying-libgdx-part-i.md b/teaching/gameofcode/09-libgdx-game-of-codes-modifying-libgdx-part-i.md deleted file mode 100755 index 2555d2d..0000000 --- a/teaching/gameofcode/09-libgdx-game-of-codes-modifying-libgdx-part-i.md +++ /dev/null @@ -1,326 +0,0 @@ -Title: 09. (LibGDX) Game of Codes: Modifying LibGDX — Part I -Date: 2014-04-04 13:57 -Category: Game of Codes -Tags: Guides -Slug: 09-libgdx-game-of-codes-modifying-libgdx-part-i -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. It's been a while since my last post and I want to make up -for that today. Last time we were talking about Screens and subscreens -for a game that made showing new information a whole lot faster and more -intuitive as it didn't require more UI elements to be written into the -same class. - -Well…despite what you might think I HAVE been very busy coding on my own -project (\*hinthint\* -[www.spacekookie.de/projects/empires](http://www.spacekookie.de/projects/empires/ "Interstellar Empires") \*hinthint\* -;) ) and have started modifying the LibGDX core a few months ago to -better suit my needs. Well…most of my modifications are pretty specific -to my case. Changing the hexagon renderer to account for my custom data -types, changing the input handling method, etc... But in the last 2 -weeks I have done something that I think can be quite handy and I want -you to see it. Additionally I will be using that example to show you how -modding LibGDX to your own needs can be very productive and even fun. It -will give you the ability to learn and understand how that framework -we've only been using so far is structured and works. And it will remove -some of the magic that you might feel is involved ;) So shall we begin? - - - -First of all I want to show you a graphic again from my last post of the -Game of Codes. - - - -This is how I thought our menu would be, have a screen in front of our -game that then showed some stuff. Well…that's all nice and good IF you -only use one game-screen. But most games aren't that simple. Usually in -a complex game you want to have your background code for music and input -handling or whatever jazz you're doing running in your game but then -have different screens for the Menu, the game, the settings, maybe an -inventory? Who knows? And well…that's all very 1-dimentional. So what I -did first was look at how things were structured in LibGDX. - -``` {.lang:java .decode:true} -public abstract class Game implements ApplicationListener { - private Screen screen; - - . . . - - public void setScreen (Screen screen) { - if (this.screen != null) this.screen.hide(); - this.screen = screen; - if (this.screen != null) { - this.screen.show(); - this.screen.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight()); - } - } - - . . . -} -``` - -As you can see the "Game" class that we extend with our MainGame-Class -where we have our ship and station and input and all those lovely assets -implements the ApplicationListener, JUST as our MainGame-class did -before we started working with Screens. Oh and look! There is some of -that code that we use to set a Screen. - -Now…what can we do with this? Well first of all we can create a new -class in our Core package and call it "CustomGame" or anything you like. -But it should be clear that it's something very specific. Make it -abstract and let it implement the ApplicationListener interface, just -like the example above. - -We can also actually just copy most of that code in the stock-Game class -into our own. - -``` {.lang:java .decode:true} -public abstract class CustomGame implements ApplicationListener { - private Screen screen; - - @Override - public void create() { - - } - - @Override - public void resize(int width, int height) { - if (screen != null) - screen.resize(width, height); - - } - - @Override - public void render() { - if (screen != null) - screen.render(Gdx.graphics.getDeltaTime()); - - } - - @Override - public void pause() { - if (screen != null) - screen.pause(); - - } - - @Override - public void resume() { - if (screen != null) - screen.resume(); - - } - - @Override - public void dispose() { - if (screen != null) - screen.dispose(); - - } - - public void setScreen(Screen screen) { - if (this.screen != null) - this.screen.hide(); - this.screen = screen; - if (this.screen != null) { - this.screen.show(); - this.screen.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight()); - } - } - - public Screen getScreen() { - return screen; - } - -} -``` - -All that does is exactly what the other class did before. If you now go -into our main-game class and let it extend "CustomGame" instead of -"Game" and compile the game it will run JUST like it did before. Because -nothing has changed. And that's what we'll change RIGHT NOW. - -What do we want? Well…we want to use Screens in our game for the actual -game screens (menu, in-game, settings, cut scenes, etc.) as well as -Screens to display information OVER the current one (for example for an -Inventory screen or dialogue options or WHATEVER!). Now…there are two -things we could do right now: - -The first would be to only add one more screen, call it "overlay" and -copy the same code as for the other screen into the class. That would -give us two screens to work with. But I don't like that idea at all. -Instead I want to do something different. I want to be able to have a -stack of Overlays over each other. And that's why we'll use a -Stack\<Screen\>! - -``` {.lang:java .decode:true} - private Stack<Screen> overlays; - - @Override - public void create() { - overlays = new Stack<Screen>(); - } -``` - -Put this code under the declaration of the private Screen variable and -initialize the stack in your create() method that was (so far) not used. -Now we of course need to make sure we actually call "super.onCreate()" -in our child-class (So our main game-class). - -So far so good. But, we can't actually do anything with that yet. First -we will want to write two access methods for the stack. - -``` {.lang:java .decode:true} - public void addOverlay(Screen overlay) { - overlays.add(overlay); - overlay.show(); - overlay.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight()); - } - - public void removeOverlay() { - if (!overlays.isEmpty()) - overlays.pop().dispose(); - } -``` - -What this will do is add a new overlay to the stack when we need one and -also call the show and resize method on the overlay (which is really -just a screen) to set up everything correctly! -The second method will remove the last overlay (if it exists) by -popping it off the stack and calling dispose() on it to finalize. This -is important so that we avoid having un-used and non-removed resources -in our memory. - -So far so good. The problem now is that our screen won't actually be -shown anywhere. Sure, we add it to our stack and show() and resize() it. -But it's not getting rendered. For that to happen we'll have to add some -more code. And in addition to that I would recommend more code to then -dispose of the screens again as well. - -For every action that we take on our main-screen we need to add this -code to it as well. - -``` {.lang:java .decode:true} - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.ACTION_HERE(); -``` - -Essentially iterating over the stack to apply it to every overlay. This -way we can have stacking UI-overlays while the ones in the background -still get rendered. And this is how the final CustomGame class then -looks. - -``` {.lang:java .decode:true} -import java.util.Stack; - -import com.badlogic.gdx.ApplicationListener; -import com.badlogic.gdx.Gdx; -import com.badlogic.gdx.Screen; - -public abstract class CustomGame implements ApplicationListener { - private Screen screen; - private Stack overlays; - - @Override - public void create() { - overlays = new Stack(); - } - - @Override - public void resize(int width, int height) { - if (screen != null) - screen.resize(width, height); - - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.resize(width, height); - - } - - @Override - public void render() { - if (screen != null) - screen.render(Gdx.graphics.getDeltaTime()); - - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.render(Gdx.graphics.getDeltaTime()); - - } - - @Override - public void pause() { - if (screen != null) - screen.pause(); - - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.pause(); - - } - - @Override - public void resume() { - if (screen != null) - screen.resume(); - - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.resume(); - - } - - @Override - public void dispose() { - if (screen != null) - screen.dispose(); - - if (!overlays.isEmpty()) - for (Screen o : overlays) - o.dispose(); - - } - - public void setScreen(Screen screen) { - if (this.screen != null) - this.screen.hide(); - this.screen = screen; - if (this.screen != null) { - this.screen.show(); - this.screen.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight()); - } - } - - public Screen getScreen() { - return screen; - } - - public void addOverlay(Screen overlay) { - overlays.add(overlay); - overlay.show(); - overlay.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight()); - } - - public void removeOverlay() { - if (!overlays.isEmpty()) - overlays.pop().dispose(); - } - -} -``` - -This is it for part 1. I don't want to let this get too long so in PART -2 of this post I'll be showing you what exactly we can do with this. If -you have any questions or suggestions, leave them in the comments below. - -Until then, keep Coding! - - - -==== EDIT ==== - -Do you want this series to get picked up again? Go here: -http://www.spacekookie.de/continue-libgdx-game-of-codes/ diff --git a/teaching/gameofcode/09.5-libgdx-game-of-codes-continuation.md b/teaching/gameofcode/09.5-libgdx-game-of-codes-continuation.md deleted file mode 100755 index 964e05f..0000000 --- a/teaching/gameofcode/09.5-libgdx-game-of-codes-continuation.md +++ /dev/null @@ -1,28 +0,0 @@ -Title: 09.5 (LibGDX) Game of Codes: Continuation - Post ideas -Date: 2015-05-02 12:12 -Category: Game of Codes -Tags: Guides -Slug: continue-libgdx-game-of-codes -Status: published - -Welcome back to the Game of Codes, an introduction series to the LibGDX -framework. In the last post we started messing around with the inner -workings of LibGDX a bit more... - -\*static\* \*voice cracking\* \*buzzing from speakers\* - -"Hello? Can anyone hear me? I think I'm in space...Hello?" - -Right...it's been about a year since I wrote on this series, a lot of -things have changed and I don't nearly have as much time anymore. BUT -people keep messaging me all over the place that they liked my LibGDX -series. SO...if you really do, I will continue it. Though, I'm slightly -out of ideas what to do. And I really have lost interest in continuing -that Star Chaser thing I started. - -So....if you want to see something from me, post it on the comments -below, twitter at me, send me emails or smoke signals. If I get enough -feedback about this I will do it. If not, I'm sure there are better and -more up to date resources out there :) - -So yea, would be cool to hear from you guys \<3 diff --git a/teaching/gameofcode/10-libgdx-game-of-codes-shaders.md b/teaching/gameofcode/10-libgdx-game-of-codes-shaders.md deleted file mode 100755 index 083d0fb..0000000 --- a/teaching/gameofcode/10-libgdx-game-of-codes-shaders.md +++ /dev/null @@ -1,7 +0,0 @@ -Title: 10 (LibGDX) Game of Codes: 50 Shades of Code -Category: Game of Codes -Tags: Guides -Slug: libgdx-game-of-codes-50-shades-of-code -Status: draft - -SHADERS!
\ No newline at end of file |