William Mora

Thoughts a year+ into AI coding

Sun, 06 Sep 2026 00:00:00 +0000

It’s been more than a year since I fully transitioned to coding with AI and wanted to post some notes about it. This post is a bit of a braindump; I’ve been meaning to write more often about my experience building with AI this year, but things in the industry have evolved quite fast and I haven’t developed the discipline to keep up with writing about it.

My AI coding experience dates back to 2022, first with a mix of GitHub Copilot and ChatGPT which was decent but also it felt more like a Stack Overflow replacement. At the time, I was fortunate to be the Head of Engineering at Ada, an AI-native customer experience company that exposed me to what generative AI had to offer from early on.

Fast forward to early 2025, I had already transitioned to Cursor (at the time, I felt it was a more powerful autocomplete) and decided to try Cline, coinciding with the release of Sonnet 3.7. That was my first experience letting AI build an app while I was ~95% hands off coding. The app was a simple conversational interface to ask questions about a podcast based on its episode transcripts. While relatively simple, I was pretty convinced that it was doing a much better job than I could at a pace I could never match if I were to design and write everything myself.

Later in 2025, I put together a micro-SaaS as a side project to further test if I could build and fully package a product with AI coding, this time with Claude Code. The end result was looppractice, in a nutshell, a practice reminder system for guitar and bass players. I have worked on many side projects over my career, but this one was special in the sense that I was able to build more than an MVP on my own quickly and get my first paying customer. It’s still early as a product; I’ve been using it as a personal tool since inception and I have plans to evolve it further to a more complete companion for hobbyist musicians.

In early 2026, I decided to go all in building and exploring how much I can achieve as a product developer using AI. As a result, I was part of the wave of Head of Engineering/Engineering leads walking away from their roles. Being a builder at heart and having successfully led Ada Engineering through a major AI product and team rebuild, it felt like the right time to step back and spend more time as a developer working on a range of things from hobby apps to more critical products; this also felt like the right move if I ever want to go back to an Engineering leadership role. I wrote about my casual word game, Shuffled, that started as a quick experiment and has been refined a lot since then. As of this writing, I continue working on multiple side projects and consulting during my free time, while also being part of the Product team at myAbode working on a new AI product.

In terms of my development workflow, I went from one-session-at-a-time-on-VSCode-with-the-odd-manual-code-change to using an orchestrator pattern, first using Conductor and similar tools, but now using herdr and my own orchestrator solution (a similar in nature, but simplified, version of firstmate). The main reason I don’t stick to simply using the Claude or Codex desktop apps is that I rely heavily on cross-vendor collaboration for code review (Codex reviews Claude and vice versa), and while right now Fable is my main orchestrator, every now and then I like to switch to a Codex model as my driver while keeping the same dev experience. Overall, I just find it easier to continue adapting my workflow this way while I settle on a specific solution.

In this model, I find myself running up to 10-15 development tasks efficiently (some very complex, some very straightforward). By development task, I mean some end-to-end problem in which I’m the bottleneck and not necessarily a pure coding task. Mechanical work can easily spawn a lot more agents as long as the guardrails are well defined.

I’m still trying things out and refining my perspective on AI, and I think it’s the main takeaway. Models are getting increasingly better and keep taking on more complex tasks, while at the same time reaching an “intelligence plateau” in which there are tasks I simply know that if I don’t take over the output is a gamble. A few examples:

Authority on “business rules” can only come from me. While AI can come up with a solution to a problem, it’s too much of a gamble to let it decide on what the best outcome is. If I’m building for fun, prototyping, or working on something low-stakes in general then it’s fine to let AI go wild, but if I’m dealing with complex decisions, ambiguity anchored on real-world situations, managing production data, etc., not being on top of the work means things can really go sideways and end up being a time sink.
Product taste. No amount of written best practices beats human judgement when playing around with a prototype and understanding what works and what doesn’t. This is especially true in my little experience prototyping video games with AI.
Overall system design, quality, and tech stack choices. I’m still on the fence on whether to trust AI more with this one, and maybe it’s a level of abstraction that will evolve as more code is done with AI, but I find there’s a huge amount of over-engineering, siloed choices, and poor judgement that makes it hard to let AI fully solve the harder engineering problems without scratching my head thinking what were you thinking?.
Writing such as this one :). AI is a good editor to catch obvious mistakes and get feedback on structure, but I heavily dislike AI-generated content that is meant to be read by humans. There is a clear split in content and services that will most likely be consumed by AI agents (in which case, by all means, use AI to optimize for AI) vs humans (in which case, drop the slop).

That said, I constantly find AI lets me focus on the bigger picture, learning about the domain problem at hand, and overall gives me more time to think about the problems I find fun as a developer, so excited to see what’s ahead. Of course, you may be working on very different problems or codebases, so ymmv. Reach out if you’d like to chat more about any of this.

Building Shuffled: Treating AI as a Team

Tue, 10 Feb 2026 00:00:00 +0000

Also published on Substack.

I wanted to run a small experiment: could I build and ship a daily word puzzle game in a few days, using AI as my entire team, to get a better sense of building an idea with today’s AI tools?

Here’s the result. Read along for how it went.

The idea

I’ve had the idea of a simple game for a while, inspired by other word and casual games: something you pick up once a day, solve in a few minutes, pick up a new word, and move on until the next day. Just a small, fun way to clear your mind. Shuffled is my take on it, where you unscramble letters in a grid to form words before running out of moves; everyone gets the same puzzles daily.

This was the perfect kind of project for an “AI-assisted sprint”:

Something I’d actually play myself (see above)
Small and shippable: a web app, no game engine, no heavy backend (yet), simple mechanics
A stack I already know, so I can focus on the “AI team” workflow instead of new tech
Something I could write about at the end (this post!)

The stack

Tech stack

Standard stack for a web app: Next.js, TypeScript, Tailwind, deployed on Railway with Cloudflare as DNS provider, PostHog for analytics.

Development stack

I had subscriptions to Claude Pro, ChatGPT Plus, and Gemini AI Plus. While I find Opus to be the most capable model for how I work, I do like the experience of using different models for different problems, depending on complexity. Also, I considered this setup as a hiring budget for a side project 🤓.

To control cost and match strengths, I gave each tool a role:

Claude Code, my pair programmer: used for hands-on keyboard work, planning complex work, and building features that required a tight feedback loop. I think of Claude Code as my most senior developer whom I want to work closely with to build my ideas
Codex, my task runner: used for delegating relatively low-complexity or well-defined work that I can confidently trust to be done with almost no back-and-forth. Think specific visual polish, documentation upkeep, straightforward bug fixes that I ran into on the go, etc
Gemini Code Assist, my code reviewer: since I predominantly use Claude and Codex for coding tasks, I set up Gemini as my sole code reviewer with out-of-the-box settings. I found Gemini was really good at flagging Critical and High issues in PRs (more on addressing PR comments later)
For everything else, eg: brainstorming, alternate perspectives, or rate-limit moments, I’d rotate between them (including the Codex and Gemini CLIs)

Beyond the models, here’s the rest of the development stack:

SonarQube to ensure good overall code quality before shipping any changes. This is a must for any new project past the prototype phase, especially with more AI-generated code
GitHub Actions to enforce good CI/CD hygiene, including SonarQube analyses
Playwright for end-to-end testing
Railway environments for:
- Production (obviously). What you see when you open Shuffled
- PR environments, for testing changes manually before shipping to production. Railway automatically spins up the environment and posts the URL in the PR. Extremely convenient in my workflow and dead simple to set up. 10/10 would recommend
VSCode as my IDE

Planning upfront: Early decisions matter

I spent a significant amount of time upfront crafting specs I was happy with. Previous experience with an AI-assisted project taught me that you need to be opinionated about boundaries: API contracts, the game flow, the rules. AI handles internal logic well enough, but core mechanics and requirements should be nailed down by a human (for now?) who understands the feel they’re going for.

I was also very intentional about the design. I even hand-sketched the layout:

Don’t hire me for art

This is something I’ll keep doing even for quick prototypes (well, maybe not the drawing). Skipping a good planning step would’ve cost me later and likely slow me down when I actually want to iterate fast.

Skills and subagents: “A-ha” moments

Through this project, I had a more relatable use for bringing skills and subagents into a project than I had tried in the past. I’m sure I’m only scratching the surface here, but I can definitely appreciate how much more productive they made me.

Skills

Once I got the first working prototype running, I started a more regular development workflow, which meant I began encountering recurring tasks I could turn into skills. The most time-saving skills I had for this project were:

Commit and open a PR: Commit pending changes, push to the current branch, and open a pull request on GitHub, with some guardrails in between in case there are git conflicts, wrong branch, etc
Review PR: For every review comment on the PR for the current branch, classify it as Address or Skip with a brief rationale, plan fixes, wait for my confirmation, and implement them. The core PR loop was essentially: Open PR → wait for Gemini’s review → run this skill

Other housekeeping skills that are less frequently used but still handy to have:

Refresh documentation and memory files. Tl;dr verify documented claims against the codebase and workflows, and update any stale information
Debug failing tests
Fix lint issues

One neat thing about skills is that they are shared among Claude, Codex and Gemini. Another thing: I found that having the models create and update the skills themselves was much more efficient than attempting to do it myself.

Subagents

I wanted the game to feel like it has an infinite number of puzzles. In order to do that, you need the math and constraints to support it (eg, 5x5 word square puzzles are hard to generate without repetition). I also wanted a scalable way to generate new puzzles that I could still control for the most part. This was a feature that needed to be well thought out; otherwise, I’d run into headaches down the road, including spending a lot of time on content moderation, which was not ideal. This is how I introduced my first subagent, given that they are well-suited to task-specific workflows.

I created (well, Claude did) an architecture-advisor agent. In a nutshell, I use it when I need guidance on architectural decisions, system design trade-offs, code organization strategies, or long-term maintainability planning. I won’t go into the details, but this significantly helped me get to a solution and a foundation for puzzle generation that I was satisfied with. More importantly, it made me realize: whoa, I can orchestrate a development team with different disciplines.

Since then, I added two agents I used heavily during this sprint:

game-design-advisor: used when I’m thinking of improving a game mechanic, expanding on game design, addressing user feedback about gameplay experience, or brainstorming a new game feature
test-strategist: this one I find extremely interesting and one I’ll keep testing (no pun intended), so sharing the current subagent description:

You are an elite software testing strategist with deep expertise in test architecture, coverage optimization, and quality engineering. You specialize in TypeScript/React applications and understand that the goal of testing is to maximize development velocity while preserving critical user experiences. You think in terms of risk-based testing: protecting what matters most while avoiding test bloat that slows teams down.

Development workflow

By now, the flow looks somewhat like this:

Planning/specs/decisions with Claude (and subagents). I even created a roadmap file broken down into phases, calling out which subagent is needed on each phase
Delegate small tasks to Codex asynchronously. My rule of thumb is that if I don’t feel confident that the task can be easily solved in one shot, I’d rather wait until I’m available to pair program
Pair program with Claude Code for features, more complex work, ensure test coverage remains solid, and test locally. Then push PRs and test in a PR environment. Small commits to iterate fast and safely are still a golden practice.
Once PR is up, Gemini reviews PRs
If review risk is low + PR env looks good → merge
SonarQube flags, or if the PR comments are signaling moderate risk, get fed back into whichever agent is best suited to address in a pair programming session

What was my role in all of this?

This is something I wanted to figure out during this experiment. How is my role as a developer evolving given everything available today? By now, I have close to 20 years of experience building and maintaining software, as well as leading Engineering teams of 80 people. While I’m aware of highly autonomous AI workflows and I’m all in on AI, I’m also approaching this as closely as a realistic, team-based development workflow could look, based on my own development approach. Vibe coding is fun; accountability is better.

To answer the question, AI primarily handles execution, while I provide direction, taste, and risk control. While AI’s throughput is excellent, I had an opinionated vision of what I wanted done. I was the orchestrator of everything happening. I needed to be able to follow and understand the code well enough, manually intervene occasionally, and assess PR comments. I also need to understand and evaluate technology choices, etc. The Railway + Cloudflare deployment setup, while straightforward, still required me to serve as the orchestrator and architect (though I’m sure this could be streamlined).

More importantly, I am the one continuously testing the game’s feel and its direction. Is it snappy enough? Is it fun? Can I actually read the letters, even if based on good design patterns? Is it what I envisioned? If not, am I still happy with it? Then there are other aspects of building the game beyond coding: I shared the game with friends and family. I am still collecting feedback, triaging it, and deciding what matters. Focus and time are limited, so building with a pragmatic approach remains relevant and is where I find myself most involved.

I shipped a shareable version in 2 days, and it hit ~100 unique users within a week. Not bad!

What’s next

I was going to stop after the experiment sprint, but the positive feedback and engagement made me keep going and add a few more things to Shuffled. Next up: a Spanish version of the game (Update: it’s up!).

Ultimately, I ran this experiment to get a better feel of what to expect as I build moving forward. The future is exciting for all the ideas we’ll be able to bring to life. Other people working with similar workflows will find their own way to fully own a service through a team of AI agents. An evolution for development teams could be that a single product engineer owns a much larger scope through their AI team than before. While I’m not a fan of fragmented codebases, orchestrating well-scoped, smaller codebases might also be a safer approach to unlocking velocity through AI. I may explore some of these thoughts in future experiments.

If this resonates with something you’re building or thinking about, I’d love to hear about it. Got questions about anything here? Happy to chat about it!

And the shameless plug: play Shuffled and let me know what you think 🙂

Build a Bot That Tells Your Story

Wed, 07 Sep 2016 00:00:00 +0000

Originally published on Medium.

Meet WilBot, my personal bot. Robot image lovingly created by Robohash.org.

I’ve wanted to build a simple bot ever since Facebook announced the Messenger Platform earlier this year. There are so many new cool bots out there on Twitter, Facebook, Slack channels, Telegram, and others that I finally decided it was time to write my own.

I came across Olabot, a startup by Esther Crawford focused on making personal resume bots. This is a fascinating concept (can’t wait to see their final product), and it got me inspired to build a similar concept of my personal bot.

I developed WilBot as this learning exercise. It tells you stuff about me but I left the code flexible enough to support other actions in the future. Although very simple, it was fun and challenging to think about all the use cases you have to consider when building a messaging bot. Users can type anything at any time, so expect them to try to break your bot when designing its behavior. Go ahead, give it a try.

Btw, WilBot is open-source; you can find the code on GitHub. You can use it as a starting point for The Next Great Facebook Bot (kidding?). It’s flexible enough so it’s easy to add new functionalities and/or integrate it with other APIs.

There are excellent resources out there if you want to get started building your own bots. Botwiki.org is a good starting point with useful tutorials, tools and articles. Also, Botmakers.org is a very active Slack community for bot developers and enthusiasts. If you are building a Facebook bot, I suggest you use this cheatsheet from Chatbot Academy when starting your design. Most important of all, keep in mind it’s on us to create a healthy bot community.

It’s exciting to think about the messaging landscape and how we are evolving the way we communicate with our family, friends, community and businesses. This is the beginning of something great.

PS: If you want to give feedback on WilBot, talk about improving its user experience or discuss how to add other functionalities, send me a message!

If you enjoyed reading this article, please hit the ♥ button in the footer so that more people start building their own bots 🤖

Martian Run! Open-Source Game with LibGDX

Fri, 02 Jan 2015 00:00:00 +0000

A few months ago I wrote a tutorial for a 2D video game with libGDX, using box2d and scene2d. Many of the things I explained in the tutorial have changed a bit to improve performance and make the final game more of a complete product since one of my goals since day 1 of that project was to publish it in Google Play. So far I’ve received mostly positive feedback for the tutorial (thanks!). However, there were a few things I did not cover in the tutorial that I’m sure people would be interested in: I did not explain how to add the menu layer to the game nor how to integrate the game with Google Play Game Services or AdMob, both which were included in the final version.

Although it may be trivial for many, I decided it was best to fully open source the game for everyone to see how the final version, the one published on Google Play, is implemented. This would include a few tweaks with the assets to improve performance, implementation of the game difficulty change, and overall management of achievements with Google Play Game Services for Android. This past week I worked hard to make this happen and the GitHub project has been updated. You can clone it, add a few string resources for the Android module and run the game just as it is published.

The documentation might be a bit incomplete, but the code shouldn’t be too hard to follow if you quickly go over the tutorial.

And in case you are interested, you can download Martian Run! here.

