Snake Webcams

Happy newyears! And now, snake cames!

(Being a mobile computing and hardware entusiast in addition to being a computer game theory geek means I will sometimes make blog posts such as these)

:

I've been on the lookout for a good webcam with a bendy mount for recording lectures and perhaps webcasts and notes, in an effort to improve my oral presentation skills. Requirements were integrated microphone, atleast 30fps 640x480 video, and a bendy usb mount.

My research turned up these models:

http://www.huehd.com/index-2.html
http://www0.shopping.com/xPO-Macally-IceCam
http://www0.shopping.com/xPO-Offspring-Technologies-CAM30
http://www0.shopping.com/xPO-MSI-StarCam-Mini
http://www0.shopping.com/xPO-Philips-PHILIPS-SPC610NC-USB-WEBCAM-FOR-PC-AND-LAPTOP
http://www0.shopping.com/xPO-Flex-CP-MPC-01
http://www0.shopping.com/xPO-Notebook-USB-Web-Cam
http://www0.shopping.com/xPO-A4tech-A4Tech-PK-7ma-Flexi-Webcam-Microphone-for-WebCam-Built-in-Microphone
http://www0.shopping.com/xPO-MSI-Starcam-370i
http://www0.shopping.com/xPO-Mustek-Mustek-Web-Cam-M6323
http://www0.shopping.com/xPO-Typhoon-Toto-TEL5GGC-60-EcoPower-Electronic-Faucet-Gooseneck-Thermal-Mixing-Chrome
http://www0.shopping.com/xPO-ClearOne-Communications-FlexCam-iCam-Digital
http://www0.shopping.com/xPO-AOC-PCCDC1120
http://www0.shopping.com/xPO-Solidtek-NoteCam-B100
http://www0.shopping.com/xPO-IC-Gear-Mini
http://www0.shopping.com/xPO-Compucessory-CCS42122
http://www0.shopping.com/xPO-BYTECC-350K
http://www0.shopping.com/xPO-Micro-Innovations-CPQ54CAM
http://www0.shopping.com/xPO-Logitech-430ML
http://www0.shopping.com/xPO-Logitech-Quick-Cam-530-Plus
http://www0.shopping.com/xPO-Micro-Innovations-IC70C
http://www0.shopping.com/xPO-SIIG-CE-UMCP12
http://www0.shopping.com/xPO-Sakar-Mini-WebCam-69352
http://www0.shopping.com/xPO-Iogear-GCA210U
http://www0.shopping.com/xPO-Canon-VIZCAM-1000
http://www0.shopping.com/xPO-Ezonics-CobraCam
http://www0.shopping.com/xPO-Sony-CCD-PC1

Now most of these are probably quite crappy, and don't even meet my demands, so proceed at your own risk, and sorry for not sorting it more thoroughly...but the above list should be current as of january 2009 with regards to everything available on the market, used or new. So it's a place to start looking for a solution that meets your needs.

Your best bet for getting a really good solution may be this though:

http://www.umpcportal.com/2009/01/digitus-flexi-webcam-ordered

It wasn't available and I've already purchased an excellent alternative from the list above, the Clique Hue HD:

http://www.amazon.com/Clique-HD-PC-Mac-Webcam/dp/B000TTIP8Q

But not at that abhorent price tag though, I purchased mine straight from Hong Kong on ebay for 17$ and 10$ shipping, brand new too. Only problem was getting the drivers from a reliable source.

Clique appears to have gone belly up, at least with regards to driver downloads! Which, if you do ebay it, kindof sucks because even if it does come with a driver cd, are you going to trust your computer to a cd that a random stranger sold on ebay?

Best drivers I have found for it are available here:
http://www.kentd.com/index.php?option=com_content&task=view&id=205&Itemid=1

Or they were at the time of writing. If the link is down, email me, and I'll try to upload them!

Exact size for the zip should be:
11.517.399 bytes.
At the time of writing Web Of Trust trusted the KetnD site. Not sure if that's worth much, but hey.

And neither avast nor any of the 4 firewalls I'm behind have complained about trojans or vira, so it appears completely legit. I don't recall if the drivers were digitally signed though, and they do install a server process for configuration, so use at your own risk.

I hope this proves useful to someone at some point =]

Progress

This is a small status update on the various things I want to write about.

