LaTeX Templates, Final Formatting, and Lessons Learned (Part 6 of 6)
The Thesis Series
This is Part 6 (the finale) of a 6-part series on learning LaTeX and writing my Masters thesis at Oakland University.
- Starting a Thesis: Why I Chose LaTeX Over Word
- Formatting Hell: 19 University Templates and Why LaTeX Wins
- IEEE Citations and BibTeX: Academic References Done Right
- LyX: The WYSIWYG Path to LaTeX
- Writing IsoMob: A Cross-Platform Game Engine Thesis
- LaTeX Templates, Final Formatting, and Lessons Learned (you are here)
- The Finished Thesis: 150 Pages Later
The Final Piece: Templates
Today I downloaded latextemplates.zip – a collection of LaTeX thesis templates to nail Oakland University’s formatting requirements. After nine months of work on this thesis, the content is written. Now it’s about making every margin, heading, and page number comply.
LaTeX templates are .cls (class) files that encode an institution’s formatting rules. Load the template, and it handles margins, heading styles, spacing, page numbering – all of it. The thesis document itself stays clean:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
\documentclass{ou-thesis}
\thesistitle{Cross-Platform Open Source Isometric Game Development
Targeting the Android Operating System}
\thesisauthor{Anthony J. DiPerna}
\thesisdegree{Master of Science in Embedded Systems}
\begin{document}
\frontmatter
\maketitle
\tableofcontents
\mainmatter
\chapter{Introduction}
This thesis presents an isometric game engine...
\end{document}
That’s it. The formatting rules live in the template. The author writes content. The compiler enforces the rules. This separation is what makes LaTeX so powerful for long documents – and this thesis would eventually reach 150 pages.
But Enough About LaTeX – Let’s Talk About Android in 2011
The real story of this thesis isn’t the tooling. It’s what happens when you try to run a game engine on Android hardware from 2011.
Here’s the landscape: smartphones are exploding. There are 150 million smartphones in the US alone. 35,000 new Android apps are hitting the market every month. Facebook is turning small studios like Zynga and Playfish into juggernauts that compete with EA. Everyone wants to ship a mobile game.
The problem? The hardware is brutal. An HTC Incredible ships with 512MB of RAM, a 1GHz single-core Snapdragon, and an Adreno 200 GPU that can barely keep up with 2D sprite rendering. An Acer Iconia tablet with its Tegra 2 is considered powerful. These aren’t the phones we carry today – these are devices where every frame matters, every texture swap costs you, and running out of memory means a hard crash.
This is the world IsoMob was built for.
What IsoMob Actually Does
IsoMob is a cross-platform isometric game engine written in HaXe. One codebase compiles to four targets: Android (via C++/NDK), Adobe Flash (ActionScript 3.0), Windows (C++), and Web. The idea is simple – a solo developer shouldn’t have to rewrite their game four times to reach four platforms.
The thesis compares IsoMob against the competition of the era:
| Engine | Cost | Language | Android | Flash | PC | Web | Isometric |
|---|---|---|---|---|---|---|---|
| Unity Pro | $5,000 | C# | Y | Y | Y | N | N |
| Corona SDK | $350/yr | Lua | Y | N | N | N | N |
| Cocos2D | Free | Java/Obj-C | Y | N | Y | N | N |
| Marmalade | $499/yr | C++ | Y | N | Y | N | N |
| PhoneGap | Free | JS | Y | N | Y | Y | N |
| IsoMob | Free | HaXe | Y | Y | Y | Y | Y |
IsoMob was the only free engine that targeted all four platforms and supported isometric games natively. That gap in the market was the thesis.
Squeezing Performance Out of Early Android
The most interesting part of the thesis – and the part that consumed the most engineering time – was performance optimization. The engine needed to maintain 30 FPS with 200+ bullets on screen, 10+ AI enemies running steering behaviors, and collision detection happening every frame.
On a 2011 Android phone, that’s a tall order.
The Optimization Tricks
Ditching classes for arrays. The original bullet design used a class per bullet. With 200 bullets active in a scene, the object overhead was killing performance. The fix was borrowed straight from 1984 – the Filmation engine that powered Knight Lore ran 128 rooms with animated sprites, menus, and game logic in 48KB of ROM. IsoMob adopted a similar approach: bullets became entries in a flat integer array, with behavior encoded in the data itself. No objects, no overhead.
Centralized game loop. Instead of each entity managing its own update timing, everything feeds through a singleton ControlLoop that fires at fixed intervals (33ms for 30 FPS). Tasks implement IPeriodicTask with a single update():Bool method. When the task returns true, the loop disposes it. Think of it as a timed ISR from embedded systems – because that’s exactly what it is.
Texture swap management. On mobile, GPU texture memory is precious. How and when you swap textures in and out of GPU memory turned out to be the single biggest factor in overall FPS. Getting this wrong meant stuttering. Getting it right meant smooth gameplay on hardware that had no business running a game this complex.
The Benchmark Results
Two test suites stress-tested the engine. The bullet test spawned projectiles in expanding rings to hammer rendering. The unit test spawned AI enemies with full steering behaviors (seek, flee, wander, wall avoidance, object avoidance) and collision detection.
Bullet Tests – firing projectiles every 500ms, measuring FPS over 100 seconds:
| Platform | 18/round (148 max) | 36/round (207 max) | 64/round (534 max) |
|---|---|---|---|
| Windows C++ | ~30 FPS | ~28 FPS | ~24 FPS |
| Adobe Flash | ~30 FPS | ~30 FPS | ~15 FPS |
| Android tablet (Tegra 2) | ~30 FPS | ~18 FPS | ~7 FPS |
| Android phone (Adreno 200) | ~23 FPS | ~10 FPS | unplayable |
Unit Tests – spawning AI enemies with full steering behaviors and collision:
| Platform | 60 enemies | 115 enemies |
|---|---|---|
| Windows C++ | 30 FPS (locked) | 30 FPS (locked) |
| Adobe Flash | 30 FPS (locked) | ~27 FPS |
| Android tablet | ~25 FPS | ~15 FPS |
| Android phone | ~15 FPS | Out of memory crash |
The Windows C++ target dominated everything – it never broke a sweat. Flash performed surprisingly well, handling 36 bullets per round at a locked 30 FPS. But the real story is Android.
The tablet could handle a real game scenario (18 bullets per round, a handful of AI enemies) at a playable frame rate. Push it harder, and it fell apart. The phone was worse – the Adreno 200 GPU simply couldn’t keep up with the texture rendering, and the 512MB of RAM meant the unit test with 115 enemies caused an out-of-memory crash.
The gap between the phone’s Adreno 200 and the tablet’s GeForce chip was massive. The Adreno 205 (released shortly after) would dramatically improve things, but in 2011, Android fragmentation meant you were designing for the lowest common denominator.
The AI That Made It Interesting
The thesis covers AI in depth – not theoretical AI, but the practical kind that makes enemies feel alive in a game. IsoMob implements Craig Reynolds’ steering behaviors: seek, flee, wall avoidance, object avoidance, wander, and formations (boids flocking). These combine into a finite state machine where enemies wander the map searching for the player, attack when they find them, and retreat when their health drops.
Wall collision detection uses a feeler-based approach – the entity projects vectors ahead of its movement direction and tests for line-segment intersections with walls. Object avoidance does something similar but against bounding circles. It’s the kind of math that looks elegant on paper and requires careful optimization to run at 30 FPS on a phone with a 1GHz ARM core.
The thesis works through all of it: rotation matrices for feeler projection, dot products for determining if an object is in front of or behind an entity, Euclidean distance calculations for collision radius checks. If you’re interested in implementing steering behaviors in a resource-constrained environment, the full thesis PDF walks through every equation.
Lessons Learned (About LaTeX and Everything Else)
LaTeX Was Worth It
150 pages. 70+ figures. 13 tables. 4 appendices. 18 bibliography entries. All of it compiled from source to a perfectly formatted PDF every time. No style corruption, no mysterious font changes, no figures jumping to random pages. For any document over 20 pages, LaTeX pays for itself.
Gather Requirements Before You Write
I spent months collecting Oakland’s 19 formatting templates before writing a single paragraph. That sounds slow, but it meant I configured my tools correctly from day one. Discovering the 1.5-inch left margin requirement halfway through writing would have been painful.
BibTeX Eliminates a Whole Class of Bugs
I never manually formatted a reference. Never renumbered a citation. Never had a dangling reference. BibTeX handles the bookkeeping, and it handles it perfectly.
Treat Writing Like Code
The thesis lived in SVN alongside the engine code. Every writing session was a potential commit. Restructuring a chapter was a cut-paste-compile cycle, not an hour of renumbering in Word. Sections could be written in any order and they’d be numbered correctly in the final document.
The Full Thesis
The finished thesis was defended in 2013 – nearly two years after this blog series. What started as a 1,000-line LyX outline grew into a 150-page document with performance benchmarks, UML diagrams, and actual game screenshots running on four platforms.
- Full thesis PDF (~150 pages) – performance charts, game screenshots, architecture diagrams, the works
- Early draft PDF (11 pages) – the skeleton from 2011 for comparison
This concludes the 6-part series on learning LaTeX and writing my Masters thesis at Oakland University. The thesis describes IsoMob, an open-source cross-platform isometric game engine written in HaXe that targets Android, Flash, Desktop, and Web from a single codebase.