Why did Dcard choose GameNobility?
A partnership that went from "we want to make a game" to a real launch
What makes this project worth talking about is not just that the game got finished. It is how both sides turned an unclear idea, step by step, into a product that could be built, tested and actually run inside the Dcard app.
This is an in-app web game development case: GameNobility helped Dcard narrow a vague brief down to hyper-casual gameplay, then handled the API, leaderboard, sharing, Android/iOS compatibility and cross-team testing before launching inside the Dcard app.
The partnership began at a developer meetup
The partnership between Dcard and GameNobility began at a game developer meetup in Taipei. Dcard was getting to know different development teams at the time. It knew it wanted to make a game, but did not yet have a full answer about what the product should look like.
After meeting, the two sides talked about ten more times, clarifying the game's purpose, target users, budget and technical constraints one by one. For GameNobility, this is where a project really begins: not starting work the moment a client asks for something, but first figuring out why the game is worth making.
Why did Dcard want to make a game?
Dcard is a community platform to begin with, so the point of making a game was not to earn money from the game itself. The goal was to increase user interaction and give its own character IP more chances to be seen and remembered.
Early on, mahjong and card games were discussed, but these formats can easily make people associate the brand with gambling. In the end, the team chose hyper-casual gameplay with simple rules that is easy to pick up: users can start quickly and chase high scores, and it suits leaderboards and sharing. For the brand, this choice is fun without overshadowing the brand's own characters.
The real challenge was not making the visuals
The game was built with web technology but had to sit directly inside the Dcard app. Users can start playing on the platform they already use, with no separate download. It looks convenient, but behind it lie the Dcard API, leaderboard, data exchange, sharing features and compatibility across Android and iOS.
During development, the two sides also had different understandings of how front-end, back-end and API integration work was divided. Rather than passing messages back and forth through contacts, GameNobility brought both sides' engineers into the same discussion to spell out the technical issues and reconfirm what each side needed to deliver.
This experience made the team even more certain: what cross-industry collaboration needs most is not just technical skill, but the ability to turn jargon into language the other side can understand and act on.
Working with a large platform tests more than development speed
Dcard has its own product, engineering and testing processes. For an outside development team, this kind of partnership cannot just mean building a good game and handing it over. You have to step into the client's existing workflow and align with its technical specs, testing methods and launch environment. Who confirms each requirement, who handles each piece of code and who makes the call when problems come up all need to be made clear.
This is also what is most easily overlooked when working with large companies. The bigger the company, the more roles are usually involved in a project, from planning, brand and engineering to decision-makers, and each cares about different things. GameNobility has to understand both the brand's expectations and the technical constraints, then turn information from both sides into specs that can be executed.
In this project, GameNobility did not just wait passively for requirements. When the direction was unclear, it helped narrow down the gameplay; when API and responsibility issues came up, it had both sides' engineers talk directly; and in the testing phase, it had to cover the real Dcard app, Android and iOS environments. Only by keeping up with a large platform's way of collaborating can a project steadily make it to launch.
After launch, user retention and sharing exceeded Dcard's expectations, and the two sides have kept in touch since the project ended.
Dcard also recognizes its experience working with GameNobility as a representative success story for this type of partnership.
Why is communication before kickoff the most important?
GameNobility believes that the most important stage of game development is often not coding, but the communication before kickoff. When goals, features, budget, responsibilities and acceptance criteria are made clear at the start, production goes much more smoothly.
If new requests come up mid-development, the team does not simply say yes or flatly refuse. It first explains how much extra work is involved and which timelines are affected, then decides with the client whether to add budget, adjust features or keep the original direction. When necessary, pausing first is more responsible than finishing and then throwing everything out.
Industry experience tells the team which problems to tackle first
Game development is not done well just because the planning, art or code is good on its own. A design may look beautiful yet not suit actual development; a feature may work on one device yet not stay stable across different systems. The value of project experience is that the team can spot likely risks before problems actually happen.
GameNobility has long worked on game projects and has experience collaborating with game industry teams and companies in other fields. So when a brief comes in, the team first assesses whether the gameplay fits the budget, whether the tech needs back-end support, whether the visual specs are feasible, and whether system updates and warranty will be involved later. These seemingly small questions are often what decides whether a project finishes on time.
More importantly, the team knows that different industries speak different working languages. With fellow game companies, many specs can be discussed directly; with community platforms or general businesses, the game development process needs to be explained more clearly. Being able to re-explain things in a way the client understands, instead of just throwing out jargon, is a skill GameNobility has built from its industry experience.
What did this Dcard project leave behind?
In the end, the game was completed and launched on the Dcard platform. According to team interviews, user retention and sharing were higher than expected at the time, and the partnership became a key case for GameNobility in shaping its approach to working with large platforms.
What this project really proves is not just that GameNobility can build a game, but that the team has the communication, integration and delivery skills needed to work with large platforms. On projects where requirements are still unclear, many roles are involved and cross-company collaboration is needed, GameNobility can find the direction together with the client, handle risks early and finally turn that direction into results ready to launch.
Further reading
- Gamification marketing: building interactive brand experiences
- 3 things that really matter when evaluating game developers
FAQ
How did Dcard and GameNobility start working together?
The two sides met at a game developer meetup in Taipei. At the time, Dcard was talking to different game development teams and wanted to try a new interactive product, but its requirements were not yet settled. After the event, GameNobility kept talking with the Dcard team. Over about ten meetings, they gradually clarified the game's purpose, target users, gameplay, budget and technical constraints before arriving at a development direction that could be formally executed.
Why did Dcard develop a game on a community platform?
The goal of the game was not to make money from the game itself, but to add more interactive moments to the platform while giving Dcard's own character IP more chances to be seen and remembered by users. With simple gameplay, a leaderboard and sharing features, users do more than read content on the platform; they can interact more directly with the brand's characters.
Why choose a hyper-casual game instead of mahjong or card games?
Early in the project, mahjong and poker were discussed because they are part of young people's everyday entertainment. However, card games can also make people associate the brand with gambling. After evaluation, the team chose hyper-casual gameplay with simple rules that is easy to pick up. Users can start quickly, chase high scores and join the leaderboard, which better fits Dcard's goals of light interaction and promoting its character IP.
Does this Dcard game need a separate download?
No. The game was built with web technology but is integrated directly into the Dcard app. Users can enter the game from the platform they already use, without installing a separate app. The experience is convenient, but the development side had to handle compatibility across the Dcard app, the web game, the API and the different Android and iOS environments.
What was the hardest technical problem in the Dcard game project?
The hard part was not just building the visuals and gameplay, but making the game run reliably inside Dcard's existing system. The project involved the Dcard API, leaderboard, data exchange, sharing features and integration between the front end and back end. Different phone systems and the in-app runtime each have their own rules, so GameNobility had to keep testing and adjusting to make sure platform differences would not cause problems in real use.
How did GameNobility work with Dcard's engineering team?
Early in the project, the two sides understood the split of front-end, back-end and API integration work differently. Relaying messages only through non-technical contacts easily creates information gaps. GameNobility then brought both sides' engineers into the same discussion to reconfirm technical requirements, responsibilities and how the work would be done. This direct, practical collaboration let technical problems actually get solved instead of bouncing between contacts.
How does GameNobility handle it when a client cannot clearly describe their needs at first?
GameNobility does not rush to start work. It first confirms why the client wants to build the product, who it will serve and what results they hope to achieve. It then looks for the overlap between brand positioning, gameplay, technical feasibility, budget and timeline. The Dcard project went through many discussions early on precisely because the team wanted to narrow down the direction first, rather than discover after planning, art and code were already underway that everyone had different goals in mind.
How does GameNobility handle additional requests during development?
The team first assesses whether the new request goes beyond the features and quote originally agreed, then explains to the client which costs and timelines the extra work will affect. Both sides can choose to add budget, adjust features or keep the original direction. If there is still no consensus on the core direction, related work may be paused when necessary. Stopping to talk the problem through usually protects both the client and the development team better than continuing to build and then throwing everything out at the end.
What skills does working with a large platform require?
Beyond game design, art and programming skills, you also need to fit in with a large company's existing product process, engineering specs, testing methods and decision-making. Large projects usually involve different roles such as planning, brand, engineering, testing and decision-makers, and each cares about different things. GameNobility has to understand both the brand's expectations and the technical constraints, then organize the information into specs everyone can act on. This is the key to whether a large platform partnership moves forward smoothly.