Firstly, there's the concurrent savegame system pattern.

That's currently on hold; it's an interesting subject, and I want to dive into it further, but for the moment I'm not well-versed enough in concurrency that I want to model it. I want to eventually utilize a concurrency modelling language to implement a real world model of it - I want to use either coloured petri nets or spin:

http://en.wikipedia.org/wiki/SPIN_model_checker

I've drawn up a preliminary diagram, but I need to work in the rigerous models in order to fully understand the problem and how to best tackle it.

Secondly, there's the non-linear story development tool. I'm inclined to call it Texton. I've been discussing with my good friend Aksel whether I should implement it in C# - Which I've never used before - or if I should implement it in Java. C# seems far more suited to the kind of enterprise level software it's turning into - and it comes with windows presentation foundation and if I do program it in that, I'll actually have C# experience.

Java, on the other hand, would mean I would have to use java swing for the interface, which is a lot less delicious than windows presentation foundation. It would be multi-platform, but that's not really a concern at this point. The biggest problem with not using java is, probably, that java is home to staggering amounts of open source software and frameworks.

Either way, that is a bit of a concern.

Thirdly, I've yet to device an appropriate storage model scheme for the tool. I'm inclined to use xml-based object serialization through an SQL database for all storage, since it effectively decouples all storage and concurrency concerns, and allows for remote sync of data. The problem is, I have to write an SQL database adapter at some point. On the plus side, I can start out simply relying on local xml object serialization.

On the other hand, I've been very enticed by the prospect of using a remote object-data-base, since it allows for transparent development and very clean code.
Problem is, such a database utilizes a model-view-controller system of it's own, where the view into it is often locked to a specific language very tightly; a java object db communicates through a java interface in the client application, for example, so you'd have to find some sort of interoperable object db in order to not get your data locked into a specific piece of software; but an interoperable DB, unless it's interoperable because there's a host of different client frameworks in different languages, would lose the elegance.

In the end, I think I'll go with a highly modular approach, where data can be saved and stored through the utility of the adapter pattern. That is, I write my own client in either C# or Java that relies on an adapter interface for loading and unloading data. How that adapter handles data persistence will then be variable, but the main application can effectively treat the adapter as the model it's working on.

If necessary, an adapter should be able to easily be fitted to a remote object data base for live sync, and one can be written for both sql databases and xml serialization. Given the modular approach, two adapters can also be chained up and translate between two different formats relatively easily. Finally, adapters can be written that are able to translate serialized or sql'ed objects into new ones with appended fields and properties, allowing for patching the data-structure without corrupting the data. Hopefully.

Fourth project is my computer game theory course exam. I need to work on it relatively vigorously, so I'll have to put the other projects on hold for now. Hopefully, the next time I post on that, it'll be concerned more or less directly with this exam.

Blog consistency

I sometimes feel the need to argue why I'm doing things a certain way. Honestly, it's not for posterity, or to make anything clear to anybody else; it's mainly for me.

When I write things down, the syntax and semantics of what I write help me express something I feel. On occassion, those feelings are misguided. That's a pretty way of saying that I'm sometimes wrong, in spite of presenting a thorough argument.

I know this, because it's happened in the past, and I'm not going about things terribly different these days, so it'll happen again.

I'm not always going to go back and say what part of an argument was right or wrong; in the end, I write this for myself, and if I feel making a wrong argument ended up making me smarter, and expressing how that happened doesn't appeal to me, chance is I won't do it.

Sometimes, that will mean my blog becomes inconsistent between blog entries, and on occassion, even within individual entries. This is a choice. I'd rather make entries distanced by clean breaks, even if that means the entries don't fit together, if that in turn means the entries themselves grow to be of better consistency internally. And I'd rather spend my time writing about new ideas I think might be right, than old ideas of my own I think might be wrong.

But, _for_ posterity, I will be making sure that the results I derive will be easy to seek out, handle, and utilize. So the good stuff, I will be certain to reexamine later. The blog is a part of the process towards arriving at those things, so those are what matter.

With that in mind, I hope to soon make a blog entry tying together the game concurrency pattern and the save game pattern.

Designing savegame systems

Since we've previously established that the design of the save game system impacts gameplay, even if it requirres specific behaviours by the player to do so, I think it's in order to discuss different behaviors in relation to different save game systems. Before we get that far though, we need to establish just how difficult the subject is to work with, how it can possibly fit within my pattern model, and generally how we should procede from there.