Hope the project helps you if you are looking to get started with libGDX and video game development in general.

Any feedback is welcome in the comments section. Happy coding!

SlidingTabs Android Library

Sat, 27 Dec 2014 00:00:00 +0000

This library project is on GitHub.

With the release of Android Studio 1.0, one of the things to notice is that there’s an option to import an Android code sample. All these samples are available on GitHub/googlesamples.

While having those projects available is good, I think it would be even better to make all these samples available as libraries for everyone to use and contribute in a single codebase. For example, if you look at the code of both the SlidingTabs sample projects, SlidingTabsBasic and SlidingTabsColor, you’ll notice that both of them have the same exact code under a com.example.android.common package.

I’m working on a basic open-source Imgur client for Android where I needed to include the Sliding Tabs from the samples, so I decided to make the job a little easier for everyone and publish the views from the common package as a library.

The library is called Sliding Tabs and it consists of the SlidingTabLayout and SlidingTabStrip classes, with minor modifications to work from minSDK 8. All contributions are welcome; open a PR or refer to the issues section.

You can see an example of this library in Imgurdroid. And although not using this library, the same code is used in Google I/O Android App and, of course, Android SlidingTabsBasic Sample and Android SlidingTabsColors Sample.

Here are a few screenshots of the library in action:

Snackbar Android Library

Wed, 20 Aug 2014 01:00:00 +0000

This library project is on GitHub along with an example app.

Google’s Material Design documentation introduces a new component used for quick feedback called Snackbars. The document describes them as follows:

Snackbars provide lightweight feedback about an operation in a small popup at the base of the screen on mobile and at the lower left on desktop. They are above all over elements on screen, including the floating action button.

They automatically disappear after a timeout or after user interaction elsewhere on the screen, whichever comes first. Snackbars can be swiped off screen. They do not block input on the screens they appear on and cannot receive input focus. Show only one snackbar on screen at a time.Here are a couple of screenshots of how they should look:

Since there’s no native widget for this (at least not yet), I created a small Android library to quickly include this component on top of any activity. It only supports phones; it would still pop up at the base of the screen on tablets/desktops.

Using the Snackbar class is easy, this is how you would display it on an Activity:

Snackbar.with(getApplicationContext()) // context
    .text("Single-line snackbar") // text to display
    .show(this); // activity where it is displayed

However, I recommend you use the SnackbarManager to handle the Snackbars queue:

// Dismisses the Snackbar being shown, if any, and displays the new one
SnackbarManager.show(
    Snackbar.with(myActivity)
    .text("Single-line snackbar"));

If you are using getApplicationContext() as the Context to create the Snackbar then you must specify the target Activity when calling the SnackbarManager:

// Dismisses the Snackbar being shown, if any, and displays the new one
SnackbarManager.show(
    Snackbar.with(getApplicationContext())
    .text("Single-line snackbar"), myActivity);

If you want an action button to be displayed, just assign a label and an ActionClickListener:

SnackbarManager.show(
    Snackbar.with(getApplicationContext()) // context
        .text("Item deleted") // text to display
        .actionLabel("Undo") // action button label
        .actionListener(new ActionClickListener() {
            @Override
            public void onActionClicked(Snackbar snackbar) {
                Log.d(TAG, "Undoing something");
            }
        }) // action button's ActionClickListener
     , this); // activity where it is displayed

If you need to know when the Snackbar is shown or dismissed, assign a EventListener to it. This is useful if you need to move other objects while the Snackbar is displayed. For instance, you can move a Floating Action Button up while the Snackbar is on screen:

SnackbarManager.show(
    Snackbar.with(getApplicationContext()) // context
        .text("This will do something when dismissed") // text to display
        .eventListener(new EventListener() {
            @Override
            public void onShow(Snackbar snackbar) {
                myFloatingActionButton.moveUp(snackbar.getHeight());
            }
            @Override
            public void onShown(Snackbar snackbar) {
                Log.i(TAG, String.format("Snackbar shown. Width: %d Height: %d Offset: %d",
                        snackbar.getWidth(), snackbar.getHeight(),
                        snackbar.getOffset()));
            }
            @Override
            public void onDismiss(Snackbar snackbar) {
                myFloatingActionButton.moveDown(snackbar.getHeight());
            }
            @Override
            public void onDismissed(Snackbar snackbar) {
                Log.i(TAG, String.format("Snackbar dismissed. Width: %d Height: %d Offset: %d",
                                    snackbar.getWidth(), snackbar.getHeight(),
                                    snackbar.getOffset()));
            }
        }) // Snackbar's EventListener
    , this); // activity where it is displayed

There are two Snackbar types: single-line (default) and multi-line (2 lines max). You can also set the duration of the Snackbar similar to a Toast.

The lengths of a Snackbar duration are:

LENGTH_SHORT: 2s
LENGTH_LONG: 3.5s
LENGTH_INDEFINTE: Indefinite; ideal for persistent errors

You could also set a custom duration.

Animation disabling is also possible.

SnackbarManager.show(
    Snackbar.with(getApplicationContext()) // context
        .type(Snackbar.SnackbarType.MULTI_LINE) // Set is as a multi-line snackbar
        .text("This is a multi-line snackbar. Keep in mind that snackbars are " +
            "meant for VERY short messages") // text to be displayed
        .duration(Snackbar.SnackbarDuration.LENGTH_SHORT) // make it shorter
        .animation(false) // don't animate it
    , this); // where it is displayed

You can also change the Snackbar’s colors.

SnackbarManager.show(
    Snackbar.with(getApplicationContext()) // context
        .text("Different colors this time") // text to be displayed
        .textColor(Color.GREEN) // change the text color
        .color(Color.BLUE) // change the background color
        .actionLabel("Action") // action button label
        .actionColor(Color.RED) // action button label color
        .actionListener(new ActionClickListener() {
            @Override
            public void onActionClicked(Snackbar snackbar) {
                Log.d(TAG, "Doing something");
            }
         }) // action button's ActionClickListener
    , this); // activity where it is displayed

Finally, you can attach the Snackbar to a AbsListView (ListView, GridView) or a RecyclerView.

SnackbarManager.show(
    Snackbar.with(getApplicationContext()) // context
        .type(Snackbar.SnackbarType.MULTI_LINE) // Set is as a multi-line snackbar
        .text(R.string.message) // text to be displayed
        .duration(Snackbar.SnackbarDuration.LENGTH_LONG)
        .animation(false) // don't animate it
        .attachToAbsListView(listView) // Attach to ListView - attachToRecyclerView() is for RecyclerViews
        , this); // where it is displayed

It uses Roman Nurik’s SwipeToDismiss sample code to implement the swipe-to-dismiss functionality. This is enabled by default. You can disable this if you don’t want this functionality:

NOTE: This has no effect on apps running on APIs < 11; swiping will always be disabled in those cases

SnackbarManager.show(
    Snackbar.with(SnackbarSampleActivity.this) // context
        .text("Can't swipe this") // text to be displayed
        .swipeToDismiss(false) // disable swipe-to-dismiss functionality
    , this); // activity where it is displayed

The library project is on GitHub along with an example app. If you would like to add features to it or report any bugs, refer to the issues section. Here are a few screenshots of the library in action:

OpenFeed - Android L Twitter Client with RecyclerView and CardView Widgets

Tue, 15 Jul 2014 02:09:00 +0000

With Google’s announcement of the new version of Android (codename L) last month. I installed the preview SDK on my Nexus 5 and all of my apps worked pretty good except for Twitter which would not even open.

I decided to create an app to make use of the new RecyclerView and CardView widgets along with the new Material theme. Since Twitter didn’t work on my phone, I started my own client: OpenFeed. It’s a work in progress and its functionality will be limited since Twitter’s API does not provide everything I need (i.e. I can’t load a conversation thread).

Feel free to browse through the code, download the project and run it on your emulator or device. Let me know what you think in the comments section.

Up in the Air

Mon, 16 Jun 2014 03:35:00 +0000

Since I decided to join one game a month, I need to come up with new ideas. Having the world cup this time around, I put myself in “hackathon mode” and developed Up in the Air over a weekend. It’s very simple (yes, even more simple than Martian Run!) but I really had a lot of fun playing around with the physics involved.

In case you are wondering, the game is done with libGDX.

Hope you like it!

I'm Joining One Game a Month!

Fri, 13 Jun 2014 04:07:00 +0000

After finishing my last game, Martian Run!, I am feeling inspired to keep working on small games. For that, I decided to join One Game a Month. I really hope to get some XP! :D

Here’s my profile. Martian Run! is already submitted.

LibGDX Tutorial - A Running Game with libGDX - Part 5

Sat, 07 Jun 2014 13:09:00 +0000

Check out part 1 for the project and world setup! Check out part 2 for implementing controls for our runner! We introduced our enemies on part 3. We rendered our background and ground on part 4.

Remember the code is on GitHub. Graphics were made by Kenney. Also, a final version based on this tutorial is on Google Play.

Where Are My Characters?

If are coming from the previous part, you probably know that we stopped showing our runner and the enemies but hey, at least the background and the ground are looking good! In this next part we are going to display our characters again.

Let’s start with the runner (I know he’s not the same as the one on the final version, sorry!). So, we have four states for our guy: he’s either running, jumping, dodging or too busy getting hit by the enemies. We are going to store all his textures, along with the enemies’, in a texture atlas. Here is the image (characters.png):

And the following is the texture file (characters.txt):

characters.png
format: RGBA8888
filter: Linear,Linear
repeat: none
alienGreen_run1
  rotate: false
  xy: 2, 97
  size: 68, 93
  orig: 68, 93
  offset: 0, 0
  index: -1
fly_fly2
  rotate: false
  xy: 182, 195
  size: 65, 39
  orig: 65, 39
  offset: 0, 0
  index: -1
bee_fly2
  rotate: false
  xy: 60, 195
  size: 61, 42
  orig: 61, 42
  offset: 0, 0
  index: -1
alienGreen_jump
  rotate: false
  xy: 144, 2
  size: 67, 93
  orig: 67, 93
  offset: 0, 0
  index: -1
barnacle_bite1
  rotate: false
  xy: 144, 97
  size: 51, 57
  orig: 51, 57
  offset: 0, 0
  index: -1
alienGreen_dodge
  rotate: false
  xy: 2, 2
  size: 69, 71
  orig: 69, 71
  offset: 0, 0
  index: -1
alienGreen_hit
  rotate: false
  xy: 73, 2
  size: 69, 92
  orig: 69, 92
  offset: 0, 0
  index: -1
ladyBug_walk1
  rotate: false
  xy: 2, 245
  size: 61, 34
  orig: 61, 34
  offset: 0, 0
  index: -1
fly_fly1
  rotate: false
  xy: 123, 195
  size: 57, 45
  orig: 57, 45
  offset: 0, 0
  index: -1
bee_fly1
  rotate: false
  xy: 2, 195
  size: 56, 48
  orig: 56, 48
  offset: 0, 0
  index: -1
ladyBug_walk2
  rotate: false
  xy: 65, 245
  size: 59, 42
  orig: 59, 42
  offset: 0, 0
  index: -1
worm_walk2
  rotate: false
  xy: 146, 298
  size: 63, 23
  orig: 63, 23
  offset: 0, 0
  index: -1
spider_walk2
  rotate: false
  xy: 2, 298
  size: 77, 53
  orig: 77, 53
  offset: 0, 0
  index: -1
worm_walk1
  rotate: false
  xy: 81, 298
  size: 63, 23
  orig: 63, 23
  offset: 0, 0
  index: -1
alienGreen_run2
  rotate: false
  xy: 72, 97
  size: 70, 96
  orig: 70, 96
  offset: 0, 0
  index: -1
barnacle_bite2
  rotate: false
  xy: 197, 97
  size: 51, 58
  orig: 51, 58
  offset: 0, 0
  index: -1
spider_walk1
  rotate: false
  xy: 126, 245
  size: 72, 51
  orig: 72, 51
  offset: 0, 0
  index: -1

So if you are new to this you are probably asking yourself “What kind of sorcery is this?”. Well, I used TexturePacker to put together my .png files (they have an option for libGDX textures) and the two files were automatically generated. LibGDX also has its own TexturePacker but I’ve never tried it. My guess is that it would work even better for this game. Both of these files are stored in the assets directory.

The texture regions when the runner is hit, dodging or jumping are easy to get since they consist of a static frame (alienGreen_hit, alienGreen_dodge, and alienGreen_jump), we set a separate TextureRegion for each state and apply it inside our draw function. For the running state, we have two frames (alienGreen_run1 and alienGreen_run2) which we’ll use to create an Animation.

First, let’s take note of all this in our Constants class:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final String CHARACTERS_ATLAS_PATH = "characters.txt";
    public static final String[] RUNNER_RUNNING_REGION_NAMES = new String[] {"alienGreen_run1", "alienGreen_run2"};
    public static final String RUNNER_DODGING_REGION_NAME = "alienGreen_dodge";
    public static final String RUNNER_HIT_REGION_NAME = "alienGreen_hit";
    public static final String RUNNER_JUMPING_REGION_NAME = "alienGreen_jump";

}

And in our Runner class, let’s assign these TextureRegion objects along with the running Animation.

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.g2d.Animation;
import com.badlogic.gdx.graphics.g2d.Batch;
import com.badlogic.gdx.graphics.g2d.TextureAtlas;
import com.badlogic.gdx.graphics.g2d.TextureRegion;
import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.RunnerUserData;
import com.gamestudio24.martianrun.utils.Constants;

public class Runner extends GameActor {

    private boolean dodging;
    private boolean jumping;
    private boolean hit;
    private Animation runningAnimation;
    private TextureRegion jumpingTexture;
    private TextureRegion dodgingTexture;
    private TextureRegion hitTexture;
    private float stateTime;

    public Runner(Body body) {
        super(body);
        TextureAtlas textureAtlas = new TextureAtlas(Constants.CHARACTERS_ATLAS_PATH);
        TextureRegion[] runningFrames = new TextureRegion[Constants.RUNNER_RUNNING_REGION_NAMES.length];
        for (int i = 0; i < Constants.RUNNER_RUNNING_REGION_NAMES.length; i++) {
            String path = Constants.RUNNER_RUNNING_REGION_NAMES[i];
            runningFrames[i] = textureAtlas.findRegion(path);
        }
        runningAnimation = new Animation(0.1f, runningFrames);
        stateTime = 0f;
        jumpingTexture = textureAtlas.findRegion(Constants.RUNNER_JUMPING_REGION_NAME);
        dodgingTexture = textureAtlas.findRegion(Constants.RUNNER_DODGING_REGION_NAME);
        hitTexture = textureAtlas.findRegion(Constants.RUNNER_HIT_REGION_NAME);
    }

    @Override
    public void draw(Batch batch, float parentAlpha) {
        super.draw(batch, parentAlpha);

        if (dodging) {
            batch.draw(dodgingTexture, screenRectangle.x, screenRectangle.y + screenRectangle.height / 4, screenRectangle.width,
                    screenRectangle.height * 3 / 4);
        } else if (hit) {
            // When he's hit we also want to apply rotation if the body has been rotated
            batch.draw(hitTexture, screenRectangle.x, screenRectangle.y, screenRectangle.width * 0.5f,
                    screenRectangle.height * 0.5f, screenRectangle.width, screenRectangle.height, 1f, 1f,
                    (float) Math.toDegrees(body.getAngle()));
        } else if (jumping) {
            batch.draw(jumpingTexture, screenRectangle.x, screenRectangle.y, screenRectangle.width,
                    screenRectangle.height);
        } else {
            // Running
            stateTime += Gdx.graphics.getDeltaTime();
            batch.draw(runningAnimation.getKeyFrame(stateTime, true), screenRectangle.x, screenRectangle.y,
                    screenRectangle.getWidth(), screenRectangle.getHeight());
        }
    }

    ...

}

That’s all there is for animating the Runner. Run the project and see the guy run and get hit by the enemies we still don’t see :D. The video below shows how the game looks so far:

Know Thy Enemy

I will take advantage of our EnemyType enum to store all the texture region names needed for each Enemy. They will be very easy to render now that we know how to render an Animation. Each enemy has its own sprites, I will set them as follows:

Running small - lady bug
Running wide - worm
Running long - barnacle
Running big - spider
Flying small - bee
Flying wide - fly

