Writing IsoMob: A Cross-Platform Game Engine Thesis in LaTeX (Part 5 of 6)

The Thesis Series

This is Part 5 of a 6-part series on learning LaTeX and writing my Masters thesis at Oakland University.

1. Starting a Thesis: Why I Chose LaTeX Over Word
2. Formatting Hell: 19 University Templates and Why LaTeX Wins
3. IEEE Citations and BibTeX: Academic References Done Right
4. LyX: The WYSIWYG Path to LaTeX
5. Writing IsoMob: A Cross-Platform Game Engine Thesis in LaTeX (you are here)
6. LaTeX Templates, Final Formatting, and Lessons Learned
7. The Finished Thesis: 150 Pages Later

---

Midnight, August 25th

It’s just past midnight and I’ve set up the SVN working copy, added all the thesis files to version control, and the LyX document is taking shape. The thesis title is locked in:

CROSS-PLATFORM OPEN SOURCE ISOMETRIC GAME DEVELOPMENT TARGETING THE ANDROID OPERATING SYSTEM

The thesis has grown from the outline I sketched back in December into a 1,000+ line LyX document with 9 major sections, 3 appendices, and 17 references. Tonight I added the figures – isometric projection diagrams and comparison images – and the Flash asset file for the engine’s animations.

The Thesis at a Glance

The document I’m writing describes IsoMob, an open-source isometric game engine I built in HaXe. The core idea: write one codebase that compiles to Android (Java), Flash (ActionScript 3.0), Desktop (C++), and Web (HTML5/JavaScript). A solo developer shouldn’t have to rewrite their game four times to reach four platforms.

Here’s how the thesis breaks down:

Section	Topic	What It Covers
1	Introduction	Motivation, mobile market, cross-platform problem
2	Related Work	Corona SDK, PhoneGap, Titanium, Cocos2d, native approaches
3	Engine Design	Isometric projection, scenes, entities, rendering, depth-sorting
4	AI	Seek, flee, wall avoidance, formations, A* pathfinding
5	Physics	Euler integration, Verlet integration, limitations
6	Application	Game mechanics, scenes, inventory, characters, animation
7	User Interface	Menus, controls, widgets
8	Implementation	Performance, FPS, memory, cross-platform difficulties
9	Conclusion	Contributions, future work

Plus three appendices: the IsoMob API reference, application design parameters, and XML parsing documentation.

Note: This was the working draft structure. By the time the thesis was defended in 2013, it had been restructured into 6 chapters (consolidating Physics, Application, and UI into the Engine Design and Implementation chapters), expanded to 4 appendices, and grown from this 11-page outline to ~150 pages with 70+ figures and performance benchmarks across four platforms.

Structuring a Technical Thesis in LaTeX

The Front Matter

Every thesis starts with front matter – title page, abstract, table of contents. In LyX, the title page elements are just layout types:

\begin_layout Title
CROSS-PLATFORM OPEN SOURCE ISOMETRIC GAME DEVELOPMENT
 TARGETING THE ANDROID OPERATING SYSTEM
\end_layout

\begin_layout Author
ANTHONY J. DIPERNA
\end_layout

\begin_layout Author
THESIS FOR THE DEGREE OF MASTERS OF SCIENCE
 IN EMBEDDED SYSTEMS
\end_layout

\begin_layout Date
OAKLAND UNIVERSITY
\end_layout

\begin_layout Date
2011
\end_layout

The Abstract layout generates the abstract environment, and the table of contents is a single inserted command. LaTeX handles the rest – page numbering, formatting, everything.

Sections and Depth

The thesis uses three levels of hierarchy:

• Section – major chapters (Introduction, Engine Design, AI, Physics, etc.)
• Subsection – chapter divisions (Isometry, Scenes, Walls, Rendering)
• Subsubsection – detailed topics (Axonometric vs Dimetric, A*)

In LyX, switching between these is a dropdown selection. In raw LaTeX, it’s \section{}, \subsection{}, \subsubsection{}. The numbering is automatic: Section 3, Subsection 3.1, Subsubsection 3.1.1.

This hierarchical structure maps perfectly to the thesis content. The Engine Design section (3) has subsections for each major system (Isometry 3.1, Scenes 3.2, Rendering 3.6), and each of those has subsubsections for specific topics (Depth Sorting 3.6.2, RTrees 3.6.3).

Writing Technical Content

The real work of thesis writing is explaining complex systems clearly. Here’s how different parts of the thesis translate to LaTeX:

Prose explaining design decisions:

Rather than creating an entire game engine from scratch, I designed
IsoMob based on proven game engine components. The Axonometric
projection is based on the very first isometric game "Knight
Lore" \cite{onFilmation}, AI is based on steering
behaviors \cite{steeringBehaviors}, the physics is a mix of Euler
and Verlet Integration.