I hope to narrow the subject towards a somewhat monolithic conclusion, but I fear it will be far more divergent than any of the other patterns I've discussed. I don't think it'll turn into a nice uniform set of rules, but rather several sets of conditional rules, that can be followed depending upon what exactly you're trying to achieve. The key to the difficulty, in my view, is the heterogeniety of the player behaviour. Perhaps I should embark on explaining why exactly save game systems are different from other gameplay mechanics, and perhaps more importantly, on how this difference is reflected in the way players tend to percieve save game systems.

Save game systems are technically different from everything else because they can be invoked at any one time during the game, and because they completely change the state of the game. None of the other metafeatures have this effect. Changing your options and configurations do not, as a general rule, effect the play experience; but there are a few exceptions to this rule, if for example you play a timed game against a chess computer you can underclock the cpu that's driving it to make the experience easier. Or, if you get a faster mouse and monitor for an FPS game, or a game with quick time events, it should improve your reaction time by as much as a 10th of a second. And of course any difficulty settings.
And then, there's the save/load feature, the focus of this blog, which alters the games state completely, at any time. Unless there isn't one, in which it simply impacts the players life, if he needs to leave the game, instead. Either way, once invoked, either by shutting the game down because there isn't one, or by saving it because there is, once the player returns, the game will be altered. Either because it allows the player to start from that point regardless of what happens over and over, or because it forces him to start from the beginning again.

Obiously, it's very difficult to anticipate the invocation of the feature, since it's invocation may not relate directly to anything that is within the game as a product. In fact, it's very normal not to respond to the invocation at all, for that very reason, nomatter where or how it occours.
This relies on a, by now completely ingrained, very specific suspension of disbelief amongst players.
Anecdotally, when disguised as anything but a save-game system, this feature would be looked upon as being completely different; a common system could be percieved as an undo-button which you can press if you anticipated that you might need to press it ahead of time. Omnipressence of this feature, this ever-pressent choice, within the game is at the heart of why it is very difficult to work with. But the bulk of the trouble in dealing with it in any innovative way is the vague notion that the feature is to be treated as special and somehow "outside" the game, which has by now festered and taken root in the public consciousness amongst players, even though it can clearly alter the experience very considerably.

Choosing wether or not to cooperate with the notion is not a difficult choice to make on the surface, as the advantages are many and ample. Many players will appreciate incorporating a traditional save game feature because it makes matching their lives with their gaming. This will largely be casual gamers, and if anybody uses it to improve their abilities within the game, it doesn't really relate to them because those who have the largest benefit from a save-at-any-time system are likely so casual that they wouldn't bother. The most hardcore gamers, of course, will likely choose to limit themselves from abusing the system because they want to play the way it was meant to be played, and somehow they feel that not using the save-game system to their advantage is more "real".

But the downside is that, somewhere in between, there will be a demographic that will likely use it to alter their game state in various ways, and it's incorporation will alter their play experience significantly. For this reason, what to do is not obvious, and because the demographic is difficult to pinpoint with any accuracy, it's difficult to say wether or not it is safe to ignore it. If it composes 75% of players, their reasoning behind using the feature to min-max their chance of doing well should be of no concern. They're your target audience, and you should try to maximize the fun they have; that's why they pay you. Not to fuel your artistic expression, but because they want to have fun. Unless you want to deny them that, you must try to cater to them.

But then...is it really worth maximizing their fun by doing something that will probably also inconvinience 30% of your players greatly? The choice is bipolar. But to me, the conclusion of this discussion is clear: If you want to design good, solid games, you'll put care into make the right decision about what save game system you choose for your game, and you'll take both the fun of your audience, the current perception of the save game feature, and the non-linearity of your game into account.

Now that I feel I've argued how to best approach the problem, I want to go over some different save game systems; I'll probably only blog about one today.

The first system is the no-save.

This is often used with arcade shmup games; it's impossible to save the state of the game, often because games in arcades are simple, easy to play, and revolve around learning level patterns in order to optimize and anticipate events that always occour in the same manner. Also, player death is directly what earns the arcades money, so if the player could skip over difficult sections after completing them once, it would be a less efficient manner of getting the players cash.
Another advantage is that playing the same levels over and over again is how you get good at many shmup games - there is no arbitrary skillset, only how good you are at the specific levels. This no-save system, then, lines up perfectly with what the game is trying to do - make the player feel as if he's constantly improving, getting better. But it comes with many drawbacks too, one of them being that when not alligning

