Our first officially launched game "A Heroic Sacrifice" is now available and ready to play. This was created by one person in under 48 hours as part of a competition, but it is a complete game with 4 different endings. We will be doing a post mortem on it in the next few days to find things that went well and things that... well completely failed!
For those who have been curious, we are still very much alive and we have some good news and some bad news. The good news is that we have been doing some prototyping (or making small little things to see if we know how to make them correctly, so development on the werewolf assistant is still going. The bad news is that we just recently discovered the Ludum Dare competiion. What is this weird sounding thing you may ask? If it helps, the phrase (supposedly) means "to give a game" in Latin. Still confused? Well, read on.
Ludum Dare is a "make a game in a short time period" challenge. You are given a theme (if you want to help pick the theme, head to the theme slaughter and vote) and then given 48 hours in which to make the best game you can... by yourself. That's right, you must work completely solo. This covers pretty much all aspects of the game: programming, graphics, sound, etc. After the 48 hours are up, everyone submits their game (or game-like thing if you have ever seen the submitted entries) and those who submitted something all spend a few weeks playing on voting on each others game. I don't think there is really any prize (other then mad respect) to the winner, but it sounds like a great way to spend a weekend. And the weekend is coming up on December 14th!
One of the other catches is that any code (the stuff that makes up the working part of the game) that is in the game must be available for everyone to look at, as it is meant to be educational as well. It also helps prevent 'cheating' if you use some really expensive platform to make an awesome game with that I cannot afford. Anything that will be used must be announced ahead of time in order to give everyone a fair chance to use it as well. I like working with my own framework (library of code) but in order to use it I have to make it public. This is the first time I have opened any of my code up to the public and even though there is not much there (as I started assembling it two days before I wrote this) it will come together rapidly as it is a culmination of all of the little things I have been playing with for years. If you are curious to look at it, you can find it on github. I decided to name it Occam after Occam's Razor (the idea that things should only be as simple as possible unless they need the extra complexity) as my goal is to keep it light weight and avoid over-designing it.
So what does this mean for the Studio and its projects? For right now they are all on hold so that I can put as much of my time as I can into getting this framework ready. Then there will be our first 'release' as whatever comes out of that weekend will be available for all. I am hoping whatever gets started that weekend will be interesting enough to continue working on and eventually finished (as most games are no where near done), so we may have a completely new game idea in the pipeline in two weeks!
So for the next step in our development process we are going to create wireframes. Wireframes are rough sketches of what the different parts of our program will look like. They do not have to be pretty (just look at ours) or even very detailed. Their main purpose is to start fleshing out the ideas of how things will work and the steps the user goes through. Be warned, things can (and will) change from the wireframes, they are not meant to be cast in stone. We found some really good sheets that can be printed out and used for wireframing at http://lab.3fl.jp/tag/idea-sheet/.
- Very simple looking loading screen. This gives us some time to load up our basic framework and titlescreen (#2).
- Our title screen. This will likely have some artwork in the background and possibly in the future some type of 'help' or 'credits' buttons. This screen also lets us preload the rest of the application. We do this so that we can have a very quick initial load to get to this screen, then we load the other screen in the background so they come up right away.
- This is where we add the list of players to the game. We need to be able to add new players, remove existing ones, and change the order of them. The order is important and the players should be listed in the order they are seated as the phone (or tablet) is meant to be passed around. There will be some help text somewhere on this page. We also need our button to start the actual game.
- Pass the phone screen. The purpose of this screen is to make sure the phone is in the right players hands before revealing any information. The players should pass the phone to the person named, and that person should then press OK.
- Initial villager screen. This screen tells the player that they are a villager and will explain to them what their goals in the game are and give them the option of clicking for more help.
- Villager at night screen. Villagers have nothing to do during the night, but we still need to put something here to make it look like they are doing something in order to prevent other players from learning which side they are on based on how long they take on their turn. Possibly set some type of timer so they cannot hit OK right away.
- Pass the phone screen (#4)
- Initial werewolf screen. This screen tells a player that they are a werewolf and who their fellow teammates are (if any).
- Werewolf victim select screen. Allows a werewolf player to select who they would like to eat at night. Given that in the live action game the werewolf players can silently come to a consensus on who they want to eat, we need to do something slightly different here. If there is only one werewolf, then its simple: they simply select from the list of non-werewolf players. If more then one, my idea is to have the first werewolf in turn order nominate two non-werewolves to be eaten. Each remaining werewolf picks one of those nominated. In case of a tie, the first victim chosen by the first werewolf will be selected.
- Pass phone screen (#4)
- Seer initial night screen. This tells a player they are a seer and explains that they need to try and find who the werewolves are and tip off the villagers who they are.
- Night over screen. After all of the players have had their turn, this screen tells the players who was eaten. I think it would be nice to have a sound effect here depending on which role was killed (werewolf, seer, villager).
- Discussion screen. This screen tells the group that they should now talk about how they want to lynch. I can see a few options for how this would work. One possibility is to put a time limit on the discussion, then start with the initial person lynching screen. I think a better option would be to allow starting player to continue past this screen to their lynching screen. They can at any time lock in their vote for who to lynch but once they have they must pass the phone to the next player.
- Pass phone screen (#4)
- Lynching screen. This is simply a list of players left in the game and the player selects who they wish to lynch.
- Lynch confirmation screen. Makes sure player selected the correct player to lynch.
- Pass phone screen (#4)
- Lynch outcome screen (not shown). This screen shows which players was lynched, and what role they had. After this screen, the game goes back to the night time process (starting at #4).
As you can see these are very rough (and even missing one) but do really start to help give a sense of what this application will do and how it will work.