This is an outline of steps in the early phases of the overall project to make Scone: a social strategy game.
First, we have to test whether the gameplay, boiled down to its most essential components, is truly engaging and fun. If not, then investing time&effort into extra features and styling won’t make it become fun. If it “fails” we fail toward success, learning from the experience and rethinking the gameplay that would embody the qualities that excite us about a game.
Prototypes need only be easy to rapidly develop to test the ideas. They will be only be seen inside the team and no effort will be wasted making it anything beyond functional.
Upon finding a winning idea for the core gameplay loop-- the actions the player will be performing repeatedly to impact the game world and get new game states to respond to-- the prototype will be scrapped in pursuit of an architecture suited to a full game.
We need a solid foundation that we will not need to switch from down the line, which would disrupt momentum and badly damage morale. This may become an iterative process of testing functionality in various architectures and packages to answer our questions.
Either way, the best approach is to recreate the winning CGL idea in the “full-scale” architecture to be certain it can be implemented. Only then can we begin expanding toward the complete vision of the game by adding features and introducing elements of the lore and setting.
Contributors contribute to a game to see their contributions become part of the game. Failing to support that need results in contributors simply not contributing. This is analogous in the FOSS world to being paid for a job in the commercial world. The project needs to begin “paying off” for people attracted to the cool game idea-- which is, in its most basic form, already working at this phase-- in order to begin approaching sustainable critical mass for the project.
Level editing is also vital early on because the game will not exist without the freedom to create the places where the game takes place. Scone may well use a simplified and map-based model of the city/town at first and various “rooms” to interact with characters in. But as things expand, we will be implementing procedural generation of urban environments, and we must be able to tweak the generator in order to ensure it creates areas that suit the gameplay we want.
This will be our first publicly released demo. It will be a basic outline of Scone’s gameplay with many features missing, but enough of the core to give people new to the game a hands-on expression of what Scone is about. It will need some polish, but not a lot. We can only “pay” people with enough imagination to get the vision and are into the ideas behind Scone.
The core functionalities are social interaction, interpersonal influence, multiple social groups, various places individual characters can be met, and characters having dispositions toward the avatar, social groups, and other characters.
With core functionality in place, as well as the tools to add to Scone in place, we will be ready to recruit contributors en mass.
The website we’ve been using for development may or may not be the same URL we use for our “public facing” website. This will be aimed at people who know very little about us beyond a blog or forum post or a video linking to us. It needs to earn their interest in learning more, not info-overload them.
It also needs to provide a homestead for a community of Scone fans to grow up around us and give feedback on what they need the game to become.
And it will also be a “publicity reward” for the team that has worked to this point in obscurity as something to point people they know toward as something they helped make.
If Mark “Notch” Persson is any example, it may be that if we’re really in tune with a “tribe” of gamers, they will spread the message themselves.
We may also find that the personal ambassador/recruiter approach to recruiting proves successful at finding high-quality contributors fuelled by the vision. To again use Minecraft as an example, when Notch reached the point of needing other contributors, he was able to pick and choose from the community already gathered around his game.
The second demo will be to include means to build community and encourage contribution into the game itself. This is taking a cue from FOSS project 0 A.D. which has in its demo releases features to send feedback to the developers both manually and with automated statistics, as well as browser links to their website and its community. Also, the pause menu of Lips of Suna includes meta info about how to help develop their game. These are ideas entirely worth stealing.
Other specific additions to the second demo will have to be judged based on where we are at that time starting from a prioritized list of essential gameplay features.
The more developed the game becomes, it harder it is to introduce significant changes. For example, changing the technical requirements for models forces a reworking of all models made up to that point.
Internally we will need to be settling on methods of development, such as building the AI code up in terms of adding one behavior at a time with its attendant reactions by characters or some other approach. This is best accomplished with input and advice by experts, and they won’t be interested in our project until we’ve shown a solid start and ability to make progress.
Assets made up to Demo 2 should not be too extensive, still pre-alpha or alpha. This particular game idea has legs in appealing to academics interested in sociology and treatment of social behavioral disorders. That gives us an opportunity to gain input from some very clever people in modeling behavior as well as some systems design. That would be perhaps the best way to figure out how things need to be done and to what specifications early on.
With a solid couple of demos, a good pitch, and some persistence, we could transform our project into “one to watch”. That would put us in position to recruit and retain high-quality contributors. With those contributors, we should be able to adapt ideas from experts as needed.
We will need to release “developer updates” as blog posts and videos with commentary. We should also continue posting to forums like FreeGameDev requesting whatever category of contributors we need.
Many releases will be for our internal/hardcore audience only, with public releases once new features become stable and acceptably polished. The timetable is best if it is challenging and we then celebrate those who rose to the challenge to deliver. The atmosphere within the team and the community needs to be rewarding, candid, enthusiastic, and always focused on an optimal balance between quality and quickness.
“Complete” is a misnomer, but the goal is to make it feature-complete rather than to complete every last aspect of it before moving to develop other aspects of a social world, including trade and economics, violence as a social strategy, sneaky acquisition of knowledge or goods-- there are many options for “what next” and that will have to be judged when we reach that bridge.
Whichever gamelet we pursue, many of the processes involved before will be useful and also easier with an established track record. Approaching academics should be a good source of ideas to get us started in the right direction right away.