Let’s add these values in our Constants:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final String[] RUNNING_SMALL_ENEMY_REGION_NAMES = new String[] {"ladyBug_walk1", "ladyBug_walk2"};
    public static final String[] RUNNING_LONG_ENEMY_REGION_NAMES = new String[] {"barnacle_bite1", "barnacle_bite2"};
    public static final String[] RUNNING_BIG_ENEMY_REGION_NAMES = new String[] {"spider_walk1", "spider_walk2"};
    public static final String[] RUNNING_WIDE_ENEMY_REGION_NAMES = new String[] {"worm_walk1", "worm_walk2"};
    public static final String[] FLYING_SMALL_ENEMY_REGION_NAMES = new String[] {"bee_fly1", "bee_fly2"};
    public static final String[] FLYING_WIDE_ENEMY_REGION_NAMES = new String[] {"fly_fly1", "fly_fly2"};

}

And as I mentioned before, use EnemyType to store these values:

package com.gamestudio24.martianrun.enums;

import com.gamestudio24.martianrun.utils.Constants;

public enum EnemyType {

    RUNNING_SMALL(1f, 1f, Constants.ENEMY_X, Constants.RUNNING_SHORT_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.RUNNING_SMALL_ENEMY_REGION_NAMES),
    RUNNING_WIDE(2f, 1f, Constants.ENEMY_X, Constants.RUNNING_SHORT_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.RUNNING_WIDE_ENEMY_REGION_NAMES),
    RUNNING_LONG(1f, 2f, Constants.ENEMY_X, Constants.RUNNING_LONG_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.RUNNING_LONG_ENEMY_REGION_NAMES),
    RUNNING_BIG(2f, 2f, Constants.ENEMY_X, Constants.RUNNING_LONG_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.RUNNING_BIG_ENEMY_REGION_NAMES),
    FLYING_SMALL(1f, 1f, Constants.ENEMY_X, Constants.FLYING_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.FLYING_SMALL_ENEMY_REGION_NAMES),
    FLYING_WIDE(2f, 1f, Constants.ENEMY_X, Constants.FLYING_ENEMY_Y, Constants.ENEMY_DENSITY,
            Constants.FLYING_WIDE_ENEMY_REGION_NAMES);

    private ...
    private String[] regions;

    EnemyType(float width, float height, float x, float y, float density, String[] regions) {
        this.width = width;
        this.height = height;
        this.x = x;
        this.y = y;
        this.density = density;
        this.regions = regions;
    }

    ...

    public String[] getRegions() {
        return regions;
    }
}

Our EnemyUserData should now store the region names the Enemy should render. We’ll pass the texture regions set in the constructor:

package com.gamestudio24.martianrun.box2d;

import ...

public class EnemyUserData extends UserData {

    private Vector2 linearVelocity;
    private String[] textureRegions;

    public EnemyUserData(float width, float height, String[] textureRegions) {
        super(width, height);
        userDataType = UserDataType.ENEMY;
        linearVelocity = Constants.ENEMY_LINEAR_VELOCITY;
        this.textureRegions = textureRegions;
    }

    public void setLinearVelocity(Vector2 linearVelocity) {
        this.linearVelocity = linearVelocity;
    }

    public Vector2 getLinearVelocity() {
        return linearVelocity;
    }

    public String[] getTextureRegions() {
        return textureRegions;
    }
}

And modify our EnemyUserData instantiation inside WorldUtils:

package com.gamestudio24.martianrun.utils;

import ...

public class WorldUtils {

    ...

    public static Body createEnemy(World world) {
        ...
        EnemyUserData userData = new EnemyUserData(enemyType.getWidth(), enemyType.getHeight(), enemyType.getRegions());
        body.setUserData(userData);
        shape.dispose();
        return body;
    }

}

Now we have all the assets we need to render the enemies! The logic to render them will be fairly similar to the logic we used to render our Runner with one exception. I’m rendering a bigger rectangle than the actual physics body (20% wider, 10% higher). The purpose of this is to make a little bit of overlapping possible between the runner and enemies so the hits look more real. The changes are the following:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.g2d.Animation;
import com.badlogic.gdx.graphics.g2d.Batch;
import com.badlogic.gdx.graphics.g2d.TextureAtlas;
import com.badlogic.gdx.graphics.g2d.TextureRegion;
import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.EnemyUserData;
import com.gamestudio24.martianrun.utils.Constants;

public class Enemy extends GameActor {

    private Animation animation;
    private float stateTime;

    public Enemy(Body body) {
        super(body);
        TextureAtlas textureAtlas = new TextureAtlas(Constants.CHARACTERS_ATLAS_PATH);
        TextureRegion[] runningFrames = new TextureRegion[getUserData().getTextureRegions().length];
        for (int i = 0; i < getUserData().getTextureRegions().length; i++) {
            String path = getUserData().getTextureRegions()[i];
            runningFrames[i] = textureAtlas.findRegion(path);
        }
        animation = new Animation(0.1f, runningFrames);
        stateTime = 0f;
    }

    ...

    @Override
    public void draw(Batch batch, float parentAlpha) {
        super.draw(batch, parentAlpha);
        stateTime += Gdx.graphics.getDeltaTime();
        batch.draw(animation.getKeyFrame(stateTime, true), (screenRectangle.x - (screenRectangle.width * 0.1f)),
                screenRectangle.y, screenRectangle.width * 1.2f, screenRectangle.height * 1.1f);
    }
}

Run the game and now you will see your fierce enemies coming towards you! Jump and dodge to avoid getting hit by any of them! The game should be working like in the video below (ignore the title, the original game name was modified before the first release):

Finally, I’d like to go back to our Runner drawing and apply the same ratio we just applied to our enemies (only 20% wider, though) so the overlapping also applies nicely to our Runner:

package com.gamestudio24.martianrun.actors;

import ...

public class Runner extends GameActor {

    ...

    @Override
    public void draw(Batch batch, float parentAlpha) {
        super.draw(batch, parentAlpha);

        float x = screenRectangle.x - (screenRectangle.width * 0.1f);
        float y = screenRectangle.y;
        float width = screenRectangle.width * 1.2f;

        if (dodging) {
            batch.draw(dodgingTexture, x, y + screenRectangle.height / 4, width, screenRectangle.height * 3 / 4);
        } else if (hit) {
            // When he's hit we also want to apply rotation if the body has been rotated
            batch.draw(hitTexture, x, y, width * 0.5f, screenRectangle.height * 0.5f, width, screenRectangle.height, 1f,
                    1f, (float) Math.toDegrees(body.getAngle()));
        } else if (jumping) {
            batch.draw(jumpingTexture, x, y, width, screenRectangle.height);
        } else {
            // Running
            stateTime += Gdx.graphics.getDeltaTime();
            batch.draw(runningAnimation.getKeyFrame(stateTime, true), x, y, width, screenRectangle.height);
        }
    }

    ...

}

Run the game one last time to make sure everything is working as expected (ignore the title, the original game name was modified before the first release):

That’s a Wrap!

Congrats on making it this far! I hope that this guide helped you understand a little better the basics of libGDX, using box2d and scene2d, and adding textures to your game. There are probably many things I could’ve done better, but I’m satisfied with the final product for teaching purposes.

I added more stuff to the game such as UI controls for menus, playing music and sounds, integrated Google Play Game Services as well as tweaked it a little bit to gradually increase the speed of the game. That’s fairly easy to implement and I think you can do it following libGDX’s wiki and other tutorials. Look at the final code to see how I did it.

Thanks for reading. If you liked this tutorial, I would really appreciate it if you could help spread the word by sharing it.

Cheers!

LibGDX Tutorial - A Running Game with libGDX - Part 4

Sat, 07 Jun 2014 13:04:00 +0000

Check out part 1 for the project and world setup! Check out part 2 for implementing controls for our runner! We introduced our enemies on part 3.

This is part 4 of a tutorial on writing a 2d running game. Remember the code is on GitHub. Also, a final version based on this tutorial is on Google Play.

Graphics Would Be Nice!

This is the part where you should really make the game your own instead of using the resources from here; I am going to be adding textures to the game. We are going to do the following:

Add a moving background
Add texture to the ground

All graphics have been made by Kenney.

Add a moving background

We will be adding the following background to the game:

But it would be nice to make the background look as if it is moving instead of a static one. For that I will be using the following technique: I will show two copies of the image and keep two rectangles that will determine the current position where each image should be rendered. We will save the background image inside the $PROJECT_ROOT/android/assets/ path, and name it background.png. Let’s keep track of the image path in our Constants class:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final String BACKGROUND_IMAGE_PATH = "background.png";
}

Now let’s create our Background class. Like I said before, it will keep a reference to a TextureRegion objects with two Rectangle objects. It will update the bounds of each Rectangle in the -x direction at a constant speed and when one of the Rectangle bounds reaches the end of the screen, reset both boundaries. Note that this class extends Actor and not our GameActor. This is because we don’t really need any of the box2d elements since the background is not really a game character:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Batch;
import com.badlogic.gdx.graphics.g2d.TextureRegion;
import com.badlogic.gdx.math.Rectangle;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.gamestudio24.martianrun.utils.Constants;

public class Background extends Actor {

    private final TextureRegion textureRegion;
    private Rectangle textureRegionBounds1;
    private Rectangle textureRegionBounds2;
    private int speed = 100;

    public Background() {
        textureRegion = new TextureRegion(new Texture(Gdx.files.internal(Constants.BACKGROUND_IMAGE_PATH)));
        textureRegionBounds1 = new Rectangle(0 - Constants.APP_WIDTH / 2, 0, Constants.APP_WIDTH, Constants.APP_HEIGHT);
        textureRegionBounds2 = new Rectangle(Constants.APP_WIDTH / 2, 0, Constants.APP_WIDTH, Constants.APP_HEIGHT);
    }

    @Override
    public void act(float delta) {
        if (leftBoundsReached(delta)) {
            resetBounds();
        } else {
            updateXBounds(-delta);
        }
    }

    @Override
    public void draw(Batch batch, float parentAlpha) {
        super.draw(batch, parentAlpha);
        batch.draw(textureRegion, textureRegionBounds1.x, textureRegionBounds1.y, Constants.APP_WIDTH,
                Constants.APP_HEIGHT);
        batch.draw(textureRegion, textureRegionBounds2.x, textureRegionBounds2.y, Constants.APP_WIDTH,
                Constants.APP_HEIGHT);
    }

    private boolean leftBoundsReached(float delta) {
        return (textureRegionBounds2.x - (delta * speed)) <= 0;
    }

    private void updateXBounds(float delta) {
        textureRegionBounds1.x += delta * speed;
        textureRegionBounds2.x += delta * speed;
    }

    private void resetBounds() {
        textureRegionBounds1 = textureRegionBounds2;
        textureRegionBounds2 = new Rectangle(Constants.APP_WIDTH, 0, Constants.APP_WIDTH, Constants.APP_HEIGHT);
    }

}

Now on to the GameStage. We need to get rid of our Box2dDebugRenderer (the ugly boxes where just for debugging purposes). We will also update the camera viewport and begin translating our box2d coordinates to screen coordinates (in pixels).

For now, we will only render our newly created Background:

package com.gamestudio24.martianrun.stages;

import ...
import com.badlogic.gdx.utils.Scaling;
import com.badlogic.gdx.utils.viewport.ScalingViewport;
import com.gamestudio24.martianrun.actors.Background;
import com.gamestudio24.martianrun.actors.Enemy;
import com.gamestudio24.martianrun.actors.Ground;
import com.gamestudio24.martianrun.actors.Runner;
import com.gamestudio24.martianrun.utils.BodyUtils;
import com.gamestudio24.martianrun.utils.Constants;
import com.gamestudio24.martianrun.utils.WorldUtils;

public class GameStage extends Stage implements ContactListener {

    private static final int VIEWPORT_WIDTH = Constants.APP_WIDTH;
    private static final int VIEWPORT_HEIGHT = Constants.APP_HEIGHT;

    ...

    public GameStage() {
        super(new ScalingViewport(Scaling.stretch, VIEWPORT_WIDTH, VIEWPORT_HEIGHT,
                new OrthographicCamera(VIEWPORT_WIDTH, VIEWPORT_HEIGHT)));
        setUpWorld();
        setupCamera();
        setupTouchControlAreas();
    }

    private void setUpWorld() {
        world = WorldUtils.createWorld();
        world.setContactListener(this);
        setUpBackground();
        setUpGround();
        setUpRunner();
        createEnemy();
    }

    private void setUpBackground() {
        addActor(new Background());
    }

    /** Remove the draw method since we won't use the DebugRenderer anymore **/

}

Run the game and you will see a nice, smooth animation of a moving background just like the video below:

Whoa! So what happened to the game? The ground, runner and enemies are still there, we are just not rendering them anymore with the Box2dDebugRenderer. That means the game started, an enemy came towards the runner and probably hit him without us noticing :D.

Add Texture to the Ground

For the ground, I will pretty much follow the same logic we used for the background. This will be our image for the ground:

I know that I should have all my textures in an atlas but I am making an exception with the ground so I can have a good image quality since I will stretch the image a lot. Let’s keep track of the image name (ground.png inside the assets directory) in our Constants class along with the previous one:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final String BACKGROUND_IMAGE_PATH = "background.png";
    public static final String GROUND_IMAGE_PATH = "ground.png";   

}

