API Programming — Research, Analysis and Justification of APIs

Research, Analysis & Justification of APIs

When starting this project, the first question we were asked was, “What is an API?” Many definitions exist online but most feel abstract. (Qiu, 2016, as cited by Ofoeda et al., 2019) argues that Application Programming Interfaces (APIs) support software reuse by providing pre-implemented functionality, reducing the effort and time required to build software. In short: APIs help developers ship faster by reusing robust, existing building blocks instead of reinventing the wheel.

Our team’s initial focus was on AI APIs for games—specifically Large Language Models (LLMs) for dynamic NPC dialogue. For example, OpenAI’s GPT-4 API uses transformer architectures trained on vast datasets (Brown et al., 2020) to generate natural-language responses; parameters allow tuning tone/length/style (OpenAI, 2023). We also explored speech-to-text and text-to-speech via Microsoft Azure Cognitive Services (Microsoft, 2023) to enable voice-interactive NPCs.

I compared common API models—REST, RPC, and GraphQL. REST (Fielding, 2000) is ubiquitous and simple (CRUD over HTTP), and OpenAI’s API is RESTful. RPC emphasises efficiency by invoking remote methods directly, while GraphQL lets clients query precisely the data they need (Sadalage & Fowler, 2012). We leaned toward REST for accessibility and ecosystem support.

Reality check: cost. Many AI APIs are pay-as-you-go—OpenAI by tokens, Azure Speech by character counts (Microsoft, 2023; OpenAI, 2023). With limited budget, and the integration surface (LLM + STT + TTS) being large, we pivoted to a scoped, feasible target that still taught us API design in games: Unity Netcode for GameObjects. Netcode provides state synchronisation for real-time multiplayer and integrates cleanly with Unity (Unity Technologies, 2023). Unlike REST-driven request/response, Netcode focuses on low-latency replication and authority models—ideal for our multiplayer chatroom brief.

Problem Solving & Appraisal

Early on, I struggled with APIs in general. Documentation assumed familiarity with concepts like replication, message passing, and server authority. I bridged the gap through tutorials, forums, and peer help until I had a baseline to contribute.

A tooling setback blocked me: Git wasn’t in my system PATH, so I couldn’t open the shared repo. A teammate shared a tutorial; adding Git to PATH fixed it and unblocked my work—good reminder that collaboration matters even for “simple” issues.

Catch-up pressure made integration harder. I needed my TeamChat to cooperate with an existing PlayerID. After tracing references and project hierarchy, I found PlayerID lived on the NetworkManager; attaching TeamChat alongside it let them coordinate. Then I hit a subtle but critical bug: my script inherited MonoBehaviour instead of NetworkBehaviour, breaking networking. Fixing inheritance immediately restored the expected Netcode behaviour.

Next, I needed multi-instance testing. Once I learned how to build and run several clients locally, a new bug appeared: joining players “broke” chat. Logs showed that joining disrupted team assignments. I moved team selection to server-side authority via ServerRpc and replicated state to clients, stabilising assignments.

With teams stable, chat spammed messages due to multiple triggers firing the send routine; adding an early-return guard ensured it executed once per keypress. Another design issue: messages appeared globally rather than per-team. Lacking a ready tutorial for team-restricted chat in NGO, I implemented a pragmatic solution—separate team chat panels in the UI, toggled by the local player’s team. This made messages visible only to the intended team while keeping code straightforward.

Key lessons: respect API-specific requirements (e.g., NetworkBehaviour), log deeply while debugging, test with realistic multi-client setups, and keep UI/network responsibilities decoupled.

Reflection

Our original LLM + STT + TTS vision was ambitious and informative, but Unity Netcode was the right pragmatic pivot: it fit our resources, met the module goals, and built real-time networking skills I can reuse. I grew from API novice to shipping a functioning multiplayer chatroom—with team-based messaging (still a little finicky) and clearer mental models of authority, replication, and client/server flow.

Team communication waxed and waned; I could have been more proactive during quiet periods. Even so, teammates’ steady contributions gave me a solid base to integrate my features. Going forward I’ll push for earlier alignment, keep small integration spikes, and document decisions to reduce friction.

Works Cited

  • Brown, T., Mann, B., Ryder, N., Subbiah, M., Kaplan, J. D., … Amodei, D. (2020). Language Models are Few-Shot Learners. NeurIPS 33, 1877–1901.
  • Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures. (Doctoral dissertation).
  • Microsoft. (2023). Speech-to-text and text-to-speech API documentation. https://learn.microsoft.com/
  • Ofoeda, J., Boateng, R., & Effah, J. (2019). Application Programming Interface (API) Research: A Review of the Past to Inform the Future. International Journal of Enterprise Information Systems, 15(3), 76–95. https://doi.org/10.4018/IJEIS.2019070105
  • OpenAI. (2023). OpenAI API documentation. https://platform.openai.com/docs
  • Sadalage, P. J., & Fowler, M. (2012). NoSQL Distilled. Addison-Wesley.
  • Unity Technologies. (2023). Netcode for GameObjects. https://unity.com/

Note: This diary captures my learning process—what worked, what didn’t, and why we pivoted—during the API Programming module.