class: center, middle, frontpage .center[] ## Töddl Labs --- # Agenda - Introduction - Presentation - Workflow --- # Introduction - Considered Twitter clone or collaborative coding - Decided to make a turn-based game --- # Vision - Online turn-based strategy game - Multiple users - Inspired by Travian and Risk - Expand forces to gain powers - Fair conflict resolution - Is RoR suitable for game dev? .right.illustration[] --- # Product - Production server: https://game.kakeboksen.td.org.uit.no - Demonstration - Map generation and technologies ??? ## Demonstration - Make a user - Faq - Move a unit/split a unit - Show the Overview for scale - Demonstrate a battle - Hiscores/possibility of seasons? ## Map generation and technologies - Short explanation of map generation (1-2 minutes) - Mention that the frontend is reactJS and we switched to PostgreSQL --- # Map Generation - Different tile types allow tactical play and visually interesting playfields - How do we assign different types to the board? - Assigning with uniform randomness looks chaotic and reduces tactical opportunities - Instead, we implement a 2D map generation algorithm - Based on Perlin noise - Overlay multiple noise maps, then apply smoothing/interpolation to generate a heightmap, and assign tile types based on the tile’s height - Creates local and global variation --- # Map Generation .center[] .center.caption[Initial spike - javascript implementation] --- # Map Generation .center[] .center.caption[Final solution - ruby implementation] --- # Rules - How to deal with many players concurrently? - Must design rules to allow concurrent play, and allow fair resolution of these rules - Two-stage solution: enumerate potential conflicts, then resolve them - Requires performant DB: for 64x64 playing field, SQLite required 130 seconds to process rules at worst - Moving to PostgreSQL lowered this to 8 seconds --- # Workflow - Scrum-based method: - Product owner and scrum master - Scrum meetings twice a week - Maintains pillar concepts of Scrum - Transparency through project and source control routines established early in the project - Inspection through mandatory code reviews, smoke testing, sprint reviews and retrospectives - Adaptation through unit testing, continuous integration and Scrum meetings --- # Git and collaboration - Issues and issue board .center[] .center.caption[The GitLab issue board, serving as our scrum board] --- # Git and collaboration - General git usage .center[] .center.caption[A sample section of our commit-graph] --- # Git and collaboration - Continuous Integration .center[] .center.caption[Continuous Integration pipelines] ??? # CI - How does it work? - What do we achieve by applying it? --- # Git and collaboration - Quality Assurance .center[] .center.caption[Example of issue of a merged branch] ??? # QA - Very important - CI is a form of QA - Code reviews are also a part of QA - Code coverage is an important tool to avoid regression - Our strict regime is used to maintain and assure quality # QA regime and agile - Workflow was rigid - ...became more agile over time due to adapting to the needs of our team - QA regime started out rigid - ...ended up becoming more rigid by applying CI and code coverage requirements - Could not become more agile because it would eventually lead to code of lesser quality --- # Conclusion - CRUD model - Agile development - QA system - Result ??? # Conclusion - We wanted to see if RoR (CRUD) was suitable for game dev - Agile workflow became more agile - QA regime did not become more agile, but more rigid - Both of which resulted in fewer conflicts and a smoother project development - ...og vi endte opp med et godt produkt...Takk for oss!