A game asks its audience to do something. That simple distinction changes the creative process. A player may explore in an unexpected direction, misunderstand an instruction or discover a strategy the designer never anticipated. The work therefore combines software with the design of choices, feedback and meaning. In South Africa, game development offers a useful example of technology becoming a creative medium rather than only a tool used behind the scenes.
Wits University’s digital-arts and game-design programs explicitly connect creative and technical disciplines, while the Tshimologong precinct identifies gaming among the creative industries it supports.[1][2] These are concrete parts of a local development environment. They do not guarantee that every student or new studio will find commercial success, but they show how education, experimentation and business support can meet around the task of making interactive work.
A game begins with an action
A story premise can suggest a world, but a game also needs an activity the player can perform. Moving, choosing, arranging, negotiating or solving can each become the center of an experience. The design question is what makes that action understandable and worth repeating.
Consider a hypothetical game about organizing a neighborhood festival. The player might allocate limited space, negotiate competing needs and respond to changing conditions. The theme alone does not make the game work. The designer must decide which choices matter, how consequences are shown and what creates an interesting tension between them.
This is why an early prototype can be visually simple. A few cards or basic shapes may reveal whether the central decision is engaging. Detailed artwork becomes more useful once the team understands the interaction it supports. Otherwise, the project may invest heavily in a world whose main activity remains unclear or uninteresting.
Playtesting supplies evidence the creator cannot invent
A developer knows what the game is supposed to mean. A new player does not. Watching someone try an early version can reveal confusing controls, hidden assumptions and unexpected behavior. The most useful observation often occurs before the designer explains how to proceed.
For the festival example, a player might repeatedly choose an option the team assumed was obviously poor. That could indicate a compelling alternative strategy, an unclear consequence or a misunderstanding of the objective. The team needs to investigate rather than immediately correct the player or defend the original intention.
Questions after the session can help distinguish these possibilities. What did the player think the choice would do? Which information did they notice? Where did they feel uncertain? Playtesting turns design into a cycle of proposing, observing and revising. It is not merely a final check that the buttons respond after every creative decision has already become expensive to change.
Technical and artistic work share the same system
Wits describes game design as multidisciplinary and connects teaching across arts and engineering.[1][3] That relationship reflects the nature of the work. A visual effect may depend on software behavior, while a programming decision can alter the timing or meaning of an interaction.
For example, a door opening slowly may create suspense, confusion or irritation depending on the context. The effect is not purely technical or purely artistic. The team needs to agree on the intended experience and then make the animation, sound and interaction support it.
Clear communication helps specialists work together. An artist needs to know how an asset will be used; a programmer needs to understand the behavior the designer wants. A shared prototype can make those discussions concrete. The project improves when people can point to the same moment in play and discuss what it communicates rather than relying on abstract labels such as “more immersive”.
Scope is a creative decision
A small team can imagine more content than it can finish. Every extra character, level or mechanic introduces design, testing and production work. Choosing a manageable scope is therefore part of authorship, not merely a concession to a limited budget.
A hypothetical first project might focus on one street and one evening rather than an entire city and several years of story. That smaller setting can still contain meaningful choices if the team develops them carefully. A finished experience with a clear point of view may communicate more than an enormous world with little interaction that works reliably.
Scope should be reviewed as evidence accumulates. If a mechanic requires far more work than expected, the team can simplify it, replace it or adjust the schedule. The important habit is to make the decision explicitly. Quietly adding work while leaving the deadline unchanged often transfers the cost to quality, wellbeing or the likelihood of finishing at all.
South African settings can shape the mechanics
A local setting should influence more than the names on street signs. Relationships, movement, language and everyday constraints can shape what the player does. A game becomes more distinctive when its systems emerge from a particular understanding of place rather than attaching decorative references to a generic structure.
In the imagined festival game, decisions might concern shared space, neighbour relationships and the timing of activities. The team would need research and consultation appropriate to the community being represented. It should avoid turning a complex place into a collection of stereotypes merely because those references are immediately recognisable.
Specificity can coexist with invention. A fictional setting can draw thoughtfully on observed experience while making clear that it is not a documentary account of every South African neighbourhood. The creative task is to establish a coherent world whose details serve the experience, while respecting the people and traditions that informed the work.
Language affects interaction, not only dialogue
Localisation includes instructions, menus, item descriptions and feedback as well as spoken lines. A translation that reads well in a paragraph may not fit a small button or preserve a joke’s timing. Language decisions therefore need to be considered while the interface is still flexible.
Players should be able to understand the action and its consequence. If a menu label is ambiguous, an otherwise elegant mechanic can become frustrating. Testing with people who use the relevant language can reveal problems that a developer working only from a translated word list may miss.
The team should also decide how language choices affect saved progress, captions and future updates. Adding another language is an ongoing commitment to keep its content accurate as the game changes. A partly translated release can create an uneven experience if important new instructions appear only in the original language without explanation.
Accessibility begins with ordinary design choices
Different players have different visual, hearing, movement and reading needs. Clear contrast, readable text, understandable controls and alternatives to relying on one kind of signal can make a game usable by more people. The appropriate design depends on the experience, but these questions are easier to address before the interface is fixed.
A puzzle that communicates success only through color may exclude information from some players. A time-sensitive instruction may be difficult for someone who needs longer to read. The team can examine whether the essential challenge is actually about those abilities or whether an alternative presentation would preserve the intended experience.
Accessibility testing should involve real tasks rather than a list of options added for appearance. Can the player start, understand feedback and recover from a mistake? A menu containing several settings is useful only if those settings address practical barriers. The strongest improvements often make the game clearer for a wide range of players, not only the group initially considered.
Performance is part of the creative promise
A game can look impressive in a development environment and perform poorly on the device its audience uses. The team should choose target hardware and test representative builds throughout production. Waiting until release preparation to discover that the core scene runs badly can force disruptive changes.
Performance decisions affect art, sound and interaction. A busy environment may need simplification, or an effect may need a different implementation. The goal is not to maximize technical complexity. It is to deliver the intended experience consistently enough that the player can engage with the game rather than struggle with it.
Download size and connectivity can matter as well. A project aimed at a broad audience should consider what must be obtained before play and what depends on an ongoing connection. These are design choices with practical consequences. They should follow the audience and the game concept rather than be copied automatically from a larger production’s business model.
Collaboration needs clear ownership of work
A small project can involve friends who begin informally and later discover different expectations. Before the game grows, the team should discuss contributions, credit, decision-making and the rights associated with code, artwork, music and writing. Appropriate advice may be needed where commercial agreements become complex.
The project should also maintain a clear record of external assets and their licenses. An image found online is not automatically available for commercial use, and a music file labelled free may carry conditions. Checking permissions early avoids a difficult replacement just before release.
Practical Organization matters too. Team members should know where the current project lives, how changes are reviewed and how work is recovered if a device fails. These habits protect creative effort. A missing file or conflicting version can consume time that a small team cannot easily replace.
Incubation supports a business, not just a prototype
Tshimologong describes support for creative industries including gaming and an interest in commercializing university research.[2] An incubator can provide an environment in which teams examine how an idea might become a sustainable activity. Its presence should not be presented as a guarantee of funding, admission or sales for any particular applicant.
The business questions differ from the prototype questions. Who is the intended audience? How will people discover the game? What will it cost to maintain? Which obligations come with the chosen distribution arrangement? A playable idea is essential, but it does not answer all of these questions by itself.
Teams should consult current official program information for actual opportunities and eligibility. Historical announcements can establish that support has existed without proving an application window is open today. The useful lesson is to treat business development as work that requires evidence, planning and revision alongside the creative process.
A release is a service commitment
Finishing a build is not the same as preparing a release. The team needs to test installation, saving, settings and the parts of the experience that may receive less attention during creative development. Clear descriptions should tell prospective players what the game offers without promising features that remain unfinished.
Support arrangements should be proportionate but real. A small studio can explain how to report a problem and what information helps investigate it. If an update changes saved progress or another important behavior, the communication should be clear. Players should not have to infer the effect from a vague announcement.
Post-release work also needs boundaries. A team should distinguish essential fixes from every suggested addition and avoid making public commitments it cannot support. Listening to players is valuable, but a coherent product still requires judgement about which changes serve the game and which would create a different project entirely.
Portfolios should demonstrate completed decisions
For someone entering the field, a portfolio can show how an idea became playable. A short explanation of the person’s role, the problem addressed and the result helps a reviewer understand the contribution. Collaborative work should be credited accurately rather than presented as though one person made every element.
A small finished game can reveal useful skills: clear interaction, consistent feedback, thoughtful scope and the ability to respond to testing. Screenshots alone may not show those qualities. A brief playable build or an accessible demonstration, shared with the appropriate permissions, can communicate how the experience actually works.
Educational programs offer one route into this work, but the value of any route depends on the skills and evidence developed. Wits’s multidisciplinary approach is a concrete local example.[1][3] It should not be turned into a universal recommendation that one qualification guarantees a career or that every creator needs the same path.
Games are a form of cultural authorship
A game can invite people to explore a place, negotiate a system or experience the consequences of a choice. That gives South African creators opportunities to work with local ideas in a medium where the audience participates. The technological achievement is intertwined with the design of that participation.
The education and incubation examples discussed here show parts of the environment that can support the work.[1][2][3] The next measure is what teams are able to finish, how well it communicates and whether they can sustain the practice. A growing collection of tools is useful when people also gain the judgement and support needed to use them effectively.
For a new creator, the most productive beginning may be a small, testable interaction rooted in a clear idea. Build it, watch someone play and revise what the evidence reveals. That cycle connects software skill with cultural imagination. Over time, it can turn a local observation into an experience that other people can enter, question and remember through their own choices.
Sources
[3] Wits University. Game Design programme overview. Checked 23 September 2026.