Building a Game with Q Developer - an intern's journey

With the world taken over by Generative AI hype, I wanted to understand how a relatively new developer would cope with being given the freedom of using any and all the AI assistance they chose. In a bid to make it as realistic as possible, I threw my intern in the deep end with a choice, 1/ choose the well trodden path and use a tech stack he’s familiar with and only experiment with the game engine, 2/ Follow my mad scientist idea and try a whole new stack. Smit, fearlessly chose to forge a new path and in a day came back to me with his tech stack - TypeScript, Phaser for the frontend and Rust for the backend all being hosted in a variety of AWS services.

Generative AI has incredible potential to take a lot of the tedium out of our lives as LLMs, the most common form of GenAI, are proficient in generating paragraphs based on the incoming query. And because language and grammatical structure can mimic thought patterns and intent, LLMs excel at recognising intent and responding with the most expected structure and words. This is an oversimplification of the approximately 60 years of NLP research that has brought us to this point. LLMs can not only generate plausible human prose, but they can effectively write code letting them interact with humans in a natural way, and with computers/systems in a programmatic way.

However, LLMs are explicitly built and trained to always answer even when they “don’t know” the answer; leading to the rise of the “hallucination”. Most of the hallucinations can be easily spotted by an expert operator however, all of them look “about right” at the first glance or with an untrained operator. For my intern, this meant often accepting a suggestion they didn’t fully understand only to realize after spending a few hours that the LLM has led them astray.

All of that to say, I wanted to experiment with what the next year of software development looks like for professionals adopting GenAI tooling. My hypothesis being, most veterans will take time to accept the tools as something that can reduce the toil of their jobs, and most rookies embracing the tool and potentially being led astray by, as our crop of interns described: “a 2-year-old with the knowledge of the internet, but no idea how to apply it”.

Our fearless intern started the project by breaking down the idea and making a project plan and creating a single player demo with the Phaser game engine. He’d chosen to eventually build a multiplayer medieval fantasy fighting game and generated some nice level backgrounds for it. After asking Amazon Q to guide him on how to build player movement and interactions out as his first task, he got the basic interactions functioning in no time, a little knight in the game would run around and jump based on keyboard input, admirable for 2 days in an unfamiliar framework.

Understanding his excitement at getting past this first milestone in the project, I recommended he consider a way to track, send, and receive these “player events” so that he can reuse the keyboard-based movement function with remote player inputs. He quickly refactored his code with Amazon Q and built a struct that represented the “player movement” event usable across the entire game state.

Now that he had established the first of his data standards, I asked him to think about how the backend will be setup and what network protocols to use. He was receptive to the idea, and used one of the more novel features of Q Developer called Feature Development to formalise his ideas. Q Developer gave him abstract implementations of the network protocol and a more concrete implementation of the player interactions before understanding the PlayerData interface the frontend uses, immediately placing the backend at odds.

This led him on a 4 day journey of understanding Rust and implementation logic that Q Developer had come up with, given the admittedly ambiguous input. Admittedly, it made a couple of wise choices, the most notable being the preference for web sockets over HTTP APIs, and opting for a robust web socket framework as a starting point. But it also created a lot of player related boilerplate that didn’t need to exist and immediately led him astray and instead of changing the Rust he wasn’t familiar with, he set about tweaking the frontend to match what the backend expected.

At the end of the week, we got together for our 1:1 and he laid out the problems he was facing and what his plans for next week were; we sat down and discussed all the code, prompts, and progress he’d made and realized that he was better off salvaging Q Developers work, but then implementing the Player interfaces from scratch. My recommendation was to directly feed the TypeScript interface to Q Developer and have it come up with an appropriate collection of Rust types, including what macros would be needed, more on this in a later part. And voila, we had a proper data standard across the frontend and backend.

He spent the rest of the day figuring out how to use web socket communications from the frontend to establish the client-server architecture of our multiplayer game and with the help of Q come up with an implementation that passed web socket control from the game instance down to the player so that every keyboard input was immediately transmitted, more on this in the next part.

To sum up the first of four (?) articles, we have a functional frontend on the client but a backend that didn't connect to the player. The project is about 200 lines of code so far, and our intern claims that Q Developer wrote the entire player movement stack and helped with refactoring amounting to about 50% of the code written or modified by AI.

See you in the next part,

Shardul