Humanity’s Last Stand was a shared project from the ground up. I worked as a game designer and programmer alongside one teammate, building the game together and taking it to a public Android release. This article credits the project as a collaboration throughout.
The game puts an aircraft into combat above London. The surviving portfolio material gives us two useful views: a short gameplay recording and a public store listing. Here is what those materials show, what my role was, and where the available evidence ends.
A real capture from the released game.Play when you’re ready
[ PEOPLE / PRACTICE ]
A TWO-PERSON BUILDMICHAEL / MY CONTRIBUTION
Game design
and programming.
I worked across both disciplines as we shaped and built the game.
COLLABORATION / FROM THE GROUND UP
Built together
with one teammate.
A shared project from its foundations through its public release.
- 01 / FLIGHTRead the airspacePlane, city and touch controls share the screen.
- 02 / ENCOUNTERAim and engageCombat and its feedback stay visible in play.
- 03 / PROGRESSIONBuild the arsenalThe store listing describes missions and upgrades.
A small team, a complete game
This was a two-person collaboration. My work covered game design and programming; my teammate worked with me to build the game from its foundations. The exact task split and system-by-system ownership were not recorded in the portfolio, so I describe the shared result without assigning individual features that I cannot substantiate.
That distinction matters when a project is presented in a portfolio. “I made the game” can hide the work of a collaborator. The more accurate account is that we built the game together, and that I contributed across both its design and implementation.
Designing around a phone screen
The recording shows the plane, the city, targets, touch controls and gameplay feedback in one frame. That makes the central design constraint visible: the player has to read the scene and act through controls that occupy part of the same screen. This is a retrospective reading of the shipped capture, not a claim about a documented design brief or a measured usability study.
The public listing describes aerial combat, missions and upgrades. Together, the capture and listing suggest a player experience that moves from flight, into an encounter, and onward through progression. The diagram above summarizes that experience; it does not represent the game’s internal code architecture.
Working across design and programming gave me a view of both sides of that work. I can confidently state those roles and the fact that we built the project together. I do not have a preserved design log or a detailed contribution history that would support more specific claims about who implemented each feature.
From project to public release
The Google Play listing is public release evidence. It currently shows a 1K+ downloads badge. That is the store’s rounded threshold, not an exact install count or a result attributable to one person; the listing can change over time.
The gameplay recording is another direct piece of evidence: it shows the game running, including its aerial setting and mobile interface. The portfolio does not contain a release-to-source revision link, a device test matrix, or repeatable performance measurements. I therefore make no frame-rate, optimization or compatibility claims here.
What I would document next
If I were preparing a deeper technical case study, I would first recover the release history and record which build was published. I would add a short breakdown of the implemented gameplay systems, clearly map my work and my teammate’s work, and capture the game on named Android devices. That would make it possible to discuss implementation choices and performance with evidence instead of memory.
For now, the useful story is already concrete: two people, design and programming, a game built from scratch, and a public Android release. See the project page for the game capture and its evidence record, or open the Google Play listing.