JustWeEngine: an Android 2D engine you drop in through Gradle or Maven

A 2D Android framework that ships as a library, not an app

JustWeEngine describes itself as an easy open source Android native game framework, and the project is written in Java. The distribution model is what shapes everything else about it. There is no application to install and no scene editor to learn. The engine is consumed the way any other Android library is consumed: you add it to a build file, and your code drives it.

That makes it a different shape of tool from the large engines that ship a visual editor. The value here is a small set of 2D game primitives that a developer can read through, plus a flow chart image in the documentation that shows how the engine's pieces fit together. The trade-off is that there is no asset pipeline, no scene serialization and no built in editor, so those parts stay in your hands. The repository also points at a plane game demo, extra modules in a separate JustWeTools repository, a web server demo for the networking parts, and two games built by other people, which is the closest thing to a usage guide the project has.

Two ways in: JitPack coordinates or a jar from the repository

The documentation gives you two integration routes and they serve different situations. The first is to import the engine's module as a library, or to import engine.jar from the jar directory in the repository. The second is to pull the published build from JitPack, the service that builds GitHub repositories into Maven style artifacts, which is why the project is tagged for jitpack in its topics.

The JitPack route is the one most people want because it survives a refactor of the repository layout and gives you a single coordinate with a version. The coordinates are the project owner and the repository name with the release tag as the version, so the group id is com.github.lfkdsk and the artifact is JustWeEngine.

    <dependency>
      <groupId>com.github.lfkdsk</groupId>
      <artifactId>JustWeEngine</artifactId>
      <version>v1.13</version>
  </dependency>

The jar route has no network dependency on a third party build service, which matters if your builds run in a restricted network, and it pins you to a specific commit of the engine rather than a tag.

The Gradle snippet still uses the old compile keyword

The Gradle path is the one most Android projects will take, and the snippet in the documentation is short. You add the JitPack repository to the repositories block of your root build file, pointing at https://jitpack.io, and then declare the dependency in your module.

      dependencies {
          compile 'com.github.lfkdsk:JustWeEngine:v1.13'
    }

Two things in those three lines deserve attention. The first is the compile keyword, which is the older Gradle configuration style; current Android projects normally use implementation or api, and a build file that still accepts compile is probably an old project or an old Gradle version. Changing the keyword to implementation is the obvious move if your build supports it, but it is a change to your build semantics rather than to the engine, and the difference between compile and implementation shows up in what the dependency exposes to the rest of the app.

The second is that the version is a release tag. JitPack builds on demand when a tag is requested, so the first resolution of a tag can take noticeably longer than a cached dependency from a standard repository.

A 2017 release tag with a 2026 push history

The version history is the part that needs a decision rather than a description. The listed releases are v1.11, v1.12 and v1.13, with v1.13 dated 2017-01-02 and described as a bug fix in path, v1.12 from 2016-12-01 fixing bugs and changing path names, and v1.11 from 2016-09-19 adding a quadtree to solve collision. The last push to the repository was on 2026-04-28.

So the tagged releases stopped more than nine years ago while commits continued afterwards. Nothing in the documentation explains that gap, and it is the first question a team should ask about, because the code you get from JitPack at v1.13 is not necessarily the code sitting on the master branch. If you are using the jar from the repository instead, you are taking master, which is the newer code with no tagged version to refer to.

Licensing is also slightly ambiguous in the metadata. The repository's licence field is not filled in, while the README carries a full Apache License 2.0 notice dated 2017. Apache 2.0 is permissive, but the missing file in the repository is worth raising with the author rather than assuming.

The surrounding ecosystem does more work than the engine

Much of what the project has to offer sits in neighbouring repositories. JustWeTools holds the extra modules. JustWe-WebServer is a demo for the network side. EngineDemo is the plane game, which is the most efficient way to understand the engine's API because it is the same version of the engine. Two outside projects show what other developers did with it: StudioVSEclipse, a studio built for the Eclipse IDE and contributed by ice1000, and Hungry Shark, a game contributed by hnshilei.

For learning, the project keeps its guidance in three languages: an English guide, a Chinese guide and a traditional Chinese guide, plus a wiki. The multiplication is unusual for a project this size and it suggests attention to the audience, but it also means the documentation is spread across several files, and the English guide is the one to read first if you are working in English.

The practical takeaway is that you should read the plane game demo before you write any code of your own. The engine is small enough that the demo is likely to teach you more than the framework overview does.

When a small engine is the right amount of engine

The honest question is when this beats a larger framework. A small Java 2D engine with a flow chart, a demo game and a couple of modules is a good fit for a small native Android game where you want control over the code and do not want a heavyweight editor and asset pipeline in the build. It is also a reasonable teaching reference, since the source fits in a repository you can read end to end.

It is the wrong tool when your project needs things the framework does not advertise: no editor, no asset pipeline, no scene format, and no sign of a plugin system in the documentation. The networking story is a demo, not a documented API surface, so a game with real multiplayer would have to build on the raw engine. And the release gap described earlier means you are depending on code whose maintenance path is not documented, which is a different kind of risk from a project with an active tag history.

The decision really comes down to how much of the engine you want to own. If you want a small set of 2D primitives and the rest of the work in your own layer, this fits. If you want a pipeline, take the pipeline.

Editorial conclusion

JustWeEngine is worth adopting for a small native Android 2D game if you are comfortable wiring an old dependency into your Gradle build and you want a working reference project to read. It is the wrong choice for a team that needs an engine with recent releases, current Android tooling support, or an active maintainer answering issues, because the last release tag is v1.13 from 2017 even though the last push was on 2026-04-28. Before you commit, check the compile configuration line in your own build file, since the documented snippet still uses the older compile keyword, and read the license section in the README because the repository's licence field is not filled in even though the README states Apache License 2.0.

Frequently asked questions

Official sources

1. Issues
2. lfkdsk/JustWeEngine on GitHub
3. README
4. Releases