It seems that games with more than 20 hours worth of playtime would be impossible to complete for any single player, as that appears to be the point where most get sick without rest. There have been reports of heart attack and similar ails setting in after 36-50 hours of playtime, for instance.

So there is a theoretical limit to the no-save system, as well as a, presumably, much lower practical limit. An estimate for the practical limit could be as low as perhaps 2-3 hours.

This is where the players behavior comes into play however. Some players will only be able to accept a sessionlength of 10 minutes or less for a no-save system game, whereas some players will be willing to accept much longer sessions without the ability to save their games.

This is perhaps one of the largest problems I've encountered so far in my work on game design patterns. Which demographic groups are able to accept which playsession lengths, and which invonviniences? And if so, does a particular type of content, which attracts a particular demographic group, need to be paired up with a particular kind of save game system in order to optimize the design? And how exactly should your demographic distribution be before you should cater to the convinience of one part, or the fun of another?

Naturally, my greatest interest is within one particular type of game - those with adaptive narratives and non-linear storylines. Sadly, those do not even fall within any one of the commonly accepted genres - and they make up only a small minority of those genres they do fall within. So there's no real chance of finding empirical evidence one way or another.

Instead, I have to approach the problem using only anecdotal evidence collected from various demographic groups. And in order to really capture the possibilities, I'll of course have to go in depth with examples from different genres and what kind of concequences game systems can have.

Oy vey. This pattern will take a while.

The "save" pattern

Many games implement some manner of saving and loading progress and game state. I've been thinking over, for a while, just how these various features affect the game play experience.

Some examples of the pattern are in order:

- A friend of mine played max payne with me many years ago. In my games, max, the titular character, was often limping around on low health, dodging bullets and dodging death with them. In my friends game, he was always stacked with 5 bottles, the maximum number, of painkillers, the games healthpack, and he was always at full health.

The difference was, he always loaded if he got hurt and he had the clear sense that he'd be able to do better. He would replay some encounters 3-4 times on occasion, till he got it "right". I only ever loaded if I died.

The game had an adaptive AI - it would leave a lot of painkillers around for the player if he was hurt, leave few if he had a good stash and he was healthy.

It should be painfully obvious that our different utility of the save game system made for different gameplay. I was consistently running the risk of bumping into an encounter that was too difficult for my hit point level, forcing me to reload over and over at the same place 10 or 20 times. He was constantly reloading nomatter what, but rarely many times at the same place; it would be wrong to say that he wasn't challenged, because clearly, it was more difficult to do every situation perfect rather than only those where max was low on health. But he always knew he had leeway, if it came down to it, whereas I always knew I didn't. Quite possibly, I might even have had easier encounters, and I deffinately had more healthpacks to pick up, than he had, so in some manners I was challenged less.

The point is not that there is a wrong and a right way to play a game. The point is that if you give a utility, such as saving games and reloading games on demand at any time, to the player, you may greatly impact his play experience by doing so. Certainly, you could argue that the how responsibly the player uses it is his choosing, not yours; but if you know that whatever you choose to make for a save game system will effect 99% of the players playing your game, and that 30% of those people will use the save game system to play the game in a min-maxing fashion, your choice concerning the system could make a difference between the game being called good or bad by many players, so responsibility doesn't even come into it.

The save game system is therefore part of the game as a product. So, the application of the save pattern, then, is concerned with a very product-oriented manner of percieving the game. It relies far more on outside context than many other patterns I have described thus far.

As such, boiling it down to rules will take a lot of work, and will likely relate a lot more to the consumer-producer analysis of the game as a product, and the context the consumer provides, rather than the contextual constructs which we, as game developers, provide within the internals of the game.

I'll be fun to write more about this in the future =]

Converting the decision pattern into rules

The summary of the previous two articles I wrote on the decision pattern goes as follows:

If you hide the concequences of the players actions from immediate view, the player won't be tempted to choose both actions via savepoints and savegames. But, if he chooses to reload based upon alusions made post-decision, and these alusions differ, he will be able to verify that his choice likely matters - just not right now.

