Gameplay and Storytelling: Part 3

I recently downloaded a game for the iPhone called Suviving High School, part 3. I was anticipating not liking it, because I am not a fan of current teen culture, and the game seemed likely to glorify it. The reason I felt interested in downloading it was because it seemed to be a game where story was important.

One of my long term goals with game development is to develop a style of gameplay where what you do in the game and what you do in the story are linked. Surviving High School showed me two things: 1) This is a viable gameplay mechanic, and 2) There is a demand for it.

Surviving High School is, in essence, a very rudimentary version of what it is that I hope to eventually accomplish. The game follows the story of you, going through high school, and along the ways you get to choose to do various things, build relationships with people, and in the end, based on how you did, things happen.

It also handles a couple of the things that I have been concerned about quite well, specifically, how to drive the player. Up front, the player is given three main goals: Win at football, Get a car, become popular. It is, of course, essentially impossible to pull all of these things off, and the player must make choices along the lines where they are going to concentrate. Are they going to make their character strong so that he can perform 'special moves' in football? Are they going to spend time studying so that they can do better at school, so that they do well enough that their dad buys them a car? Or are they going to watch TV and skip class to be come popular? (Philosophically, that's the part I hate most - that the player was rewarded for doing such things - but whatever, I won't go into a teen-lifestyle rant today :)

Where this game differs from my view on what I hope to eventually accomplish, down the road, with this style of gameplay is the characters interaction. What we have here is great - I actually enjoyed building up relationships with the various characters, and I really tried hard to have a good relationship with the girl who I was dating, and I really felt bad when other characters didn't get along well with my character. And I point out that this game does it very well, and it has excellent scripts and the characters are interesting and varied. But what I want to accomplish is a game where your interactions with other characters are richer. Surviving High School plays roughly like a "Choose your own adventure" game, where your relationship with characters is dependent on what you say in situations where you only get to choose one of two possible things to say.

I want to someday have a style of gameplay where you can go, strike up a conversation with another character, and say pretty much whatever. This of course leads to many concerns, of which syntax, performance, and possibilities are among them. I have been thinking more and more about the idea of symbolic language, as used in Siboot. (This would also solve the difficulty of porting to other languages; no having to learn how to parse multiple languages!)

Alright, so saying "Pretty much whatever" is unlikely, and it would lead to players saying dumb things to the characters. (You know that as soon as you start talking to one of those 'bots' online or wherever, you try to say the zaniest thing possible in the hopes of tripping it up). But creating a more rich, verbose interaction between characters, I believe, will really immerse the players. Because truthfully, in Surviving High School, there were many times when I didn't feel compelled to say or do either of the things that I was given the choice of doing, and felt as if I were picking the "lesser of two evils".

There is one other area that Surviving High School did well that I still would like to potentially improve upon in my own game down the road, and that is variety of actions. In SHS, the game calls on you to do many things, from sing to act to play football to etc..., and each of these things would of course require different minigames or actions to fully work. What they have instead for most cases is word based games; you spell or choose words that are related to the actions. This nicely solves the problem of having to create many different actions for the player to perform but at the same time devalues the experience of trying to accomplish some of the things your character does. While it would be difficult to create a game where the player has many options of actions on top of the various conversation requirements this game would require, I feel that finding some solution to this would be important.

At this point all of my ideas are experimental and I don't know how to solve all the problems I am encountering in my mental designs. Those that I am finding solutions for are often expensive or require vast amounts of technology and scripting times. It will require vast amounts of experimentation and iterations before this style of gameplay is fully realised. Perhaps I won't even be the one to realise it, but I hope to be involved to some degree.

Castle Conflict: Update is live!

The original plan for the Castle Conflict update was for it to take eight days to develop (similar to our original development cycle of 8 days). Of course, live intervened, and during that 8 day period, I had a concert, a contract to work on, family commitments, and many other interruptions. These conditions existed the first time as well, but we we had planned this time ... well ... it took longer.

Nonetheless, we had a game that had rough versions of all the features by the Monday after we had started, which was good because myself and the Lead Programmer from FPM Software (a new iPhone company in Calgary working on games, the first of which, Shift Maze, was submitted to the app store on Wednesday) were hosting a testing dinner that night, where friends and family got a chance to play our game. We, of course, bribed them with food.

The app was delayed a further two weeks. One week, I was away from the code base, working on and teaching iPhone Dev School with Michael Sikorsky, who also has a game that has been or will soon be submitted to the app store.

Josiah (the artist/audio developer) and I decided to take another week to finish the app, to make sure that it was a really polished experience. And so it was that, 4 and a half hours past our deadline, on the morning of December 8th, we finally clicked the 'submit' button so that Apple could view our game.

Castle Conflict went live around midnight last night. The new update does not have all the features we planned, yet both Josiah and myself keep playing the game. (I have gone through campaign mode probably 10 times by now, and am still not bored of it). We are planning future updates already, now that we have the architecture in for levels and new units to be added easily.

It has been a wild ride. But it has been fruitful!

Screenshots of the new update:












We also have a youtube video:



(and if you go to our channel, there are also 4 videos that show the game being developed).

And finally, the iTunes URL :)

iPhone tip: don't change ${EXECUTABLE_NAME}

This is a series of quick tips for people who are having a few problems, with ad-hoc iPhone builds and xCode in general.

1) When creating an ad-hoc iPhone app, be sure to have a 512*512 png file in your app called iTunesArtwork . Just iTunesArtwork, no png at the end.
2) Be sure to create an Entitlements file (Add->New File->Code Signing->Entitlements). Name it whatever, and place it in the root, not in any subfolders. Then, go into the information for your target, and set the Code Signing Entitlments field to the name of that file.

The next one is important, as I lost > 30 minutes on it: do not change ${EXECUTABLE_NAME}. This is in the information for your Target, under properties/Executable. I decided to change this, because I had one target for regular development and one for ad-hoc distribution, and I thought to myself, boy, it would be neat to be able to tell the output of these targets apart easily. So I changed that value to CC_AdHoc, and suddenly my code was exploding. The worst error I got was "CC.app: object file format invalid or unsuitable". It took me a while to realise that it was the ${EXECUTABLE_NAME} that was causing the problem, and once I did, was highly frustrated. So just leave that variable alone, it will save you a lot of problems.

Objective C in-code profiling

To check how long something is running in objective C:

1) Declare an NSDate and set it to [NSDate date]

2) Run the code you want to test

3) Get an NSInterval from the NSDate by sending the timeIntervalSinceNow message

So for example:

NSDate* date = [NSDate date];

//RUN some expensive code her

NSTimeInterval interval = [date timeIntervalSinceNow];

NSLog(@"Time running expensive code: %f", interval);