Now, one thing to note is that when we rendered the Background we used rectangles the size of the screen to know where to render. That was fine since we got a nice image which has the same size as the screen measurements we are working with. We don’t really want to do that for the other GameActor objects since we will be working with smaller images. In order to know the current Rectangle that we are supposed to render in screen coordinates, I am going to add a screenRectangle to my GameActor and update it in its act() method. I’m also going to check if the GameActor’s Body was destroyed by the GameStage (this happens when an Enemy or the Runner go out of bounds:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.math.Rectangle;
import com.badlogic.gdx.physics.box2d.Body;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.gamestudio24.martianrun.box2d.UserData;
import com.gamestudio24.martianrun.utils.Constants;

public abstract class GameActor extends Actor {

    protected Body body;
    protected UserData userData;
    protected Rectangle screenRectangle;

    public GameActor() {

    }

    public GameActor(Body body) {
        this.body = body;
        this.userData = (UserData) body.getUserData();
        screenRectangle = new Rectangle();
    }

    @Override
    public void act(float delta) {
        super.act(delta);

        if (body.getUserData() != null) {
            updateRectangle();
        } else {
            // This means the world destroyed the body (enemy or runner went out of bounds)
            remove();
        }

    }

    public abstract UserData getUserData();

    private void updateRectangle() {
        screenRectangle.x = transformToScreen(body.getPosition().x - userData.getWidth() / 2);
        screenRectangle.y = transformToScreen(body.getPosition().y - userData.getHeight() / 2);
        screenRectangle.width = transformToScreen(userData.getWidth());
        screenRectangle.height = transformToScreen(userData.getHeight());
    }

    protected float transformToScreen(float n) {
        return Constants.WORLD_TO_SCREEN * n;
    }

}

I mentioned before that I am translating 1 meter as 32 pixels. You can translate the units using whatever ratio works for you. The value goes in the Constants:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    public static final int APP_WIDTH = 800;
    public static final int APP_HEIGHT = 480;
    public static final float WORLD_TO_SCREEN = 32;

    ...

Since we are going to be working with the body’s position, we should change the way we create our Ground in WorldUtils. Before doing so, we have to match the GroundUserData constructor with its parent’s to store the width and height:

package com.gamestudio24.martianrun.box2d;

import com.gamestudio24.martianrun.enums.UserDataType;

public class GroundUserData extends UserData {

    public GroundUserData(float width, float height) {
        super(width, height);
        userDataType = UserDataType.GROUND;
    }

}

Now we can make the change in WorldUtils:

package com.gamestudio24.martianrun.utils;

import ...

public class WorldUtils {

    ...

    public static Body createGround(World world) {
        ...
        body.setUserData(new GroundUserData(Constants.GROUND_WIDTH, Constants.GROUND_HEIGHT));
        shape.dispose();
        return body;
    }

    ...

}

And now we apply pretty much the same logic we applied to the background in order to render the Ground with the exception of the texture loading (Note that I’m being lazy and should reuse the same methods from the Background class instead of copying them):

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Batch;
import com.badlogic.gdx.graphics.g2d.TextureRegion;
import com.badlogic.gdx.math.Rectangle;
import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.GroundUserData;
import com.gamestudio24.martianrun.utils.Constants;

public class Ground extends GameActor {

    private final TextureRegion textureRegion;
    private Rectangle textureRegionBounds1;
    private Rectangle textureRegionBounds2;
    private int speed = 10;

    public Ground(Body body) {
        super(body);
        textureRegion = new TextureRegion(new Texture(Gdx.files.internal(Constants.GROUND_IMAGE_PATH)));
        textureRegionBounds1 = new Rectangle(0 - getUserData().getWidth() / 2, 0, getUserData().getWidth(),
                getUserData().getHeight());
        textureRegionBounds2 = new Rectangle(getUserData().getWidth() / 2, 0, getUserData().getWidth(),
                getUserData().getHeight());
    }

    @Override
    public GroundUserData getUserData() {
        return (GroundUserData) userData;
    }

    @Override
    public void act(float delta) {
        super.act(delta);
        if (leftBoundsReached(delta)) {
            resetBounds();
        } else {
            updateXBounds(-delta);
        }
    }

    @Override
    public void draw(Batch batch, float parentAlpha) {
        super.draw(batch, parentAlpha);
        batch.draw(textureRegion, textureRegionBounds1.x, screenRectangle.y, screenRectangle.getWidth(),
                screenRectangle.getHeight());
        batch.draw(textureRegion, textureRegionBounds2.x, screenRectangle.y, screenRectangle.getWidth(),
                screenRectangle.getHeight());
    }

    private boolean leftBoundsReached(float delta) {
        return (textureRegionBounds2.x - transformToScreen(delta * speed)) <= 0;
    }

    private void updateXBounds(float delta) {
        textureRegionBounds1.x += transformToScreen(delta * speed);
        textureRegionBounds2.x += transformToScreen(delta * speed);
    }

    private void resetBounds() {
        textureRegionBounds1 = textureRegionBounds2;
        textureRegionBounds2 = new Rectangle(textureRegionBounds1.x + screenRectangle.width, 0, screenRectangle.width,
                screenRectangle.height);
    }

}

Now run the game and you should see the Background getting rendered along with the Ground just like it’s shown on the video below:

The game looks really good so far, even though we lost our characters :D. Let’s work with that on the next part.

If you have any questions or comments please let me know in the comments section. Please keep in mind that this was my way of solving the box2d to scene2d graphics conversion and I know that there are probably better ways to implement these kind of animations.

Click here for part 5. Cheers!

LibGDX Tutorial - A Running Game with libGDX - Part 3

Sat, 07 Jun 2014 13:03:00 +0000

Check out part 1 for the project and world setup! Check out part 2 for implementing controls for our runner!

This is part 3 of a tutorial on writing a 2d running game. Remember the code is on GitHub. Also, a final version based on this tutorial is on Google Play.

Watch Out for the Enemies!

In this section we’ll introduce our enemies, a bunch of running/flying insects. They will all be coming towards our runner in an attempt to hit/stop him. We will have 6 types of enemies: 4 of them will be running so we’ll have to jump over them and the other 2 will be flying, so we’ll have to dodge them. This is the configuration (width x height in meters) I came up with for all enemies:

Running small - 1 x 1
Running wide - 2 x 1
Running long - 1 x 2
Running big - 2 x 2
Flying small - 1 x 1
Flying wide - 2 x 1

The logic for our enemies will be the following: we’ll place an enemy just outside of the right side of the screen and move him towards the left end of the screen. If the runner successfully avoids getting hit by the enemy, we’ll create a new one until one of them hits the runner. The type of enemy to create will be randomly determined.

Since we want to generate different types of enemies, we’ll store their configuration as an enum. In our enums package, create an enum called EnemyType with the following:

package com.gamestudio24.martianrun.enums;

import com.gamestudio24.martianrun.utils.Constants;

public enum EnemyType {

    RUNNING_SMALL(1f, 1f, Constants.ENEMY_X, Constants.RUNNING_SHORT_ENEMY_Y, Constants.ENEMY_DENSITY),
    RUNNING_WIDE(2f, 1f, Constants.ENEMY_X, Constants.RUNNING_SHORT_ENEMY_Y, Constants.ENEMY_DENSITY),
    RUNNING_LONG(1f, 2f, Constants.ENEMY_X, Constants.RUNNING_LONG_ENEMY_Y, Constants.ENEMY_DENSITY),
    RUNNING_BIG(2f, 2f, Constants.ENEMY_X, Constants.RUNNING_LONG_ENEMY_Y, Constants.ENEMY_DENSITY),
    FLYING_SMALL(1f, 1f, Constants.ENEMY_X, Constants.FLYING_ENEMY_Y, Constants.ENEMY_DENSITY),
    FLYING_WIDE(2f, 1f, Constants.ENEMY_X, Constants.FLYING_ENEMY_Y, Constants.ENEMY_DENSITY);

    private float width;
    private float height;
    private float x;
    private float y;
    private float density;

    EnemyType(float width, float height, float x, float y, float density) {
        this.width = width;
        this.height = height;
        this.x = x;
        this.y = y;
        this.density = density;
    }

    public float getWidth() {
        return width;
    }

    public float getHeight() {
        return height;
    }

    public float getX() {
        return x;
    }

    public float getY() {
        return y;
    }

    public float getDensity() {
        return density;
    }

}

The new Constants added:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final float ENEMY_X = 25f;
    public static final float ENEMY_DENSITY = RUNNER_DENSITY;
    public static final float RUNNING_SHORT_ENEMY_Y = 1.5f;
    public static final float RUNNING_LONG_ENEMY_Y = 2f;
    public static final float FLYING_ENEMY_Y = 3f;
    public static final Vector2 ENEMY_LINEAR_VELOCITY = new Vector2(-10f, 0);

}

To obtain a random value from an enum, I created a RandomUtils class inside our utils package that contains a private static RandomEnum class that returns a random value from a given enum (credits go to this SO question):

package com.gamestudio24.martianrun.utils;

import com.gamestudio24.martianrun.enums.EnemyType;

import java.util.Random;

public class RandomUtils {

    public static EnemyType getRandomEnemyType() {
        RandomEnum<EnemyType> randomEnum = new RandomEnum<EnemyType>(EnemyType.class);
        return randomEnum.random();
    }

    /**
     * @see [Stack Overflow](http://stackoverflow.com/a/1973018)
     * @param <E>
     */

    private static class RandomEnum<E extends Enum> {

        private static final Random RND = new Random();
        private final E[] values;

        public RandomEnum(Class<E> token) {
            values = token.getEnumConstants();
        }

        public E random() {
            return values[RND.nextInt(values.length)];
        }
    }

}

Since we want to be consistent with our project setup, we have to create an EnemyUserData which extends from our UserData as well as an Enemy which extends from our GameActor. Let’s add an ENEMY value to our UserDataType enum:

package com.gamestudio24.martianrun.enums;

public enum UserDataType {

    GROUND,
    RUNNER,
    ENEMY

}

Hey! What was that ENEMY_LINEAR_VELOCITY we added to our Constants? Well, remember we are using our custom UserData to store any info regarding our characters’ movement. Our enemies will always run with a constant linear velocity to the left (negative x-direction) and a EnemyUserData class in our box2d package will be the perfect place to store it.

Before creating or EnemyUserData class, I’d like to change something in our UserData class: when we check if a character is in bounds (we’ll add that in a little bit), I need the character’s width in order to calculate it. I want to store this info whenever we create a new UserData object:

package com.gamestudio24.martianrun.box2d;

import com.gamestudio24.martianrun.enums.UserDataType;

public abstract class UserData {

    protected UserDataType userDataType;
    protected float width;
    protected float height;

    public UserData() {

    }

    public UserData(float width, float height) {
        this.width = width;
        this.height = height;
    }

    ...

    public float getWidth() {
        return width;
    }

    public void setWidth(float width) {
        this.width = width;
    }

    public float getHeight() {
        return height;
    }

    public void setHeight(float height) {
        this.height = height;
    }

}

Let’s match this new constructor in our RunnerUserData:

package com.gamestudio24.martianrun.box2d;

import ...

public class RunnerUserData extends UserData {

    ...

    public RunnerUserData(float width, float height) {
        super(width, height);
        jumpingLinearImpulse = Constants.RUNNER_JUMPING_LINEAR_IMPULSE;
        userDataType = UserDataType.RUNNER;
    }

    ...

}

And now we can create our EnemyUserData:

package com.gamestudio24.martianrun.box2d;

import com.badlogic.gdx.math.Vector2;
import com.gamestudio24.martianrun.enums.UserDataType;
import com.gamestudio24.martianrun.utils.Constants;

public class EnemyUserData extends UserData {

    private Vector2 linearVelocity;

    public EnemyUserData(float width, float height) {
        super(width, height);
        userDataType = UserDataType.ENEMY;
        linearVelocity = Constants.ENEMY_LINEAR_VELOCITY;
    }

    public void setLinearVelocity(Vector2 linearVelocity) {
        this.linearVelocity = linearVelocity;
    }

    public Vector2 getLinearVelocity() {
        return linearVelocity;
    }

}

Let’s now add our Enemy class that extends from our GameActor. Like it’s mentioned before, the logic for an enemy is to constantly move in the -x direction:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.EnemyUserData;

public class Enemy extends GameActor {

    public Enemy(Body body) {
        super(body);
    }

    @Override
    public EnemyUserData getUserData() {
        return (EnemyUserData) userData;
    }

    @Override
    public void act(float delta) {
        super.act(delta);
        body.setLinearVelocity(getUserData().getLinearVelocity());
    }

}

We’ll add a createEnemy function using our WorldUtils to create an Enemy of a random EnemyType. Note that in our World, an enemy will be a KinematicBody, which means it will move but it won’t be affected if it’s hit by another object (the Runner). While we are at it, we also have to change a line in our createRunner function so we store the Runner width and height:

package com.gamestudio24.martianrun.utils;

import ...
import com.gamestudio24.martianrun.box2d.EnemyUserData;
import com.gamestudio24.martianrun.box2d.GroundUserData;
import com.gamestudio24.martianrun.box2d.RunnerUserData;
import com.gamestudio24.martianrun.enums.EnemyType;

public class WorldUtils {

    ...

    public static Body createRunner(World world) {
        ...
        body.setUserData(new RunnerUserData(Constants.RUNNER_WIDTH, Constants.RUNNER_HEIGHT));
        shape.dispose();
        return body;
    }

    public static Body createEnemy(World world) {
        EnemyType enemyType = RandomUtils.getRandomEnemyType();
        BodyDef bodyDef = new BodyDef();
        bodyDef.type = BodyDef.BodyType.KinematicBody;
        bodyDef.position.set(new Vector2(enemyType.getX(), enemyType.getY()));
        PolygonShape shape = new PolygonShape();
        shape.setAsBox(enemyType.getWidth() / 2, enemyType.getHeight() / 2);
        Body body = world.createBody(bodyDef);
        body.createFixture(shape, enemyType.getDensity());
        body.resetMassData();
        EnemyUserData userData = new EnemyUserData(enemyType.getWidth(), enemyType.getHeight());
        body.setUserData(userData);
        shape.dispose();
        return body;
    }

}

Now, we will add the following logic to our GameStage: when the game is running, check if there are any enemies on screen; if there aren’t any create a new one. Also, when we check if our enemies are out of bounds, we also want to check if our runner is out of bounds to destroy its Body. If an Enemy hits our Runner, we’ll apply an angular impulse to our Runner so the hit looks a bit cartoonish.

Let’s store the angular impulse we just mentioned in our Constants:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...
    public static final Vector2 RUNNER_JUMPING_LINEAR_IMPULSE = new Vector2(0, 13f);
    public static final float RUNNER_HIT_ANGULAR_IMPULSE = 10f;

    ...

}

And access it through our RunnerUserData object:

package com.gamestudio24.martianrun.box2d;

import ...

public class RunnerUserData extends UserData {

    ...

    public float getHitAngularImpulse() {
        return Constants.RUNNER_HIT_ANGULAR_IMPULSE;
    }

}

Our Runner now needs to apply this angular impulse whenever he’s hit():

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.RunnerUserData;

public class Runner extends GameActor {

    private boolean dodging;
    private boolean jumping;
    private boolean hit;

    ...

    public void jump() {

        if (!(jumping || dodging || hit)) {
            body.applyLinearImpulse(getUserData().getJumpingLinearImpulse(), body.getWorldCenter(), true);
            jumping = true;
        }

    }

    ...

    public void dodge() {
        if (!(jumping || hit)) {
            body.setTransform(getUserData().getDodgePosition(), getUserData().getDodgeAngle());
            dodging = true;
        }
    }

    public void stopDodge() {
        dodging = false;
        // If the runner is hit don't force him back to the running position
        if (!hit) {
            body.setTransform(getUserData().getRunningPosition(), 0f);    
        }
    }

    public boolean isDodging() {
        return dodging;
    }

    public void hit() {
        body.applyAngularImpulse(getUserData().getHitAngularImpulse(), true);
        hit = true;
    }

    public boolean isHit() {
        return hit;
    }

}

Now, add a couple of helper functions in our BodyUtils class: bodyIsEnemy checks whether the given Body belongs to an Enemy and bodyInBounds checks whether the Runner or an Enemy is in our screen boundaries:

package com.gamestudio24.martianrun.utils;

import ...

public class BodyUtils {

    public static boolean bodyInBounds(Body body) {
        UserData userData = (UserData) body.getUserData();

        switch (userData.getUserDataType()) {
            case RUNNER:
            case ENEMY:
                return body.getPosition().x + userData.getWidth() / 2 > 0;
        }

        return true;
    }

    public static boolean bodyIsEnemy(Body body) {
        UserData userData = (UserData) body.getUserData();

        return userData != null && userData.getUserDataType() == UserDataType.ENEMY;
    }

    ...

}

Hook it all up in the GameStage:

package com.gamestudio24.martianrun.stages;

import ...
import com.badlogic.gdx.utils.Array;
import com.gamestudio24.martianrun.actors.Enemy;
import com.gamestudio24.martianrun.actors.Ground;
import com.gamestudio24.martianrun.actors.Runner;
import com.gamestudio24.martianrun.utils.BodyUtils;
import com.gamestudio24.martianrun.utils.WorldUtils;

public class GameStage extends Stage implements ContactListener {

    ...

    private void setUpWorld() {
        world = WorldUtils.createWorld();
        world.setContactListener(this);
        setUpGround();
        setUpRunner();
        createEnemy();
    }

    ...

    @Override
    public void act(float delta) {
        super.act(delta);

        Array<Body> bodies = new Array<Body>(world.getBodyCount());
        world.getBodies(bodies);

        for (Body body : bodies) {
            update(body);
        }

        // Fixed timestep
        accumulator += delta;

        while (accumulator >= delta) {
            world.step(TIME_STEP, 6, 2);
            accumulator -= TIME_STEP;
        }

        //TODO: Implement interpolation

    }

    private void update(Body body) {
        if (!BodyUtils.bodyInBounds(body)) {
            if (BodyUtils.bodyIsEnemy(body) && !runner.isHit()) {
                createEnemy();
            }
            world.destroyBody(body);
        }
    }

    private void createEnemy() {
        Enemy enemy = new Enemy(WorldUtils.createEnemy(world));
        addActor(enemy);
    }

    ...

    @Override
    public void beginContact(Contact contact) {

        Body a = contact.getFixtureA().getBody();
        Body b = contact.getFixtureB().getBody();

        if ((BodyUtils.bodyIsRunner(a) && BodyUtils.bodyIsEnemy(b)) ||
                (BodyUtils.bodyIsEnemy(a) && BodyUtils.bodyIsRunner(b))) {
            runner.hit();
        } else if ((BodyUtils.bodyIsRunner(a) && BodyUtils.bodyIsGround(b)) ||
                (BodyUtils.bodyIsGround(a) && BodyUtils.bodyIsRunner(b))) {
            runner.landed();
        }

    }

    ...

}

And we’ve got ourselves a game! Run the game and you’ll get “enemies” of different types moving towards the runner. You have to jump or dodge to avoid getting hit by any of them. The following video shows the game at this point (ignore the title, the original game name was modified before the first release):

At this point, I think enough has been covered to understand the basics of implementing a running game. In the next parts of this guide I will add some more stuff to make the game a little more fun, but I recommend you take it from here and customize it as you wish. Click here for part 4. Feel free to drop any questions or comments in the comments section. Cheers!

LibGDX Tutorial - A Running Game with libGDX - Part 2

Sat, 07 Jun 2014 13:02:00 +0000

Check out part 1 for the project and world setup!