Citations inline, concise, clear. The \cite commands resolve to numbered IEEE references automatically.

Comparison lists for related work:

\begin{itemize}
  \item Corona SDK
  \begin{itemize}
    \item Yearly Fee
    \item Each additional piece of SDK costs more money
    \item No one has done anything isometric yet (20mil downloads)
  \end{itemize}
  \item PhoneGap -- HTML5 Based
  \item Titanium -- HTML5 Based
  \item GameSalad -- HTML5 Based
\end{itemize}

The Related Work section compares five cross-platform strategies (Scripting, Flash, AIR, HTML5, Consistent API) with their limitations. Nested lists make the comparisons scannable.

Figures for visual concepts:

The isometric projection explanation needs diagrams. I have two key figures:

• thesisIsometricPicture.png – showing what isometric projection looks like
• thesisIsovsDimetric.png – comparing isometric and dimetric projection angles

In LyX, inserting these is point-and-click. Under the hood, it generates:

\begin{figure}[h]
  \centering
  \includegraphics[width=0.8\textwidth]{figures/thesisIsometricPicture}
  \caption{Isometric Projection}
  \label{fig:isometric}
\end{figure}

The figure floats to the best position on the page, gets numbered automatically, and appears in the List of Figures. Cross-referencing it elsewhere is just Figure~\ref{fig:isometric}.

The Hardest Sections to Write

AI (Section 4)

Explaining steering behaviors in academic prose is a challenge. Craig Reynolds’ original GDC paper is brilliantly clear, but translating his concepts into a thesis chapter means balancing mathematical precision with readability. The section covers:

• Seek: vector from current position to target, normalized and scaled to max speed
• Flee: the inverse – vector away from a threat
• Wall Avoidance: ray-casting from the entity to detect walls, generating avoidance forces
• Object Avoidance: similar to wall avoidance but for dynamic objects
• Formations: coordinated group movement patterns
• A* Pathfinding: the graph search algorithm for navigating the isometric grid

Each behavior needs both a conceptual explanation (what it does, why it matters) and a technical description (the math, the data structures). LaTeX’s equation environments handle the math cleanly, while the prose connects it to the game engine context.

Cross-Platform Difficulties (Section 8)

This section is where the thesis gets honest about what doesn’t work perfectly. HaXe’s promise of “write once, run everywhere” has real friction:

• Android: JNI bridge overhead, touch input differences, memory constraints
• Flash: SWF file size limits, ActionScript 3.0 runtime behavior
• Desktop: C++ compilation differences, platform-specific rendering paths

Writing about limitations in an academic thesis requires a careful tone. You’re not complaining – you’re documenting the engineering tradeoffs and contributing knowledge about what cross-platform development actually involves in practice.

What LaTeX Gives Me That Word Can’t

Now that I’m deep into the writing process, the LaTeX advantages are paying off daily:

Reorganization Is Free

Last week I moved the Physics section from position 6 to position 5. In LaTeX: cut and paste the section block. All section numbers, cross-references, and the table of contents update on the next compile. In Word, this would have been an hour of renumbering and checking.

Consistent Formatting Across Sessions

I write in bursts – sometimes a subsection in an evening, sometimes an entire chapter over a weekend. Every time I open the document, the formatting is exactly as I left it. No style corruption, no mysterious font changes, no “Heading 2 now looks different because I pasted from another document.”

The Bibliography Grows Organically

As I write each section, I add \cite{} commands for sources I reference. The bibliography at the end reflects exactly what I’ve cited – nothing more, nothing less. I don’t maintain a separate reference list. It maintains itself.

Figures Stay Put

LaTeX’s float placement can be frustrating, but once you understand the [h], [t], [p] options, figures go where you expect. More importantly, they stay where you put them. In Word, adding a paragraph above a figure can push it to the next page, cascade-breaking every subsequent figure position.

SVN and the Writing Process

Having the thesis in SVN alongside the engine code means I can correlate writing milestones with code changes. When I write about the A* implementation, I can reference the actual commit where I implemented it. When I describe the rendering pipeline, I can verify my description matches the code.

The SVN repository on Unfuddle (hobo.unfuddle.com/svn/hobo_main/doc/thesis) tracks:

• The main LyX file
• All figures
• Example documents
• The Flash asset file for animations

Every writing session is a potential commit. Every revision tells the story of how the thesis evolved.

Up Next

The thesis is taking shape. The content is written (or at least outlined to the subsection level). What remains is the polish: finding and applying proper LaTeX templates that match OU’s formatting requirements exactly, final proofreading, and preparing for submission. That’s the next and final post in this series.

---

This post is part of a series documenting my Masters thesis journey at Oakland University. The thesis describes IsoMob, an open-source cross-platform isometric game engine written in HaXe.