Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Aug 2003
Offline Last Active May 14 2014 05:26 AM

Topics I've Started

Why cards in a game design?

21 May 2013 - 07:38 AM

Hello all, 
Have you made a game design involving cards, tabletop or otherwise? Why did you put cards in there? What were the other options? Could the same mechanic have been displayed differently, especially in a video game? What core mechanic do cards provide in tabletop card games and what is the equivalent in a computer game? I'd like your thoughts on this since a lot of card mechanics (in video games) feel gimmicky to me especially when they display the actual card. I want the mechanic but do not want to be bound by the aestethic, so what's the mechanic?
One thing they do in tabletop games is providing a tangible marker of some kind. This is where the gimmic feeling comes from when translated into a computer. Sure, every inventory item in an rpg could represented by a card, every module in a spaceship, every regiment in an army. But on a computer that's just an aesthetic choice, not a mechanic. 
So what can we learn from cards? Here are some of my thoughts on what mechanics cards provide and how it relates to computers without actually showing cards on the screen. Faithful translations of tabletop card games (i.e. Poker online) doesn't count, nor does switching from cards to Scrolls.
1) Collectibility
Disclaimer: I've never played neither CCG's, TCG's nor miniature games so I don't actually know what I'm talking about.
Clearly CCG's proves that you can collect them. This they have in common with miniatures. World of Tanks is an example of this, but it feels more like miniatures than cards in that you get exactly what you buy rather than a random set of cards.
An example of this collecting mechanic would be a game where you recruit troops. Using standard clichés, you can send your recruiter to a dwarf village, a human village or elf village to get a certain kind of recruits, but the exact composition is random. 
2) Fog of War
In RL, cards are useful to keep information concealed from you yet available to me. Or concealed from all of us in the deck. In computer games it's very easy to conceal information from players (I'm ignoring hacking and hot-seat issues for now) so we do that in all kinds of ways. Actual fog of war, hiding unit statistics, line-of-sight, etc...
3) The Wonderful World of Discrete Mathematics and Probability
When you play a card in a card game, they can be thought of as actions. This means that you as a player can make decision trees: IF you do that, THEN I counter with, OR etc...
One way we do this in games is with various rock-paper-scissors mechanics: IF you get cavalry, THEN I get pikes.
4) The Deck
When you have a deck of cards it can be used as a resource with some randomness thrown in. In video games we do resource management in all sorts of ways, like health/mana, budgets, etc.
Remember my recruit troops example above? If that was an in-game action rather than something you bought or got "between" games, it could be an analogy to drawing a card from the deck: "You got a company of archers!"
5) Limits
As a thinking tool they might provide limits, in a positive sense. If you tend to have feature-itis in your designs (like me) then the limitation that *all* information about a unit, item or whatever should fit on a "reasonably sized" card could be a good one.
What other ways can you think of that cards are used in games, tabletop or otherwise? 

Which hack is the worst?

16 December 2008 - 08:06 AM

Hey guys! Imagine this game: You train a squad of AI agents in a game of Laser-Tag. Notice "train", not program. You put them in a bunch of scenarios and then you get a debriefing where you can say when and where they did good or what they should have done instead. When your team is ready for it, you can pit it against other players online. Now to the dilemma: When playing vs other players, you can: Send all your AI parameters to each other and then run the simulation on each computer. This will eliminate lag and it will be virtually impossible to hack. All the hacker can do is send his AI parameters, and honest player will see an honest fight on his own un-hacked machine. The backside is that a hacker can easily steal the honest guy's AI. OR you can run your simulation more like normal games are run where each computer tells the other what it's AI is doing. This means an honest player has to trust a potentially hacked machine. So my game design question is, which one of these hacks do you think detriments gameplay the most? That an honest player can be tricked thinking he's seeing an honest fight when he's not, or that his AI can be stolen? P.S. Any solution that would get the best of both worlds is of course welcome, though I think this is the wrong forum for overly technical stuff. :)

The Hacker in me

06 October 2008 - 01:21 AM

In a moment of both sudden and for me uncharacteristic artistic creativity I came up with this homage to the Hacker in me, to the melody of The Cowboy in me. Enjoy! :) The Hacker in Me I don't know why I code the way I do Like I ain't got a single byte to lose Sometimes I make my own balanced tree I guess that's just the hacker in me I know that here some brute force would suffice Still I do a premature optimize And I rather code assembler than code C I guess that's just the hacker in me The urge to code the very best That pass through ev'ry single test The things I've done for foolish pride The me that's never satisfied The trashing of the keyboard when there's a bug I cannot see I guess that's just the hacker in me Compiler there was times when you said halt There ain't a line you wrote that won't segfault But you set your mind to see this code on through I guess that's just the hacker in you We carefully inspect each function call I guess that's just the hacker in us all

Scripting as strategy game interface

05 October 2008 - 11:49 PM

A couple of times every year I replay the original XCOM game. But there is one thing I miss in this game and also in many other similar ones. Namely some kind of "keep-it-this-way" control. Like "I always want at least 20 spare rifle clips in this base". When I use up some ammunition during a mission, then new ammo should be bought automatically (or let me view the replacement order). Maybe this is the programmer in me, but I would love some kind of lightweight scripting for this kind of situations in strategy games. Would a "normal" person like this you think? Do you know any other rare or nonexistant interface feature that you feel would improve games, strategy or otherwise?

boost::shared_ptr trickery

22 January 2007 - 10:37 AM

I'm looking for solutions for a problem I have with boost::shared_ptr's. Let's see a pseudo-c++-example:

// Boo.h
typedef boost::shared_ptr<Boo> BooPtr;

// Somewhere.cpp
void doStuff()
    BooPtr ptr(new Boo());
    // stuff...

// Boo.cpp
    // attachBooToList requires a shared_ptr.
    attachBooToList( BooPtr(this) );  // Now we have two reference counts. Bad...
    // stuff...

This is the problem I encountered. Both doStuff and the Boo constructor need a SmartPtr. There are a few solutions to this, but I'm not really happy with them. Perhaps attachBooToList or doStuff could take a normal pointer. But since both of them keep the reference to Boo for quite a while, it kinda defeats the purpose of having shared_ptr's in the first place. You could attachBooToList just after the constructor (in doStuff), but I don't want the user of Boo to have to know who Boo attaches to. Perhaps doStuff could get a shared_ptr from the BooList that Boo attaches itself to, but then doStuff has to know who Boo attaches to, just like above. You could send a shared_ptr to an init() function, but it annoys me to send a pointer to an object pointing to itself. It's not very elegant. Still, it's the best I can come up with. Using intrusive_ptr with a custom reference counting could perhaps solve the problem, but I don't want to run around making different custom reference counters for different classes. I think this problem will appear at many places. Is there another, better, solution to this?