This is part 2 of a tutorial on writing a 2d running game. Remember the code is on GitHub. Also, a final version based on this tutorial is on Google Play.

Run, Jump and Dodge!

The next step is to create our main guy, the runner. He will be a dynamic body with a fixed position on the x-axis with the ability to jump when the right side of the screen is touched and will dodge for as long the left side of the screen is touched.

First, let’s build our function inside WorldUtils that creates the runner:

package com.gamestudio24.martianrun.utils;

import ...

public class WorldUtils {

    //Rest of the code
    ...

    public static Body createRunner(World world) {
        BodyDef bodyDef = new BodyDef();
        bodyDef.type = BodyDef.BodyType.DynamicBody;
        bodyDef.position.set(new Vector2(Constants.RUNNER_X, Constants.RUNNER_Y));
        PolygonShape shape = new PolygonShape();
        shape.setAsBox(Constants.RUNNER_WIDTH / 2, Constants.RUNNER_HEIGHT / 2);
        Body body = world.createBody(bodyDef);
        body.createFixture(shape, Constants.RUNNER_DENSITY);
        body.resetMassData();
        shape.dispose();
        return body;
    }

}

And add the following constants:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...

    public static final float RUNNER_X = 2;
    public static final float RUNNER_Y = GROUND_Y + GROUND_HEIGHT;
    public static final float RUNNER_WIDTH = 1f;
    public static final float RUNNER_HEIGHT = 2f;
    public static float RUNNER_DENSITY = 0.5f;

}

How is our runner set up? We created him as a box that is 1 meter wide and 2 meters long. His position will be fixed at 2 meters from the left side of the screen and on top of the ground (duh). Let’s make sure that our runner is set up fine by adding him to the GameStage:

package com.gamestudio24.martianrun.stages;

import ...

public class GameStage extends Stage {

    ...

    private World world;
    private Body ground;
    private Body runner;

    ...

    public GameStage() {
        world = WorldUtils.createWorld();
        ground = WorldUtils.createGround(world);
        runner = WorldUtils.createRunner(world);
        renderer = new Box2DDebugRenderer();
        setupCamera();
    }

    // The rest
    ...

}

Run the game again and you should now see the runner (a box) standing there doing nothing, like the image below:

Good! Now, before we add the controls to our game, we should make good use of our GameStage and use Actor classes for our world components (the ground and the runner). In a newly created actors package, let’s create a base class for our actors called GameActor. Let’s start with this:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.badlogic.gdx.scenes.scene2d.Actor;

public abstract class GameActor extends Actor {

    protected Body body;

    public GameActor(Body body) {
        this.body = body;
    }

}

With the base class done, I’ll add a Ground class for our ground:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.GroundUserData;

public class Ground extends GameActor {

    public Ground(Body body) {
        super(body);
    }

}

And a Runner class for our runner:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;

public class Runner extends GameActor {

    public Runner(Body body) {
        super(body);
    }

}

Notice how our constructor is expecting a Body. This will make sure each Actor is responsible for the physics Body it is supposed to render and update. Let’s change our GameStage so it uses our newly created classes.

package com.gamestudio24.martianrun.stages;

import ...

public class GameStage extends Stage {

    ...

    private World world;
    private Ground ground;
    private Runner runner;

    ...

    public GameStage() {
        setUpWorld();
        setupCamera();
        renderer = new Box2DDebugRenderer();
    }

    private void setUpWorld() {
        world = WorldUtils.createWorld();
        setUpGround();
        setUpRunner();
    }

    private void setUpGround() {
        ground = new Ground(WorldUtils.createGround(world));
        addActor(ground);
    }

    private void setUpRunner() {
        runner = new Runner(WorldUtils.createRunner(world));
        addActor(runner);
    }

    private void setupCamera() ...

    ...    

}

If you run the project at this point, you should still see the last posted image (the static runner on the ground).

The first control we’ll add to the runner is jumping. The logic is the following: when I touch the right side of the screen, the runner will jump vertically and won’t be able to jump again until he’s landed.

So, how do I make a body jump? We apply a linear impulse to the body in the y-direction and let box2d do its magic. We’ll make use of box2d’s UserData to store information needed by our Body objects in order to behave properly. We’ll also create an enum to store the different UserData types we have available; this will come in handy when detecting collisions later on.

In an enums package, create an enum called UserDataType:

package com.gamestudio24.martianrun.enums;

public enum UserDataType {

    GROUND,
    RUNNER

}

In a newly created box2d package, create an abstract UserData class which will be used by our characters:

package com.gamestudio24.martianrun.box2d;

import com.gamestudio24.martianrun.enums.UserDataType;

public abstract class UserData {

    protected UserDataType userDataType;

    public UserData() {

    }

    public UserDataType getUserDataType() {
        return userDataType;
    }

}

And extend it for our Ground and our Runner:

package com.gamestudio24.martianrun.box2d;

import com.gamestudio24.martianrun.enums.UserDataType;

public class GroundUserData extends UserData {

    public GroundUserData() {
        super();
        userDataType = UserDataType.GROUND;
    }

}

Our RunnerUserData will store the vector to apply to our body when jumping:

package com.gamestudio24.martianrun.box2d;

import com.badlogic.gdx.math.Vector2;
import com.gamestudio24.martianrun.enums.UserDataType;
import com.gamestudio24.martianrun.utils.Constants;

public class RunnerUserData extends UserData {

    private Vector2 jumpingLinearImpulse;

    public RunnerUserData() {
        super();
        jumpingLinearImpulse = Constants.RUNNER_JUMPING_LINEAR_IMPULSE;
        userDataType = UserDataType.RUNNER;
    }

    public Vector2 getJumpingLinearImpulse() {
        return jumpingLinearImpulse;
    }

    public void setJumpingLinearImpulse(Vector2 jumpingLinearImpulse) {
        this.jumpingLinearImpulse = jumpingLinearImpulse;
    }

}

Here’s the new constant I added. Even though it may look like a random value, I actually did a bit of trial and error until the controls felt right. I’m also adding a gravity scale which I’ll set in a bit because I want the runner to fall faster so the game has an arcade feel:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    ...
    public static final float RUNNER_GRAVITY_SCALE = 3f;
    public static float RUNNER_DENSITY = 0.5f;
    public static final Vector2 RUNNER_JUMPING_LINEAR_IMPULSE = new Vector2(0, 13f);

}

Even though I pointed out that GroundUserData is pointless, it is important to be consistent with the UserData your Body objects use to prevent unexpected behavior. We will store an instance of UserData in all our Actor objects so let’s prepare our GameActor class for it:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.gamestudio24.martianrun.box2d.UserData;

public abstract class GameActor extends Actor {

    protected Body body;
    protected UserData userData;

    public GameActor(Body body) {
        this.body = body;
        this.userData = (UserData) body.getUserData();
    }

    public abstract UserData getUserData();

}

I need to override the new getUserData() function in our Ground class:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;

public class Ground extends GameActor {

    public Ground(Body body) {
        super(body);
    }

    @Override
    public GroundUserData getUserData() {
        return (GroundUserData) userData;
    }

}

Now we have all we need to make our character jump. We’ll do it with a jump() function in our Runner class. We’ll also add a landed() function to notify the runner he can jump again:

package com.gamestudio24.martianrun.actors;

import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.RunnerUserData;

public class Runner extends GameActor {

    private boolean jumping;

    public Runner(Body body) {
        super(body);
    }

    @Override
    public RunnerUserData getUserData() {
        return (RunnerUserData) userData;
    }

    public void jump() {

        if (!jumping) {
            body.applyLinearImpulse(getUserData().getJumpingLinearImpulse(), body.getWorldCenter(), true);
            jumping = true;
        }

    }

    public void landed() {
        jumping = false;
    }

}

Pretty straightforward, but we need two more things: set the appropriate UserData when setting up our World and implementing the controls on the GameStage to actually make the character jump. Setting the UserData is easy, you just need to add a couple of lines in our WorldUtils class. I’m also going to add a gravity scale (already added in the Constants class) to the runner so he falls faster:

package com.gamestudio24.martianrun.utils;

import ...
import com.gamestudio24.martianrun.box2d.GroundUserData;
import com.gamestudio24.martianrun.box2d.RunnerUserData;

public class WorldUtils {

    public static World createWorld() {
        return new World(Constants.WORLD_GRAVITY, true);
    }

    public static Body createGround(World world) {
        ...
        body.setUserData(new GroundUserData());
        shape.dispose();
        return body;
    }

    public static Body createRunner(World world) {
        ...
        Body body = world.createBody(bodyDef);
        body.setGravityScale(Constants.RUNNER_GRAVITY_SCALE);
        body.createFixture(shape, Constants.RUNNER_DENSITY);
        body.resetMassData();
        body.setUserData(new RunnerUserData());
        shape.dispose();
        return body;
    }

}

To implement the controls in our GameStage, we must override the touchDown function, determine if the right side of the screen is touched and, if so, make the runner jump():

package com.gamestudio24.martianrun.stages;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.OrthographicCamera;
import com.badlogic.gdx.math.Rectangle;
import com.badlogic.gdx.math.Vector3;
import ...

public class GameStage extends Stage {

    ...

    private OrthographicCamera camera;
    private Box2DDebugRenderer renderer;

    private Rectangle screenRightSide;

    private Vector3 touchPoint;

    public GameStage() {
        setUpWorld();
        setupCamera();
        setupTouchControlAreas();
        renderer = new Box2DDebugRenderer();
    }

    ...

    private void setupCamera() {
        ...
    }

    private void setupTouchControlAreas() {
        touchPoint = new Vector3();
        screenRightSide = new Rectangle(getCamera().viewportWidth / 2, 0, getCamera().viewportWidth / 2,
                getCamera().viewportHeight);
        Gdx.input.setInputProcessor(this);
    }

    ...

    @Override
    public void draw() {
        ...
    }

    @Override
    public boolean touchDown(int x, int y, int pointer, int button) {

        // Need to get the actual coordinates
        translateScreenToWorldCoordinates(x, y);

        if (rightSideTouched(touchPoint.x, touchPoint.y)) {
            runner.jump();
        }

        return super.touchDown(x, y, pointer, button);
    }

    private boolean rightSideTouched(float x, float y) {
        return screenRightSide.contains(x, y);
    }

    /**
     * Helper function to get the actual coordinates in my world
     * @param x
     * @param y
     */
    private void translateScreenToWorldCoordinates(int x, int y) {
        getCamera().unproject(touchPoint.set(x, y, 0));
    }

}

The controls are almost done, we need one last thing. We want to know when the runner lands on the ground so we are able to jump again. The way we’ll do this is by detecting a collision between the Runner and the Ground and notifying the Runner that he’s landed(). There’s a box2d listener for detecting collision between two bodies called ContactListener which we’ll implement. First, I’ll create a BodyUtils class inside the utils package with a couple of helper functions:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.physics.box2d.Body;
import com.gamestudio24.martianrun.box2d.UserData;
import com.gamestudio24.martianrun.enums.UserDataType;

public class BodyUtils {

    public static boolean bodyIsRunner(Body body) {
        UserData userData = (UserData) body.getUserData();

        return userData != null && userData.getUserDataType() == UserDataType.RUNNER;
    }

    public static boolean bodyIsGround(Body body) {
        UserData userData = (UserData) body.getUserData();

        return userData != null && userData.getUserDataType() == UserDataType.GROUND;
    }

}

And now implement the ContactListener in the GameStage class:

package com.gamestudio24.martianrun.stages;

import ...
import com.badlogic.gdx.physics.box2d.*;
import com.badlogic.gdx.scenes.scene2d.Stage;
import com.gamestudio24.martianrun.actors.Ground;
import com.gamestudio24.martianrun.actors.Runner;
import com.gamestudio24.martianrun.utils.BodyUtils;
import com.gamestudio24.martianrun.utils.WorldUtils;

public class GameStage extends Stage implements ContactListener {

    ...

    private void setUpWorld() {
        world = WorldUtils.createWorld();
        // Let the world now you are handling contacts
        world.setContactListener(this);
        setUpGround();
        setUpRunner();
    }

    ...

    @Override
    public void beginContact(Contact contact) {

        Body a = contact.getFixtureA().getBody();
        Body b = contact.getFixtureB().getBody();

        if ((BodyUtils.bodyIsRunner(a) && BodyUtils.bodyIsGround(b)) ||
                (BodyUtils.bodyIsGround(a) && BodyUtils.bodyIsRunner(b))) {
            runner.landed();
        }

    }

    @Override
    public void endContact(Contact contact) {

    }

    @Override
    public void preSolve(Contact contact, Manifold oldManifold) {

    }

    @Override
    public void postSolve(Contact contact, ContactImpulse impulse) {

    }
}

We’ve added a lot of stuff and it’s finally ready to run! Run the game and you’ll see that when you click/touch the right side of the screen the runner will jump just like is shown in the following video:

Our next step is to make the runner dodge. Now that we’ve got our blueprint for implementing the runner’s moves it will be much easier to make him dodge. The logic is the following: if the runner is not jumping and we touch the left side of the screen, he will be sliding until we stop touching the left side of the screen. By sliding, we mean rotating our rectangle by -90 degrees and placing it just above the ground. We already know the position of the runner when running; it’s in our Constants class. Now we also need to make note of the position of the runner while sliding by also adding it in the Constants class:

public class Constants {

    ...

    public static float RUNNER_DENSITY = 0.5f;
    public static final float RUNNER_DODGE_X = 2f;
    public static final float RUNNER_DODGE_Y = 1.5f;
    public static final Vector2 RUNNER_JUMPING_LINEAR_IMPULSE = new Vector2(0, 13f);

}

And store this info in our RunnerUserData class:

package com.gamestudio24.martianrun.box2d;

import ...

public class RunnerUserData extends UserData {

    private final Vector2 runningPosition = new Vector2(Constants.RUNNER_X, Constants.RUNNER_Y);
    private final Vector2 dodgePosition = new Vector2(Constants.RUNNER_DODGE_X, Constants.RUNNER_DODGE_Y);
    private Vector2 jumpingLinearImpulse;

    public RunnerUserData() {
        super();
        jumpingLinearImpulse = Constants.RUNNER_JUMPING_LINEAR_IMPULSE;
        userDataType = UserDataType.RUNNER;
    }

    public Vector2 getJumpingLinearImpulse() {
        return jumpingLinearImpulse;
    }

    public void setJumpingLinearImpulse(Vector2 jumpingLinearImpulse) {
        this.jumpingLinearImpulse = jumpingLinearImpulse;
    }

    public float getDodgeAngle() {
        // In radians
        return (float) (-90f * (Math.PI / 180f));
    }

    public Vector2 getRunningPosition() {
        return runningPosition;
    }

    public Vector2 getDodgePosition() {
        return dodgePosition;
    }
}

In our Runner class, we’ll add the functions to dodge() and stopDodge(). We also have to modify our jump() function so it does not make the runner jump while dodging:

package com.gamestudio24.martianrun.actors;

import ...

public class Runner extends GameActor {

    private boolean dodging;
    private boolean jumping;

    ...

    public void jump() {

        if (!(jumping || dodging)) {
            body.applyLinearImpulse(getUserData().getJumpingLinearImpulse(), body.getWorldCenter(), true);
            jumping = true;
        }

    }

    public void landed() {
        jumping = false;
    }

    public void dodge() {
        if (!jumping) {
            body.setTransform(getUserData().getDodgePosition(), getUserData().getDodgeAngle());
            dodging = true;
        }
    }

    public void stopDodge() {
        dodging = false;
        body.setTransform(getUserData().getRunningPosition(), 0f);
    }

    public boolean isDodging() {
        return dodging;
    }

}

Great! Now we need to call these functions from our GameStage class. When the user touches the left side of the screen we’ll call dodge() and whenever we stop touching the screen we’ll call stopDodge() if the runner isDodging(). It’s easy to know when we stop touching the screen, we just need to override the touchUp() function:

package com.gamestudio24.martianrun.stages;

import ...

public class GameStage extends Stage implements ContactListener {

    ...
    private Rectangle screenLeftSide;
    private Rectangle screenRightSide;

    private void setupTouchControlAreas() {
        touchPoint = new Vector3();
        screenLeftSide = new Rectangle(0, 0, getCamera().viewportWidth / 2, getCamera().viewportHeight);
        screenRightSide = new Rectangle(getCamera().viewportWidth / 2, 0, getCamera().viewportWidth / 2,
                getCamera().viewportHeight);
        Gdx.input.setInputProcessor(this);
    }

