Megalopolis was created over the course of four weeks as the final for my Game Studio I: Game Design course. It features 30 unique possible events over the course of the three phases of the game (with 10 events in each phase), making it highly replayable. How the party proceeds in response to an event is determined by a voting system (which in and of itself involves a pre-vote discussion phase, followed by the actual vote, where all players reveal their votes at the same time), and each possible response will give the party different amounts of resources (money, manpower, and reputation). They must carefully manage these resources over the course of the game in order to enable specific responses to future events, which may require an existing quantity of a given resource in order to be pursuable. However, each player also has goals (in the form of quests) they must fulfill that may or may not align with the goals of other players; whichever player has the most fulfilled quests at the end of the game wins and gets to determine what happens to the fate of both the party and the city in which the game takes place.
Megalopolis is available for download on itch.io.
Megalopolis underwent several changes from the beginning of development to its finished state. Among these challenges was how to handle the voting system with regard to the issue of players being physically able to see each other’s votes. Initially, as a temporary playtesting measure, players voted by literally holding up fingers, which quickly proved to be inefficient. This was later replaced with the dice system used in the final version of the game. Players had 18 votes in total which could be spent as desired at any point in the game with the caveat that these votes do not regenerate; for example, a player could spend all 18 votes on the first event of the game, but would then not be able to vote in any events for the rest of the game because they used them all up. 18 was selected as the total number of votes for several reasons. Having a number slightly above the amount of votes necessary to vote once per turn, with a few votes left over, was successful in encouraging experimentation with the amount of votes used per turn, as players felt comfortable using more than one vote per turn with the assurance that they would not be locked out of voting later unless it was by their own volition. Additionally, 18 is neatly displayable on 3 dice, which lead to the solution for the voting problem: literally just to have players display the number of votes they were spending on the dice, which are hidden behind a blinder until the pre-voting discussion period wraps up and players reveal what result they’ve voted for.
