The motivation behind the work lies in a persistent gap between what software engineering courses teach and what the software industry actually needs. The researchers note that professors often adhere closely to traditional expository lectures and tests, leaving students unmotivated in a subject whose learning is achieved primarily through applying content to practical projects. Citing earlier work, the authors point out that a newly graduated individual typically needs between two and three years to gain professional experience in software engineering, and that companies frequently have to supplement graduates’ knowledge to promote both technical and non-technical skills. Software’s intangible and malleable nature compounds the problem, because students who can apply theory to classroom exercises still need more experience when faced with real projects and ambiguous specifications.

ConES, whose name derives from the Portuguese terms for Construction and Software Engineering, is a role-playing game built around building blocks and inspired by established systems such as GURPS and Dungeons & Dragons. Players are placed in a team hired by a king to rebuild a castle, and each participant assumes a role that mirrors a position in a real software project. The game master plays the Customer, who knows the business rules and validates deliveries, and the Manager, who removes obstacles for the team. Players choose between the Architect, who designs structures in the LeoCAD modeling tool; the Builders, who implement the design with physical blocks; and the Tester, who monitors construction and fills out a compliance checklist comparing what was built against what was requested.

The game’s mechanics translate software engineering practices into explicit, auditable rules. Each player fills out a character sheet distributing attribute points across three categories: soft skills, hard skills, and scope mastery. Action cards, usable once per turn and tied to specific roles, grant benefits if the player passes a skill test, a dice roll in which the action succeeds when the result is less than or equal to the sum of the attributes involved. Demand cards carry the Customer’s requirements together with acceptance criteria, while event cards represent random requirement changes that force teams to adjust mid-turn. A Customer Requested Changes Sheet tracks corrections across rounds. The researchers mapped the game’s rules to the Software Engineering Body of Knowledge, so that demand cards operationalize requirements engineering, LeoCAD models simulate architectural decisions, the compliance checklist operationalizes verification, and physical construction operationalizes implementation.

A full match unfolds across five phases: Introduction and Character Creation, Turn Planning, Turn Execution, Demand Delivery, and Retrospective. In the Retrospective phase, players gain an experience point and reflect on difficulties and strategies for future turns, a structure the authors link to Kolb’s Experiential Learning Cycle. Before the classroom application, the game went through a systematic literature mapping and the validation of two prototypes. For the case study itself, the Player’s Manual was distributed a week in advance through Google Classroom, and the session was planned under the guidance of two software engineering professors, with a game researcher conducting the play.

The classroom session began an hour late because not enough students had arrived at the scheduled start time, a delay the authors acknowledge may have negatively affected the study by forcing an early finish. Once underway, the 20 students were divided into four teams of five, each with one Architect, three Builders, and one Tester. The narrative placed them at Medieval Solutions, an organization hired by a king whose castle had been attacked by orcs. The first demand was a wall, built under a 10-minute timer, and none of the teams met all the requirements on their first attempt, which the professors had anticipated given the players’ inexperience. By the second round, involving a moat, teams began using action cards effectively: one Builder from Team A passed a skill test to access four additional blocks, and Team B’s Tester passed a test allowing him to assist a Builder.

The third and fourth rounds introduced event cards and a tower demand, and the professors observed behaviors that echoed real project dynamics. Teams A and D tried to discard an unexpected event card through skill tests; Team D’s Architect succeeded while Team A’s failed, forcing that team to continue with the disruption. Team C, having missed the moat criterion of a distinct color, prioritized correcting that fault before starting the tower. As the timer ran down, players increasingly abandoned their defined roles, with Builders, Architects, and Testers overlapping in function. By the final evaluation, all teams built their structures satisfactorily, and one team even met the tower’s window criterion using unexpected blocks, suggesting that success improved as players gained experience.

The quantitative results were detailed and consistently favorable. In the background and motivation questionnaire, the three knowledge areas of architecture, construction, and testing were rated important, with means between 3.60 and 3.70, while motivation to learn software engineering showed the highest dispersion, with a standard deviation of 1.00. In the feedback questionnaire, the nine items obtained means between 3.25 and 3.95, and all nine were significantly above the scale midpoint with p values below 0.01 and effect sizes between 0.71 and 1.00. The Friedman test confirmed the differences among items were informative rather than random. The fun and challenge of the dynamics rated highest, with 95 percent of participants giving the top score, while the amount of building blocks ranked lowest, with 80 percent positive ratings. Notably, the three lowest-rated items concerned time constraints, block quantity, and complexity level, suggesting that reservations targeted the operational conditions of the session rather than the game’s design. The game master’s presence earned a mean of 3.75, and no participant produced a predominantly negative evaluation.

The collective SWOT analysis revealed both strengths and friction points. Participants praised the game’s playful presentation of the software development process, its encouragement of creativity, and one noted that its phases resembled the steps of the Agile Scrum methodology, while another described the character sheet as a form of self-assessment. Weaknesses centered on communication failures with the Customer and Manager, the absence of a planning stage, the short 10-minute time limit, and the isolation of Testers and Architects during rushed final rounds. The study also documented a revealing divergence: some participants asked for reduced complexity while others requested more complex challenges, a pattern with a standard deviation of 0.82 on the complexity item. The authors connect this to gamification research showing that player profiles, such as the Bartle archetypes or the Hexad typology, moderate responses to game mechanics, though they emphasize that the study measured Kolb learning styles, not player profiles, and could not distinguish between experience-based and motivation-based explanations for the divergence.

The authors are explicit about the study’s limits. The instruments were ad hoc questionnaires and a SWOT analysis rather than validated scales such as the System Usability Scale or the Intrinsic Motivation Inventory; no objective learning measures like pre- and post-knowledge tests were collected; the sample of 20 students from a single institution was small and homogeneous; and the anonymous questionnaires could not be linked across instruments. A controlled experiment was deliberately avoided because randomly withholding the activity from part of a single class raised pedagogical objections and would have yielded subgroups too small for statistical power. The findings therefore indicate the direction and consistency of participant perceptions, not generalizable estimates of learning gains. Future work outlined by the team includes replication across multiple institutions, adoption of validated scales, objective learning measures, incorporation of a player-profile instrument such as the Hexad scale, and extension of ConES to other software engineering knowledge areas, building on evidence that the game’s cooperative, face-to-face format surfaces difficulties, such as role isolation and communication breakdowns under time pressure, that individually mediated educational games cannot observe.

Subject of Research: A role-playing game for teaching software product construction in software engineering education

Article Title: A case study on the application of a role playing game to support the teaching of software product construction

Article References: dos Santos Guerra, A., Oliveira, S. R. B., & Furtado, J. C. C. (2026). A case study on the application of a role playing game to support the teaching of software product construction. Discover Education, 5(1), Article 1220. https://doi.org/10.1007/s44217-026-02258-3

Image Credits: AI Generated

DOI: 10.1007/s44217-026-02258-3

Keywords: software engineering education, role-playing game, ConES, gamification, case study, software construction, Lego building blocks, Kolb learning styles, SWOT analysis, computer science students, Brazil, Discover Education