    ...

    @Override
    public boolean touchDown(int x, int y, int pointer, int button) {

        // Need to get the actual coordinates
        translateScreenToWorldCoordinates(x, y);

        if (rightSideTouched(touchPoint.x, touchPoint.y)) {
            runner.jump();
        } else if (leftSideTouched(touchPoint.x, touchPoint.y)) {
            runner.dodge();
        }

        return super.touchDown(x, y, pointer, button);
    }

    @Override
    public boolean touchUp(int screenX, int screenY, int pointer, int button) {

        if (runner.isDodging()) {
            runner.stopDodge();
        }

        return super.touchUp(screenX, screenY, pointer, button);
    }

    private boolean rightSideTouched(float x, float y) {
        return screenRightSide.contains(x, y);
    }

    private boolean leftSideTouched(float x, float y) {
        return screenLeftSide.contains(x, y);
    }

    ...
}

Our dodging functionality is done! Run the game and go ahead and touch and hold the left side of the screen; you should now be able to dodge. The jump functionality stays the same.
The video shows how the game is working at this point:

Very nice, isn’t it? So, what about the running part? We will keep our runner fixed at this position and make the objects move towards him, the animations will give the illusion of the runner moving forward. This means we are done with our runner’s controls!

In the next part, we will be adding our enemies to the game.

If you have any questions or comments on what we have done so far, feel free to let me know in the comments section. Cheers!

LibGDX Tutorial - A Running Game with libGDX - Part 1

Sat, 07 Jun 2014 13:02:00 +0000

I’ve always liked 2d running games. When I first got an Android phone, I played iRunner for hours, and at the time I seriously wanted to develop a game like that. A lot of time has passed since but I finally had the time to put together a simple, running game using libGDX. A final version based on this tutorial is on Google Play.

LibGDX is one of the nicest projects I’ve followed over the past few years and when I began looking into different video game development frameworks, it was definitely the one that provided the most features and provided the best performance for my then crappy phone :). If you have time, I recommend reading its creator’s post on releasing version 1.0.

I developed this game as a learning exercise using libGDX’s scene2d and box2d libraries on my spare time. The code is by no means perfect, but I hope it helps you get on the right track if you are looking to develop The Next Awesome Game. Also, even though libGDX is a cross-platform framework, I only targeted Android as my final release platform and I targeted desktop for testing purposes.

NOTE: I won’t be explaining much related to libGDX or box2d as they already have excellent documentation. I’m only guiding you through my own implementation of a game using these tools. If you don’t understand why I’m using a particular class or what a physics body is I strongly suggest taking a look at libGDX’s wiki before moving forward.

This tutorial guides you through the basics of how I implemented the game. The code from these posts is on GitHub. You are free to use it as you wish.

Before we start writing any code, let’s take a look at the game concept.

Martian Run!

This is the silly story I came up with: You are an alien and giant insects are attacking your city! Your goal is to escape by running as much as you can while avoiding all insects.

Game Controls

There are only to ways of avoiding insects: jumping and dodging. The jump button will be the right side of the screen and the dodge button will be the left side of the screen.

With our awesome design done, let’s build the game!

Creating the Project

Let’s set up a new project using the gdx-setup tool they offer. We’ll be using box2d, so make sure to include the extension during the setup. Like I said before, I’m only targeting Android as my build platform and will use desktop for testing, so no iOS or HTML.

This is what my setup looks like:

Once you click on Generate the Gradle clean task will run and all libraries will be downloaded. You should see an output like the following:

Generating app in /Users/wilmor24/Downloads/martianrun
Executing '/Users/wilmor24/Downloads/martianrun/gradlew clean --no-daemon'
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2/userguide/gradle_daemon.html.
Parallel execution with configuration on demand is an incubating feature.
:android:clean
:desktop:clean
:core:clean UP-TO-DATE
:desktop:clean UP-TO-DATE
:android:clean UP-TO-DATE

BUILD SUCCESSFUL

Total time: 12.395 secs
Done!
To import in Eclipse: File -> Import -> Gradle -> Gradle Project
To import to Intellij IDEA: File -> Import -> build.gradle
To import to NetBeans: File -> Open Project...

I won’t go over importing the project into an IDE since it’s part of a libGDX project setup and it is up to you which IDE to use (in case you are wondering, I’m using IntelliJ IDEA 14 at the time of this writing).

After successfully running the game in both desktop and Android, I usually clean up the boilerplate code set up by libGDX. That means, deleting the image badlogic.jpg that is added to the assets folder and leaving my game class like the following:

package com.gamestudio24.martianrun;

import com.badlogic.gdx.ApplicationAdapter;

public class MartianRun extends ApplicationAdapter {

    @Override
    public void create() {

    }

    @Override
    public void render() {

    }
}

Getting Started

The first thing we’ll do is to make our game class extend Game so we can support multiple screens. We won’t be using multiple screens for this game but I suggest doing this part in case you want to add multiple screens in the future, e.g. for a splash screen, separate menu screen, leaderboards, etc.

My game class now looks like this:

package com.gamestudio24.martianrun;

import com.badlogic.gdx.Game;

public class MartianRun extends Game {

    @Override
    public void create() {

    }

    // Get rid of render function, let the parent class handle it

}

Now create a GameScreen class inside a newly created screens package:

NOTE: Assume all classes/packages are being added/modified inside our core module unless otherwise noted

package com.gamestudio24.martianrun.screens;

import com.badlogic.gdx.Screen;

public class GameScreen implements Screen {

    @Override
    public void render(float delta) {

    }

    @Override
    public void resize(int width, int height) {

    }

    @Override
    public void show() {

    }

    @Override
    public void hide() {

    }

    @Override
    public void pause() {

    }

    @Override
    public void resume() {

    }

    @Override
    public void dispose() {

    }

}

Once created, we need to make our game class set our GameScreen on startup.

package com.gamestudio24.martianrun;

import com.badlogic.gdx.Game;
import com.gamestudio24.martianrun.screens.GameScreen;

public class MartianRun extends Game {

    @Override
    public void create() {
        setScreen(new GameScreen());
    }

}

The last thing we need to do for our setup is to set the height and width of our game. We’ll make this game 480x800. Let’s store these values in a Constants class inside a utils package.

package com.gamestudio24.martianrun.utils;

public class Constants {

    public static final int APP_WIDTH = 800;
    public static final int APP_HEIGHT = 480;

}

Finally, configure our DesktopLauncher so it uses the correct measurements:

package com.gamestudio24.martianrun.desktop;

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
import com.gamestudio24.martianrun.MartianRun;
import com.gamestudio24.martianrun.utils.Constants;

public class DesktopLauncher {
    public static void main (String[] arg) {
        LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
        config.width = Constants.APP_WIDTH;
        config.height = Constants.APP_HEIGHT;
        new LwjglApplication(new MartianRun(), config);
 }
}

Go ahead and run the project. So far, we have set up a game with a screen running on a 480x800 window.

A Stage for a Physics World

Now we’ll start creating our physics world. It’ll consist of a ground, a runner, and enemies. Even though our runner will be the one running through the city, we won’t be actually moving our runner body along the x-axis but make the enemies move towards the runner to while giving the illusion he is moving forward with sprite animations.

Box2d makes it easy to control bodies and control their physics, such as jumping, colliding, moving, etc. If you don’t know box2d at all, I recommend taking a quick look at its documentation.

Our bodies will be created as follows:

Ground: Static body
Runner: Dynamic body
Enemies: Kinematic bodies

Let’s make a class that takes care of creating our bodies. Create a WorldUtils class inside our utils package and create a function to set up the ground.

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;
import com.badlogic.gdx.physics.box2d.Body;
import com.badlogic.gdx.physics.box2d.BodyDef;
import com.badlogic.gdx.physics.box2d.PolygonShape;
import com.badlogic.gdx.physics.box2d.World;

public class WorldUtils {

    public static World createWorld() {
        return new World(Constants.WORLD_GRAVITY, true);
    }

    public static Body createGround(World world) {
        BodyDef bodyDef = new BodyDef();
        bodyDef.position.set(new Vector2(Constants.GROUND_X, Constants.GROUND_Y));
        Body body = world.createBody(bodyDef);
        PolygonShape shape = new PolygonShape();
        shape.setAsBox(Constants.GROUND_WIDTH / 2, Constants.GROUND_HEIGHT / 2);
        body.createFixture(shape, Constants.GROUND_DENSITY);
        shape.dispose();
        return body;
    }

}

The new constants added to our Constants class are the following:

package com.gamestudio24.martianrun.utils;

import com.badlogic.gdx.math.Vector2;

public class Constants {

    public static final int APP_WIDTH = 800;
    public static final int APP_HEIGHT = 480;

    public static final Vector2 WORLD_GRAVITY = new Vector2(0, -10);

    public static final float GROUND_X = 0;
    public static final float GROUND_Y = 0;
    public static final float GROUND_WIDTH = 25f;
    public static final float GROUND_HEIGHT = 2f;
    public static final float GROUND_DENSITY = 0f;

}

Let’s take a look at what we just did. We defined a utility class WorldUtils which will take care of creating our world components. For now we’ll only create the ground and the world itself. The ground is created as a static body with a width of 25 meters and a height of 2 meters and it is created as a box. In fact, all of our bodies will be boxes of different shapes.

The world is created with a gravity of -10 m/s^2. Box2d works best when using real physics values. In fact, the documentation warns the engine to be buggy if using exaggerated world values.

Ok, so we have these functions to create a world and the ground, but where do we use them? We could use them inside our GameScreen; instead, we will add them to a Stage which will be added to the GameScreen. A Stage is part of scene2d and is an input processor that can hold many Actor objects and handle their drawing and input events. We will add Actors later on but it is better to set up the Stage now so we don’t have to move the code from the GameScreen later on.

Create a GameStage inside a stages package. This class will extend libGDX’s Stage class. In the constructor, we’ll use our WorldUtils class to create the world and the ground. At this point, we will be using the Box2DDebugRenderer to display what we have created so far. We’ll use sprites later on once we are comfortable with the physics. The code is the following:

package com.gamestudio24.martianrun.stages;

import com.badlogic.gdx.graphics.OrthographicCamera;
import com.badlogic.gdx.physics.box2d.Body;
import com.badlogic.gdx.physics.box2d.Box2DDebugRenderer;
import com.badlogic.gdx.physics.box2d.World;
import com.badlogic.gdx.scenes.scene2d.Stage;
import com.gamestudio24.martianrun.utils.WorldUtils;

public class GameStage extends Stage {

    // This will be our viewport measurements while working with the debug renderer
    private static final int VIEWPORT_WIDTH = 20;
    private static final int VIEWPORT_HEIGHT = 13;

    private World world;
    private Body ground;

    private final float TIME_STEP = 1 / 300f;
    private float accumulator = 0f;

    private OrthographicCamera camera;
    private Box2DDebugRenderer renderer;

    public GameStage() {
        world = WorldUtils.createWorld();
        ground = WorldUtils.createGround(world);
        renderer = new Box2DDebugRenderer();
        setupCamera();
    }

    private void setupCamera() {
        camera = new OrthographicCamera(VIEWPORT_WIDTH, VIEWPORT_HEIGHT);
        camera.position.set(camera.viewportWidth / 2, camera.viewportHeight / 2, 0f);
        camera.update();
    }

    @Override
    public void act(float delta) {
        super.act(delta);

        // Fixed timestep
        accumulator += delta;

        while (accumulator >= delta) {
            world.step(TIME_STEP, 6, 2);
            accumulator -= TIME_STEP;
        }

        //TODO: Implement interpolation

    }

    @Override
    public void draw() {
        super.draw();
        renderer.render(world, camera.combined);
    }

}

You probably noticed the Fixed timestep comment inside the render function. Like the libGDX box2d documentation says, stepping the simulation is a topic itself. I followed this article to implement my version of fixed timestep. We probably need to implement interpolation as well, but I’ll leave it as a TODO for now.

Finally, let’s launch our GameStage inside our GameScreen. We’ll be calling act and draw inside the render function:

package com.gamestudio24.martianrun.screens;

import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.Screen;
import com.badlogic.gdx.graphics.GL20;
import com.gamestudio24.martianrun.stages.GameStage;

public class GameScreen implements Screen {

    private GameStage stage;

    public GameScreen() {
        stage = new GameStage();
    }

    @Override
    public void render(float delta) {
        //Clear the screen
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

        //Update the stage
        stage.draw();
        stage.act(delta);
    }

    //Rest of the code
    ...

}

Run the game and you’ll see a green line at the bottom which is the outline of the box we added to our world (the ground). Your game should look like the image below:

In the next part, we’ll add our runner with some basic controls.

If you have any questions or comments, feel free to let me know in the comments section.

Cheers!

Angular Espresso - AngularJS, CoffeeScript and Express

Tue, 02 Apr 2013 01:29:00 +0000

UPDATE: This post is now outdated. Check out the project’s git page for the latest info on Angular Espresso.

AngularJS is a powerful framework maintained by Google. I started playing around with it a few weeks ago and I think it is great for developing web apps. If you are a used to using jQuery for DOM manipulation and/or your views’ logic, you’ll have to change your approach and change the way you write dynamic views. Best of all, AngularJS is more than that: you could also have models, controllers, services and use partial views to develop a true, behavior-driven web app.

The AngularJS team has an angular-seed project that is very useful as a starting point for an AnglarJS app. There’s also an extension of that project that integrates Express with AngularJS.

Both of those projects are great. Based on them, I created a starting point for an AngularJS project, powered by Node.js and Express at the backend, all written in CoffeeScript. The result is Angular Espresso.

Besides rewriting some of the angular-seed project in CoffeeScript, I included a more complete template that hopefully serves as a starting point for some powerful web apps. Some of its key points are:

Socket.IO: Socket.IO is included as a service. As it is, it implements the “on” and “emit” functions.
Web Service: The “User” service is an example of how the project should be developed. Call a web service from your client app to your Express server and let the server handle all the logic, even if it’s just a proxy to an external service.
Partial Views and Jade: Use Jade as the template engine for your views and partial views. In your server, define the top-level views and let AngularJS handle the rest of the views with a $routeProvider config.

Once you download the project, you’ll need to install the dependencies with npm and build/run the project using its Cakefile. Take a look at the project’s documentation for more info. Long story short, the app folder contains all .coffee files. Each folder has a README file with a brief description. It compiles into a module called .espresso that it is run by the top-level app file. All client .js files are uglified using UglifyJS.

In the future I’d like to add some kind of Model support for the server (Mongoose, maybe?) as well as testing support (probably Mocha).

Node.js Tutorial - Building a Chatroom with Express.js + Socket.IO

Sun, 24 Mar 2013 00:16:00 +0000

In this tutorial we’ll see the basics of creating a Node.js project with two of its most popular modules: Express.js and Socket.IO. We’ll build a simple chatroom from scratch, like those from the early Internet days :P.

The final code is on GitHub, here’s the link.

Requirements

We are going to be building the project from scratch, so the only requirement is that you install, of course, node and npm (if not included with node). Also, I assume you know JavaScript. If you don’t, I totally recommend JavaScript’s track at Codecademy.

Creating a Project

Create the folder where we’ll have our project, we’ll be working from here from now on.

In Node, we don’t really create a project with a specific folder structure, but create an app file instead; that is, the file that will be executed as the node application. You may name the file as you want; in most of the projects I’ve seen it named either app.js or server.js. Since we’ll be building a web server, let’s go with server.js.

Let’s make sure our node installation works properly. Put the following in server.js:

console.log("Hello, world!");

Now, run your app. From a terminal window, execute:

$ node server.js

You should see the output:

Hello, world!

Ok, good to go! Now, create a file called package.json.This file serves the purpose of packaging your node project. Here you can specify the project name, author(s) info, dependency modules, node version, etc. There’s an excellent cheat sheet that you can use to package your own project.

For this project, the only info that you need in your package.json file is the following:

{
  "dependencies": {
    "express": "4.6.1",
    "jade": "1.4.2",
    "socket.io": "1.0.6",
    "underscore": "1.6.0",
    "body-parser": "1.4.3"
  }
}

You can put as much info as you like; the more info you put, the more info you are giving others about your app. The dependencies object is used by npm to download any necessary external modules for your app. Let’s go briefly through each one:

Express: a web framework for node. It is one of the most used modules in node.js; it takes care of a lot of boilerplate code to build a web app. If you are using views in your project, it expects you to use a template engine. By default, it expects Jade to be used.
Jade: a template engine for node. If you know HTML, you’ll love Jade. Briefly go through the docs and you’ll see what I mean.
Socket.IO: a module that makes real-time apps possible. We’ll go into more detail later in this tutorial.
Underscore: a utility module that has many common operations that you would normally use in other dynamic languages like Groovy or Ruby.
Body Parser**: **middleware parsing utility for node. We’ll use this to let the server parse JSON requestsNow that we’ve included our dependencies for the project, let’s tell npm to install the binaries:

$ npm install

Npm will automatically read the package.json file and download the dependencies noted in it. The output should be similar to the following:

> ws@0.4.31 install /node_modules/socket.io/node_modules/engine.io/node_modules/ws
> (node-gyp rebuild 2&gt; builderror.log) || (exit 0)

  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
  SOLINK_MODULE(target) Release/bufferutil.node
  SOLINK_MODULE(target) Release/bufferutil.node: Finished
  CXX(target) Release/obj.target/validation/src/validation.o
  SOLINK_MODULE(target) Release/validation.node
  SOLINK_MODULE(target) Release/validation.node: Finished

> ws@0.4.31 install /node_modules/socket.io/node_modules/socket.io-client/node_modules/engine.io-client/node_modules/ws
> (node-gyp rebuild 2&gt; builderror.log) || (exit 0)

  CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
  SOLINK_MODULE(target) Release/bufferutil.node
  SOLINK_MODULE(target) Release/bufferutil.node: Finished
  CXX(target) Release/obj.target/validation/src/validation.o
  SOLINK_MODULE(target) Release/validation.node
  SOLINK_MODULE(target) Release/validation.node: Finished
underscore@1.6.0 node_modules/underscore

body-parser@1.4.3 node_modules/body-parser
├── qs@0.6.6
├── media-typer@0.2.0
├── bytes@1.0.0
├── raw-body@1.2.2
├── depd@0.3.0
├── iconv-lite@0.4.3
└── type-is@1.3.1 (mime-types@1.0.0)

express@4.6.1 node_modules/express
├── utils-merge@1.0.0
├── merge-descriptors@0.0.2
├── parseurl@1.1.3
├── cookie@0.1.2
├── escape-html@1.0.1
├── finalhandler@0.0.3
├── cookie-signature@1.0.4
├── range-parser@1.0.0
├── fresh@0.2.2
├── vary@0.1.0
├── qs@0.6.6
├── media-typer@0.2.0
├── methods@1.1.0
├── serve-static@1.3.2
├── buffer-crc32@0.2.3
├── depd@0.3.0
├── path-to-regexp@0.1.3
├── accepts@1.0.7 (negotiator@0.4.7, mime-types@1.0.1)
├── type-is@1.3.2 (mime-types@1.0.1)
├── proxy-addr@1.0.1 (ipaddr.js@0.1.2)
├── debug@1.0.3 (ms@0.6.2)
└── send@0.6.0 (ms@0.6.2, mime@1.2.11, finished@1.2.2)

socket.io@1.0.6 node_modules/socket.io
├── debug@0.7.4
├── has-binary-data@0.1.1 (isarray@0.0.1)
├── socket.io-parser@2.2.0 (isarray@0.0.1, emitter@1.0.1, json3@3.2.6)
├── socket.io-adapter@0.2.0 (socket.io-parser@2.1.2)
├── engine.io@1.3.1 (base64id@0.1.0, debug@0.6.0, engine.io-parser@1.0.6, ws@0.4.31)
└── socket.io-client@1.0.6 (to-array@0.1.3, indexof@0.0.1, component-bind@1.0.0, object-component@0.0.3, component-emitter@1.1.2, parseuri@0.0.2, engine.io-client@1.3.1)

jade@1.4.2 node_modules/jade
├── commander@2.1.0
├── character-parser@1.2.0
├── mkdirp@0.5.0 (minimist@0.0.8)
├── transformers@2.1.0 (promise@2.0.0, css@1.0.8, uglify-js@2.2.5)
├── with@3.0.0 (uglify-js@2.4.15)
├── constantinople@2.0.1 (uglify-js@2.4.15)
└── monocle@1.1.51 (readdirp@0.2.5)

You should now have a folder named node_modules. The folder contains all the necessary files and binaries to run your project. This means that now this folder is truly the root folder of your project.

HTTP Server Setup

To set up the HTTP server using Express, we also need the http module included with node. You can go through the node documentation to see other modules included with it. Let’s change the contents of server.js as follows:

NOTE: I’ll comment where necessary; otherwise, it should be self-explanatory.

/*
  Module dependencies:

  - Express
  - Http (to run Express)
  - Body parser (to parse JSON requests)

  It is a common practice to name the variables after the module name.
  Ex: http is the "http" module, express is the "express" module, etc.
*/
var express = require("express")
  , app = express()
  , http = require("http").createServer(app)
  , bodyParser = require("body-parser");

/* Server config */

//Server's IP address
app.set("ipaddr", "127.0.0.1");

//Server's port number
app.set("port", 8080);

//Tells server to support JSON requests
app.use(bodyParser.json());

/* Server routing */

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {

  //Show a simple response message
  response.send("Server is up and running");

});

//Start the http server at port and IP defined before
http.listen(app.get("port"), app.get("ipaddr"), function() {
  console.log("Server up and running. Go to http://" + app.get("ipaddr") + ":" + app.get("port"));
});

Start the server:

$ node server.js

You should see the message:

Server up and running. Go to http://127.0.0.1:8080

If you go to that address in a browser, you should see a message as follows:

Awesome! We have an HTTP server up and running. Granted, it doesn’t do much but if you have worked with other web frameworks, you have to admit that it was very easy to set up an HTTP server. If you wanted to use an HTTPS server instead, instead of using the http module you would use the https module instead. Yup, is that easy.

Building a Jade View

This is a two-step process. First we have to tell our server that we are using Jade as our template engine. Then, we’ll create the view of our chatroom.

Add folders to our project where we’ll have all static content (css, client javascript), and one folder with our jade templates, or views. Add the following folder structure to the project:

public/
├── js/
└── css/

views/

Let the server know about this folder. Stop the server if you haven’t already done so and modify server.js:

NOTE: Changes in bold.

/*
  Module dependencies:

  - Express
  - Http (to run Express)
  - Body parser (to parse JSON requests)

  It is a common practice to name the variables after the module name.
  Ex: http is the "http" module, express is the "express" module, etc.
*/
var express = require("express")
  , app = express()
  , http = require("http").createServer(app)
  , bodyParser = require("body-parser");

/* Server config */

//Server's IP address
app.set("ipaddr", "127.0.0.1");

//Server's port number
app.set("port", 8080);
<b>
//Specify the views folder
app.set("views", __dirname + "/views");

//View engine is Jade
app.set("view engine", "jade");

//Specify where the static content is
app.use(express.static("public", __dirname + "/public"));
</b>
//Tells server to support JSON requests
app.use(bodyParser.json());

/* Server routing */

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {
<b>
  //Render the view called "index"
  response.render("index");
</b>
});

//Start the http server at port and IP defined before
http.listen(app.get("port"), app.get("ipaddr"), function() {
  console.log("Server up and running. Go to http://" + app.get("ipaddr") + ":" + app.get("port"));
});

Great! Now our server is ready to display views. The only thing missing is an actual view! Under the views folder, create a file named index.jade. This is the view we are telling the server to render when accessing http://localhost:8080. At this point you should probably take a quick look at the Jade documentation but if you don’t feel like it, don’t worry, I’ll create a simple document and the Jade syntax should be self-explanatory. The contents of index.jade should be the following:

doctype html
html
  head
    link(rel='stylesheet', href='http://fonts.googleapis.com/css?family=Open+Sans')
    link(rel='stylesheet', href='/css/style.css')    
    title Super Awesome Chatroom
  body
    h1 Super Awesome Chatroom
    div
      div.inlineBlock
        span Your name:
          input(type="text", value="Anonymous")#name
        br
        form#messageForm
          textarea(rows="4", cols="50", placeholder="Share something!", maxlength=200)#outgoingMessage
          input(type="button", value="Share", disabled=true)#send
      div.inlineBlock.topAligned
        b Participants
        br
        div#participants
    div#messages

I’d like to point out that Jade is awesome, I think the documents look way more elegant like this as opposed to simple HTML. Anyhow, we also need to create a stylesheet for the classes we assigned to some of the elements. It should be named style.css under the folder public/css/ with the following:

NOTE: If you decide to name the file other than style.css just make sure you also change it in index.jade.

body {
  padding: 3em;
  font-family: 'Open Sans', sans-serif;
  font-size: 1em;
}

textarea {
  resize: none;
}

.inlineBlock {
 display: inline-block;
}

.topAligned {
 vertical-align: top;
}

We have our view! Start (or restart) the server, open the browser and go to http://localhost:8080. You should now see an awesome chatroom that doesn’t do anything (yet!) like the one in the picture:

Web Services with Express

Express is great for creating RESTful web services. From the frameworks I’ve worked with, it has to be one of the easiest, if not the easiest, to build them with. If you take a look at server.js you’ll notice we have the following function to render our view:

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {

  //Render the view called "index"
  response.render("index");

});

We could easily change a function like the following:

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {

  //Return what's on your mind
  response.json(200, {message: "express is cool"});

});

And that would create a GET service at “http://localhost:8080/” that returns a JSON object. Awesome! Isn’t it? Let’s add a POST method to our server.js to send a chat message. We will also begin using Underscore:

NOTE: Changes in bold.

/*
  Module dependencies:

  - Express
  - Http (to run Express)
  - Body parser (to parse JSON requests)
  - Underscore (because it's cool)

  It is a common practice to name the variables after the module name.
  Ex: http is the "http" module, express is the "express" module, etc<b>
  The only exception is Underscore, where we use, conveniently, an underscore.</b>

*/
var express = require("express")
  , app = express()
  , http = require("http").createServer(app)
  , bodyParser = require("body-parser")
<b>  , _ = require("underscore");</b>

/* Server config */

//Server's IP address
app.set("ipaddr", "127.0.0.1");

//Server's port number
app.set("port", 8080);

//Specify the views folder
app.set("views", __dirname + "/views");

//View engine is Jade
app.set("view engine", "jade");

//Specify where the static content is
app.use(express.static("public", __dirname + "/public"));

//Tells server to support JSON requests
app.use(bodyParser.json());

/* Server routing */

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {

  //Render the view called "index"
  response.render("index");

});
<b>
//POST method to create a chat message
app.post("/message", function(request, response) {

  //The request body expects a param named "message"
  var message = request.body.message;

  //If the message is empty or wasn't sent it's a bad request
  if(_.isUndefined(message) || _.isEmpty(message.trim())) {
    return response.json(400, {error: "Message is invalid"});
  }

  //Looks good, let the client know
  response.json(200, {message: "Message received"});

});
</b>
//Start the http server at port and IP defined before
http.listen(app.get("port"), app.get("ipaddr"), function() {
  console.log("Server up and running. Go to http://" + app.get("ipaddr") + ":" + app.get("port"));
});

Let’s test our POST method, (re)start the server and call the method at http://localhost:8080/message. I’m using curl as my REST client, but you can choose whichever you want.

$ curl -X POST -H 'Content-Type:application/json' 'http://localhost:8080/message' -d '{"message":"Good news, everyone!"}'
{
  "message": "Message received"
}

Let’s test a bad request.

$ curl -X POST -H 'Content-Type:application/json' 'http://localhost:8080/message' -d '{"invalidParam":"Good news, everyone!"}'
{
  "error": "Message is invalid"
}
$ curl -X POST -H 'Content-Type:application/json' 'http://localhost:8080/message' -d '{"message":""}'
{
  "error": "Message is invalid"
}

This is as far as we’ll go with RESTful services in this tutorial, but feel free to browse through the Express documentation and build more methods or add options to our POST method.

Making real-time apps with Socket.IO

So far we have a web server that receives incoming messages that does nothing with them, and a view that can’t even send a message. I think that now it’s a good time to make this a real-time app. Let’s talk a little bit about Socket.IO first.

Socket.IO is a module that aims at making real-time apps possible. Long story short, it consists of a server that receives and emits events to all the clients, or just a set of clients, that connect to it. Here’s a list of browser and transport support for it. There are many websites that use Socket.IO, however, an excellent implementation of it is Trello. Fog Creek Software, its creator, have an excellent post on the website’s tech stack, including comments on their implementation of Socket.IO. It is definitely worth a read.

We are going to set up our socket server with our web server, but if you are considering building a huge website you should definitely implement your socket.IO server as a dedicated service instead of mixing it with your web server. Modify the header of server.js with the following:

NOTE: Changes in bold.

/*
  Module dependencies:

  - Express
  - Http (to run Express)
  - Body parser (to parse JSON requests)
  - Underscore (because it's cool)
<b>  - Socket.IO(Note: we need a web server to attach Socket.IO to)</b>

  It is a common practice to name the variables after the module name.
  Ex: http is the "http" module, express is the "express" module, etc.
  The only exception is Underscore, where we use, conveniently, an
  underscore. <b>Oh, and "socket.io" is simply called io. Seriously, the
  rest should be named after its module name.</b>

*/
var express = require("express")
  , app = express()
  , http = require("http").createServer(app)
  , bodyParser = require("body-parser")<b>
  , io = require("socket.io").listen(http)</b>
  , _ = require("underscore");

/* Server config */
...