If you do not allude, show the concequences immediately, and the concequences are shallow, allowing the player to try both will break the game - the player will no longer feel he has any influence, and he cannot consider his choices, former and future, actual gameplay, but will rather consider them out of his hands, and he will cease trying to influence it.

So: When implementing decisions, in a game that allows reloading, these rules apply:

- Always allude to concequences both before and after the player makes a decision.
- The closer to the action you show the concequences, the larger and more impactful the concequences must be.

The second bit also makes sense conversely; if we presume that a decision is supposed to have a big impact on a story, and the full effects of it are something the player might be unhappy with, he should not be "punished" with having to do-over very much.
The psychology here would say that the player should be conditioned to choosing his actions with great care, and that punishment would be effective; but if he regrets a decision enough to discard his current thread and wants to do it over, he is _already_ as into the story as you could want. He cares about the story and the characters. You're not only punishing him for making the wrong decision, but also for caring. The whole reloading thing should be avoided when possible, as a concequence. As such, the player should generally not experience concequences to his actions that there's a high probability he would regret. And if you must take tis route, make a do-over easy.

A couple of examples are in order: in Ultima X you encounter a deathly ill orphaned girl, and you're offered the choice of wether or not to euthanize her. No matter what you choose, the games villain taunts you - either over the fact that you now have the blood of an 8 years old girl on your hands, or that you left one to a slow, grueling and cruel death over the next couple of hours.

Nomatter what the player chooses, the adverse reaction, the long taunting session, and the guilt will likely make him try the other option if he cares about the story and his influence. When he finds out that negative concequences are unavoidable, and that he has only been presented with wrong choices, at the very least he will be glad that he can do over easily. But even then, he is still getting punished for caring about the game world by having to use a lousy interface to explore the concequences; all because some developer somewhere thought it would be a good idea to punish the player with concequences he will be likely to reject nomatter what decision he makes.

In the end, I played through the above sequence 4 times - one euthanizing her, one saving her, and one euthanizing her, then after spending 15 minutes on gamefaqs before I concluded that my first decision was what I really wanted to do, I euthanized her _again_.

- The player must generally not experience concequences he will regret.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them

Or, all in one place, the decision pattern in summary:

When implementing a decision, follow these guidelines:

- Always allude to concequences both before and after the player makes a decision. Make the post-decision allusions differ depending on choice made. Exceptions can be made if, and only if, you can be certain that the player won't reject the concequences in favor of a do-over.
- The closer to the action you show the concequences of it, the larger and more impactful the concequences must be. Long stretches are therefore cheaper to make and implement with the same impact. You can even allude to something that never happens if it's the exception rather than the rule.
- For big concequences, the player must not recieve punishment for attempting to figure out all possible outcomes. You would punish him for caring.
- The player must generally not experience concequences he will regret to such a degree that he would be willing to go through anything more than a quick and painless do-over to rectify it.
- Do-overs should happen out of caring for the world, not out of frustration with the concequences.
- Concequences that the player cannot escape must not be attributed to his choices if he is likely to reject them, and he is able to figure out that there is no way around them. There must always be a "right" choice, so to speak.

Storyline concept

I need to dump this concept somewhere:

As a method for international star travel, in an age where human science has conquered star faring propulsion technologies but not the human lifespan, nor the ability to store a computerized mind more powerfull than a cat in anything smaller than the volume of an elephant, humans develop a mechanized shell with the ability to grow a humanoid host.

Designed as a cyborg, the shell is 2 stories tall, with a life support chamber within that can grow and support a human being. If the human is ever killed, dies of old age, or leaves the shell, or is terminated, a new one can be grown to serve as host based on a storage bank of zygote clones with identical DNA to the former host. The shell nurtures and raises the human within the chamber, utilizing hormonal growth regulations, optimized sleep cycle regulation, and databanks containing interactive virtual reality recordings that allows the human to be raised, and eventually come to understand it's position, based on the lifes of the previous hosts.

Any space travel accross long distances means the death, rebirth, and re-raising of the host upon closing to the destination, effectively leaving the shell as a whole immortal, but always alone, and suffering from varying degrees of amnesia depending upon it's development.

I'm not quite sure what this concept means, but I thought it was cool when I came up with it....