Yup, we now have a socket.IO server up and running at the same location as our web server (http://localhost:8080). Let’s test it, shall we? For development purposes, socket.IO serves its client library at /socket.io/socket.io.js. Let’s also go ahead and create a JavaScript file that will be used in our client. Name it index.js (or whatever you like, just make sure it’s called the same in your index.jade file) and add it to our static location of JavaScript files, public/js/. Finally, we’ll use jQuery for our client code, so we’ll use it with a CDN (this example works with version 1.11). Modify the head tag of index.jade so it includes all JavaScript files, socket.io.js, jquery-1.11.0.min.js and index.js:

NOTE: Changes in bold.

doctype html
html
  head
    link(rel='stylesheet', href='http://fonts.googleapis.com/css?family=Open+Sans')
    link(rel='stylesheet', href='/css/style.css') <b>   
    script(src='//code.jquery.com/jquery-1.11.0.min.js')
    script(src='/socket.io/socket.io.js')
    script(src='/js/index.js')</b>
    title Super Awesome Chatroom
  body
    ...

Let’s put the following in index.js:

NOTE: I’ll comment where necessary; otherwise, it should be self-explanatory. Also, I’m not going to explain jQuery, you can go to Codecademy for that. They’ve got excellent tutorials.

function init() {

  var serverBaseUrl = document.domain;

  /*
   On client init, try to connect to the socket.IO server.
   Note we don't specify a port since we set up our server
   to run on port 8080
  */
  var socket = io.connect(serverBaseUrl);

  //We'll save our session ID in a variable for later
  var sessionId = '';

  /*
 When the client successfully connects to the server, an
 event "connect" is emitted. Let's get the session ID and
 log it.
  */
  socket.on('connect', function () {
    sessionId = socket.io.engine.id;
    console.log('Connected ' + sessionId);    
  });
}

$(document).on('ready', init);

Let’s test it! (Re)start the server, as soon as you start the server you should see an info message from the socket.IO server:

$ node server.js
Server up and running. Go to http://127.0.0.1:8080

Open the browser and go to http://localhost:8080. Take a look at the browser console and you should see the log along with a session ID as follows:

  Connected b0mT1Y370LFMU7rKXTsP

Woohoo! We now have a socket.IO server along out web server and successfully connected a client to it. We can now finish our chatroom!

A Chatroom

Let’s use what we just did to finish our chatroom. We are going to be working with the following events between our client and server:

When a new user connects to our server, he will emit an event called newUser and the server will emit an event called newConnection with a list of all participants to all connected clients
When a user changes his name, he will emit an event called nameChange and the server will emit an event called nameChanged to all participants with the id and new name of the user who emitted the original message
When a client disconnects from the server, an event called disconnect is automatically captured by the server. It will then emit an event to all participants with the id of the client that disconnected
When a client sends a message through our POST method, the server will emit an event called incomingMessage which will send the sender’s name and the message to all clients to show on their viewsLet’s add all this fancy stuff to our server. This is the final version of server.js:

NOTE: Changes in bold.

/*
  Module dependencies:

  - Express
  - Http (to run Express)
  - Body parser (to parse JSON requests)
  - Underscore (because it's cool)
  - Socket.IO

  It is a common practice to name the variables after the module name.
  Ex: http is the "http" module, express is the "express" module, etc.
  The only exception is Underscore, where we use, conveniently, an
  underscore. Oh, and "socket.io" is simply called io. Seriously, the
  rest should be named after its module name.

*/
var express = require("express")
  , app = express()
  , http = require("http").createServer(app)
  , bodyParser = require("body-parser")
  , io = require("socket.io").listen(http)
  , _ = require("underscore");
<b>
/*
  The list of participants in our chatroom.
  The format of each participant will be:
  {
    id: "sessionId",
    name: "participantName"
  }
*/
var participants = [];
</b>
/* Server config */

//Server's IP address
app.set("ipaddr", "127.0.0.1");

//Server's port number
app.set("port", 8080);

//Specify the views folder
app.set("views", __dirname + "/views");

//View engine is Jade
app.set("view engine", "jade");

//Specify where the static content is
app.use(express.static("public", __dirname + "/public"));

//Tells server to support JSON requests
app.use(bodyParser.json());

/* Server routing */

//Handle route "GET /", as in "http://localhost:8080/"
app.get("/", function(request, response) {

  //Render the view called "index"
  response.render("index");

});

//POST method to create a chat message
app.post("/message", function(request, response) {

  //The request body expects a param named "message"
  var message = request.body.message;

  //If the message is empty or wasn't sent it's a bad request
  if(_.isUndefined(message) || _.isEmpty(message.trim())) {
    return response.json(400, {error: "Message is invalid"});
  }
<b>
  //We also expect the sender's name with the message
  var name = request.body.name;

  //Let our chatroom know there was a new message
  io.sockets.emit("incomingMessage", {message: message, name: name});
</b>
  //Looks good, let the client know
  response.json(200, {message: "Message received"});

});
<b>
/* Socket.IO events */
io.on("connection", function(socket){

  /*
    When a new user connects to our server, we expect an event called "newUser"
    and then we'll emit an event called "newConnection" with a list of all
    participants to all connected clients
  */
  socket.on("newUser", function(data) {
    participants.push({id: data.id, name: data.name});
    io.sockets.emit("newConnection", {participants: participants});
  });

  /*
    When a user changes his name, we are expecting an event called "nameChange"
    and then we'll emit an event called "nameChanged" to all participants with
    the id and new name of the user who emitted the original message
  */
  socket.on("nameChange", function(data) {
    _.findWhere(participants, {id: socket.id}).name = data.name;
    io.sockets.emit("nameChanged", {id: data.id, name: data.name});
  });

  /*
    When a client disconnects from the server, the event "disconnect" is automatically
    captured by the server. It will then emit an event called "userDisconnected" to
    all participants with the id of the client that disconnected
  */
  socket.on("disconnect", function() {
    participants = _.without(participants,_.findWhere(participants, {id: socket.id}));
    io.sockets.emit("userDisconnected", {id: socket.id, sender:"system"});
  });

});
</b>
//Start the http server at port and IP defined before
http.listen(app.get("port"), app.get("ipaddr"), function() {
  console.log("Server up and running. Go to http://" + app.get("ipaddr") + ":" + app.get("port"));
});

I think the code and the comments are self-explanatory. If not, let me know in the comments section to update it accordingly.

Let’s finish this chatroom by extending the index.js file with the events we just defined.

NOTE: Changes in bold.

function init() {

  var serverBaseUrl = document.domain;

  /*
   On client init, try to connect to the socket.IO server.
   Note we don't specify a port since we set up our server
   to run on port 8080
  */
  var socket = io.connect(serverBaseUrl);

  //We'll save our session ID in a variable for later
  var sessionId = '';

  //Helper function to update the participants' list
  function updateParticipants(participants) {
   $('#participants').html('');
   for (var i = 0; i &lt; participants.length; i++) {
      $('#participants').append('&lt;span id="' + participants[i].id + '"&gt;' +
        participants[i].name + ' ' + (participants[i].id === sessionId ? '(You)' : '') + '&lt;br /&gt;&lt;/span&gt;');
    }
  }

  /*
 When the client successfully connects to the server, an
 event "connect" is emitted. Let's get the session ID and
 log it.<b> Also, let the socket.IO server there's a new user
 with a session ID and a name. We'll emit the "newUser" event
 for that.</b>
  */
  socket.on('connect', function () {
    sessionId = socket.io.engine.id;
    console.log('Connected ' + sessionId);<b>
    socket.emit('newUser', {id: sessionId, name: $('#name').val()});</b>
  });
<b>
  /*
 When the server emits the "newConnection" event, we'll reset
 the participants section and display the connected clients.
 Note we are assigning the sessionId as the span ID.
  */
  socket.on('newConnection', function (data) {    
    updateParticipants(data.participants);
  });

  /*
 When the server emits the "userDisconnected" event, we'll
 remove the span element from the participants element
  */
  socket.on('userDisconnected', function(data) {
    $('#' + data.id).remove();
  });

  /*
 When the server fires the "nameChanged" event, it means we
 must update the span with the given ID accordingly
  */
  socket.on('nameChanged', function (data) {
    $('#' + data.id).html(data.name + ' ' + (data.id === sessionId ? '(You)' : '') + '&lt;br /&gt;');
  });

  /*
 When receiving a new chat message with the "incomingMessage" event,
 we'll prepend it to the messages section
  */
  socket.on('incomingMessage', function (data) {
    var message = data.message;
    var name = data.name;
    $('#messages').prepend('&lt;b&gt;' + name + '&lt;/b&gt;&lt;br /&gt;' + message + '&lt;hr /&gt;');
  });

  /*
 Log an error if unable to connect to server
  */
  socket.on('error', function (reason) {
    console.log('Unable to connect to server', reason);
  });

  /*
 "sendMessage" will do a simple ajax POST call to our server with
 whatever message we have in our textarea
  */
  function sendMessage() {
    var outgoingMessage = $('#outgoingMessage').val();
    var name = $('#name').val();
    $.ajax({
      url:  '/message',
      type: 'POST',
      contentType: 'application/json',
      dataType: 'json',
      data: JSON.stringify({message: outgoingMessage, name: name})
    });
  }

  /*
 If user presses Enter key on textarea, call sendMessage if there
 is something to share
  */
  function outgoingMessageKeyDown(event) {
    if (event.which == 13) {
      event.preventDefault();
      if ($('#outgoingMessage').val().trim().length &lt;= 0) {
        return;
      }
      sendMessage();
      $('#outgoingMessage').val('');
    }
  }

  /*
 Helper function to disable/enable Send button
  */
  function outgoingMessageKeyUp() {
    var outgoingMessageValue = $('#outgoingMessage').val();
    $('#send').attr('disabled', (outgoingMessageValue.trim()).length &gt; 0 ? false : true);
  }

  /*
 When a user updates his/her name, let the server know by
 emitting the "nameChange" event
  */
  function nameFocusOut() {
    var name = $('#name').val();
    socket.emit('nameChange', {id: sessionId, name: name});
  }

  /* Elements setup */
  $('#outgoingMessage').on('keydown', outgoingMessageKeyDown);
  $('#outgoingMessage').on('keyup', outgoingMessageKeyUp);
  $('#name').on('focusout', nameFocusOut);
  $('#send').on('click', sendMessage);
</b>
}

$(document).on('ready', init);

Aaaaaand, that’s it! (Re)start the server and see our chatroom in action!

$ node server.js
Server up and running. Go to http://127.0.0.1:8080

Let’s open a browser to http://localhost:8080. You should see the following:

Now, open another tab or window at the same address:

You should see the list of participants on both sessions. Now change the name of one of the users:

All sessions should reflect the change:

Send a message from one of the sessions:

Check the other session to see the message that was sent:

Finally, send a message back to the other session:

Your super awesome chatroom is now complete! Note that this is a very basic implementation of different node modules, and also know that this chatroom is vulnerable to XSS and you should at the very least add an HTML sanitizer if you intend to use it for a real-world application.

What I would like now is for you to be creative and add events, styles, and cool functionalities to the chatroom. Share them all in the comments section or let everyone know what you thought of this tutorial!

Thanks for reading this far, I put a lot of effort into making this tutorial. If you liked it, I would really appreciate it if you could help spread the word by sharing this post.

Learning CoffeeScript

Tue, 19 Mar 2013 04:25:00 +0000

Since there’s so much fuzz about CoffeeScript these days, I thought it would be nice to cover the basics of the language and publish it on GitHub. You can take a look at it and share your thoughts in the comments section. The repo is a work in progress.

Repo: https://github.com/wmora/learning-coffeescript

See the README.md section for more details.

SpinnerSimpleDateModel

Fri, 14 Jan 2011 05:55:00 +0000

Here is the code for a JSpinnerModel that handles Date objects in simple format (e.g. ‘dd/MM/yyyy’). It extends a SpinnerDateModel so most of the code is based on that class. This class assumes that values are separated by a slash (/). The reason why I created this was based on a client’s requirement where I could only display the date in simple format and select the calendar using a JSpinner:

/**
 * A SpinnerSimpleDateModel for sequences of formatted Dates.
 * in simple format(e.g. "dd/MM/yyyy")
 *
 * @author William Mora
 * @version 1.0
 */
public class SpinnerSimpleDateModel extends SpinnerDateModel {

    private Comparable start, end;
    private Date value;
    private int calendarField;
    private SimpleDateFormat dateFormat;

    private boolean calendarFieldOK(int calendarField) {
        switch (calendarField) {
            case Calendar.DATE:
            case Calendar.YEAR:
            case Calendar.MONTH:
                return true;
            default:
                return false;
        }
    }

    /**
     * Creates an instance of SpinnerSimpleDateModel
     *
     * @param value         Initial date for the model
     * @param start         Minimum date for the model
     * @param end           Maximum date for the model
     * @param calendarField The interval desired for next and previous values.
     *                      The options are:
     *                      Calendar.DATE - Day of the month
     *                      Calendar.MONTH - Month
     *                      Calendar.YEAR - Year
     * @param dateFormat    A format specified by an instance of SimpleDateFormat
     */
    public SpinnerSimpleDateModel(Date value, Comparable start, Comparable end,
int calendarField, SimpleDateFormat dateFormat) {
        this.dateFormat = dateFormat;
        if (value == null) {
            throw new IllegalArgumentException("value is null");
        }
        if (!calendarFieldOK(calendarField)) {
            throw new IllegalArgumentException("invalid calendarField");
        }
        if ( !(((start == null) || (start.compareTo(value) <= 0)) &&
        ((end == null) || (end.compareTo(value) >= 0)))){
            throw new IllegalArgumentException("(start <= value <= end) is false");
        }
        this.value = value;
        this.start = start;
        this.end = end;
        this.calendarField = calendarField;
    }

    @Override
    public void setStart(Comparable start) {
        if ((start == null) ? (this.start != null) : !start.equals(this.start)) {
            this.start = start;
            fireStateChanged();
        }
    }

    @Override
    public void setEnd(Comparable end) {
        if ((end == null) ? (this.end != null) : !end.equals(this.end)) {
            this.end = end;
            fireStateChanged();
        }
    }

    @Override
    public void setCalendarField(int calendarField) {
        if (!calendarFieldOK(calendarField)) {
            throw new IllegalArgumentException("invalid calendarField");
        }
        if (calendarField != this.calendarField) {
            this.calendarField = calendarField;
            fireStateChanged();
        }
    }

    @Override
    public Comparable getEnd() {
        return end;
    }

    @Override
    public Object getNextValue() {
        Calendar cal = Calendar.getInstance();
        cal.setTime(value);
        cal.add(calendarField, 1);
        Date next = cal.getTime();
        return (end == null) || (end.compareTo(next) >= 0) ? next: null;
    }

    @Override
    public Object getPreviousValue() {
        Calendar cal = Calendar.getInstance();
        cal.setTime(value);
        cal.add(calendarField, -1);
        Date prev = cal.getTime();
        return ((start == null) || (start.compareTo((prev)) <= 0)) ? prev : null;
    }

    @Override
    public Object getValue() {
        return value;
    }

    @Override
    public void setValue(Object value) {
        if (value == null) {
            throw new NullPointerException("Date is null!");
        } else {
            if ((value instanceof String) && ((String) value).matches("[0-9]+[/][0-9]+[/][0-9]+")) {
                String date = ((String) value);
                int day = Integer.parseInt(date.substring(0, 2));
                int month = Integer.parseInt(date.substring(3, 5));
                int year = Integer.parseInt(date.substring(6));
                Calendar cal = Calendar.getInstance();
                //Month-1 because is zero-based
                cal.set(year, month - 1, day);
                this.value = cal.getTime();
            }
            if (value instanceof Date) {
                if (!dateFormat.format((Date) value).equals(dateFormat.format(this.value))) {
                    String temp = dateFormat.format((Date) value);
                    this.setValue(temp);
                    fireStateChanged();
                }
            }
        }

    }
}

Now the model can be used for any JSpinner. To create an instance for this class, the following will work: SpinnerSimpleDateModel spinnerModel = new SpinnerSimpleDateModel(new Date(), null, null, Calendar.DATE, new SimpleDateFormat("dd/MM/yyyy")); Then, set the editor of the JSpinner object to show the same format specified for the SpinnerSimpleDateModel object like the following:

JSpinner spinner1 = new javax.swing.JSpinner();
spinner1.setModel(spinnerModel);
spinner1.setEditor(new javax.swing.JSpinner.DateEditor(spinner1, "dd/MM/yyyy"));

Hope someone finds this useful. An advantage of using this technique is to manipulate date formats as you wish regardless of the locale.

SQL: Exists Condition

Wed, 19 May 2010 21:34:00 +0000

The SQL EXISTS condition is a boolean function that returns true if the condition is met. The syntax is pretty simple:

SELECT * FROM TABLE WHERE EXISTS(_subquery_);

Alternatively, you can use NOT EXISTS(_subquery_). An example of the function is the following:

SELECT utc.table_name    
 FROM user_tab_cols utc     
 WHERE utc.column_name='ACCOUNTID'
 AND NOT EXISTS(SELECT uc.table_name     
   FROM user_constraints uc     
   WHERE uc.table_name=utc.table_name     
   AND uc.r_constraint_name='SYS_C00229824')     
   ORDER BY utc.table_name;

The query looks for all the tables that contain the column ACCOUNTID and from those tables, only get the ones that don’t make reference to the constraint SYS_C00229824.

How to Modify Swap Size - Ubuntu 10.04

Fri, 14 May 2010 04:04:00 +0000

When installing Ubuntu, I was never asked about the desired size for my swap size. Oracle recommends to use at least 2GB of memory in order to create a database, let alone run it. With help from this excellent post from LinuxReaders, I expanded my swap size to 2GB (again, Oracle’s recommended size for 11g) by executing the following:

$ dd if=/dev/zero of=/tmp/swapfile bs=1MB count=2048
2048+0 records in
2048+0 records out
2048000000 bytes (2.0 GB) copied, 36.257 s, 56.5 MB/s
$ mkswap /tmp/swapfile
mkswap: /tmp/swapfile: warning: don't erase bootbits sectors
       on whole disk. Use -f to force.
Setting up swapspace version 1, size = 1999996 KiB
no label, UUID=aa8617a8-9500-498e-90da-f5164190ad00
$ sudo swapon /tmp/swapfile

Checked my swap memory with free -m:

            total       used       free     shared    buffers     cached
Mem:          3895       3841         53          0       1008       1799
-/+ buffers/cache:       1033       2861
Swap:         2208          0       2208

And made the swap size permanent by adding the following to /etc/fstab:

/tmp/swapfile          swap            swap    defaults        0 0

Cheers!

Change Screen Brightness From Terminal (Ubuntu 10.04)

Wed, 12 May 2010 15:30:00 +0000

If you want to change the screen brightness in Ubuntu (I can’t change it using the keyboard shortcuts or the Ubuntu Power Management menu), open a terminal and execute the following:

sudo setpci -s 00:02.0 F4.B=xx

Where xx is the desired brightness in hex ranging from 0 (brightest) to FF (no brightness at all). I usually change it to CA when working on battery.

Cheers!

What This is About

Sun, 09 May 2010 15:42:00 +0000

Hello!

Random tech tips, thoughts, etc.

You can follow me on Twitter @_williammora

Enjoy!