GameMaker community forum gripe

development, games, Uncategorized
Comments

Ok, I realize that GameMaker isn’t a hard core developer environment. It does serve a purpose though: to provide a more accessible means for aspiring game designers who are not primarily programmers to be able to give life to their ideas. This is a truly noble purpose, in my view and I will never say anything bad about GameMaker’s technical limitations as long as they’re limitations which must exist in order to achieve that goal.

That said, I am really starting to get frustrated with the GameMaker community. Not its members, mind you — the handful of interactions that I’ve had with GamMaker devs have been helpful and positive. But what is really driving me nuts in the community forums is the way people will post links to filehosting sites, and the link is dead because it’s a few months later. This is totally counterproductive to the goal of making a game dev environment that’s welcoming and forgiving to newbie programmers and non-techie types.

The forum thread is there, the tantalizing discussion about how awesome a solution is to just the exact problem I needed to solve is there, but the .gmk or .gex file that would make my day is gone. And not enough discussion around the gaping hole to figure out what the solution was that was demonstrated in the downloadable file.

But it’s not just an everyday occurrence. It’s damn near mandatory. And super frustrating.

.gmk files *usually* take up very little space, and if you don’t need all the resources embedded to create a full-fledged game, you can make *extremely* lean .gmk files that can provide a reference implementation of your nifty solution…. AND, we live in an age where 2TB hard drives cost under $100.

So, WTF? The GameMaker community would be so much better serving its users if it provided permanent hosting space so that discussion threads could remain relevant.

I really don’t understand it, I mean if you go to yoyogames they have graphic and sound resource packs that you can download. They’re of poor quality, and searching for anything in them is atrocious, but they at least have links that still point to extant resources. They even host all the games that people submit to the site.

Clearly they have the technology, why are they not using it in this way?

Fixed that bug

development, programming
Comments

Haha, I figured out what was causing that bug I ran into the other day.

While reading the GameMaker documentation, I read that the order in which objects are drawn is determined by their Depth, and inferred that it is not just the *drawing* order but the construction order when a new room is instantiated. (In GameMaker, Depth is a property that all Objects have, which helps determined which Object is drawn “on top” when their sprites overlap.)

I happened to have my Fish objects at a higher depth than the Player, because if the Player was overlapping the Fish, I wanted the Player to be “on top” so that the Player would always be visible. As an unintended consequence, the Fish objects got drawn and created first, and since Fish.size depends on the value of Player.size, and so were throwing exceptions when the Player did not yet exist.

For some reason this bug was always latent in my game project, but it only manifested after I added a Background to the Room, which is a bit odd. I am guessing that a Background has an extremely high depth so that it appears “behind” everything else in the room, but why it seems to trigger the creation order bug is mysterious to me.

What’s more, I am also confused as to why one of the things I tried to prevent the error did not work. In the Fish.Create() event, I added a check to make sure that the Player object exists before assigning a value to Fish.size that is based on Player.size. If !Player.exists, Fish.size is set to a safe value that is not based on Player.size. Yet, for some reason, the check was successfully able to determine that Player existed for purposes of Player.exists() check, but yet was not able to get the value of Player.size in order to calculate a randomized value for Fish.size. Apparently, the Player object exists at this point but its size attribute does not, or perhaps contains an undefined value.

Figuring this out was rather tricky and it never would have occurred to me had I not been thinking about this bug when I happened to be reading about how the Depth property determines drawing order. Hopefully this writeup will help some other GameMaker developer avoid making a similar mistake.

BunnyBots

Best Of, games
Comments

I was over at my parents house for Christmas. When I was a kid, my mom kept a bunch of my old school assignments and things up in the attic. I had hoped that I’d be able to go up there and find some of the old game ideas that I had drawn when I was in first and second grade, but unfortunately it seems within the last ten years she went and got rid of a lot of that stuff, and turned the rest of it into some scrapbooks. Unfortunately, it appears that most of my old ideas were lost, other than to my memory.

There was just one thing that I did find among all of that stuff, which might have been a video game concept. The strange thing is, this one I have no memory of making. The drawing is of BunnyBots, which looks a bit like Lemmings, only with bunny robots. That field war machines and artillery pieces, apparently. They fire carrot missiles at each other and drop easter egg bombs and have tunneling equipment for digging rabbit holes. Gameplay evidently resembled a 2-player PvP 2D horizontal scrolling RTS.

Mind you, this was probably drawn in 1982-3, long before Lemmings or real-time strategy existed.

I dunno when or if I’ll ever turn this concept into a game, but here’s a scan I made of the drawing:

BunnyBots

Original drawing for BunnyBots videogame concept. Click Image to enlarge.

?! >:/

programming
Comments

Something very weird going on in my GameMaker project…

I have two Object classes: Player and Enemy.

Player
{ Create() {size = 2}
}

Enemy
{ Create() {size = random_range(0.5, Player.size*3)}
}

This code was working fine up until today. Technically, I should be checking to see if Player exists before I try to use Player.size, but I set things up so that Player always exists and was created before any Enemy instances, so it never threw an exception. I understood the risks and tested it and it never had a problem.

Today I created a background image for the room where the game takes place, and added it to the room. All of a sudden now, the Enemy.Create() event is throwing an exception at Player.size because it is an unknown variable.

I scratch my head a bit and try to figure out why…

Was there actually a fortuitous timing condition prior to adding the background that caused the Player instance to be created before the Enemy instances when the room was being constructed? I try removing the background, but the game still throws the exception. I try creating a new room, adding the background to it, then the player, then the enemies, in that order, and it still throws the exception.

OK, let’s be more careful, and check to see if Player exists when in Enemy.Create(), then.

Enemy.Create()
{
If instance_count(Player)>0
{
size = random_range(0.5,(Player.size*3))
}
}

Game STILL throws an exception trying to access a non existent Player.size variable.

OK, did my game project somehow get corrupted? I roll back and test, things are working, then re-implement the background, and the bug is back again.

Does a room with a background image somehow conflict with Player.size? I run the built in variable name checker, no conflicts.

Hmm, what if there’s a name conflict anyway? I try renaming the size variable to foo. Still throws the exception. I try deleting the variable and adding a new variable that performs the same function. No better.

I run the game, Ignore all the thrown exceptions, and then once all the Enemy instances are created the game works. Clear level, next level is fine, no errors.

Alright, last thing: I pull size out of the Player object and make it global. Surely if Enemy isn’t capable of peering in to Player’s public variables (GameMaker doesn’t seem to have a distinction between public and private object properties, at any rate — everything is public for sake of simplicity for newbie programmers) but what the hey, let’s try it. Add the global.Player_size variable, attempt to access it in Enemy.Create(), still throws the exception.

To quote Moss from The IT Crowd, “What the ever-flipping flip?”

Player.size most certainly exists, why can Enemy no longer access it?

Update: To troubleshoot further, I created a new gamemaker project and made it as simple as possible. I created two sprites, two objects, a room, and a background. With the objects, I assigned a variable in the create() event, and tied the value of object0’s variable to the value of object1. Then added both to a room, then ran the game. No error. Then added the background to the room. Again, no error. So, it doesn’t look like this is a bug in GameMaker, then. Something must be messed up with my game project, and it’s up to me to sort through and figure out what it is, then.

Boobie Teeth

games
Comments

I’ve made enough progress with my first game project that I’m releasing a build to the public.

Boobie Teeth is a game I designed as a six-year-old in 1980-1981. The title derives from the term “Booby Trap”. The game is about a voracious fish with jaws like a steel bear trap. Swim around and eat all the fish that are smaller than you. The more fish you eat, the more you grow. The other fish will eat smaller fish too and will grow as they eat also.

This is a very early non-feature-complete alpha build that demonstrates the core play mechanics. Built with GameMaker Pro 8.

Download it on the Releases page.

About my process

programming
2 Comments

One thing that I think I am starting to realize about my programming process is how important it is to me to be able to complete a task in a single session.

Each evening when I sit down to work on my game project, I don’t usually have a specific idea about exactly what I want to work on or accomplish. I do have a lot of general ideas. I have a list of things, a backlog of features that I have brainstormed but have yet to implement, or have yet to implement to my complete satisfaction, and a rough idea of the priority I’d like to give on each item in that list. When I sit down to being my development session, I review the list and pick something. As I continue to develop, I continually update the list, usually removing things from it that I’ve completed (it makes me happy/inspired to see the list shrink), but sometimes adding new things if an idea comes to me or I realize a new problem has come up as a result of something I’ve been working on.

I am not strict about working on items in priority order. To some extent I am taking things in order of importance, but mostly I try to work on the most important thing that is also easy to accomplish quickly — the so-called low-hanging fruit type stuff that is easy to do and provides a high value to the project. To a larger extent, I work on things in the order that I can work on them — some things are dependent upon other things and I have to do those things first in order to be able to do the next thing. Or sometimes I need to learn more about something in order to do it, and doing something else first will give me the opportunity to start to get into that topic in a more lightweight and manageable fashion.

Sometimes I just work on something that I happen to be interested in at the moment — it is important to recognize the power that having an interest in something has. If you’re interested in something, engaging with it is easy and natural. If you’re not interested in something, it’s hard. If you’re actually interested in something else, it can be all but impossible.

Having a sense of progress and momentum is extremely important to maintaining my morale and motivation.

I like to work in long, mostly uninterrupted sessions. I’ll start around 6-7pm and stop around midnight-1am. I don’t just work on the project during this session, though — I read my usual websites, do email, make dinner, chat with friends over IM. I find that this does not interfere or impede my progress or ability to focus, and any of these “distractions” makes for a good punctuation mark that allows me to take a breather and come back to the project with renewed energy.

I don’t even spend most of my project time developing and coding. The coding part of the work just doesn’t take that much time. I spend more time building and playing, then going back and tweaking something, building, adding a tiny little bit, and replaying, again and again, until I get what I wanted, or, often, figure out what I wanted. A lot of times, an idea I had at first is not really as good as I thought once I have built it, but something else that is close to that is better. By carefully testing each little change iteratively as I build, I ensure that I move in a steady direction toward a successful design. This is much better than trying to design everything out on paper before I put any time into building it, by far.

When I first sit down to work for the evening, I have in mind a goal to improve some aspect of it, and by the time I am ready to put the project down again, leave the game in a state where it is both playable and improved from the last iteration. I sit down and look at my list, mull things over for a bit, do a little bit of planning and thinking, and then start building. As I build, I document what I’m doing.

The first thing I do with each session is to create a new version of my project. I don’t stop working until I’m satisfied that what I built works the way I wanted it to, and results in a better game than what I started with.

I’m not sure how sustainable this is, this approach of having tiny tasks and completing them in one session, but as much as possible, I want it to be. I find that I am far more productive in my project as I am working if I can complete* some aspect in one sitting, as it were. If I don’t make it, I run the risk of losing my thought process and not being able to pick up where I left off. I think of it like writing a book — you don’t want to just cut off in mid sentence. And ideally, you’d like to be able to complete a chapter, or at least a thought.

*When I say “complete”, I don’t mean “final”. I will likely go back again and make further refinements when the time is right. For example, when I started implementing my enemy objects, at first I just placed them into the game as immobile objects. I next focused on interactions with the player object. In a later session I added very basic movement, and spent a lot of time tweaking that. In upcoming sessions I plan to further refine enemy movement, adding different modes and coming up with some AI routines that determine how the enemy “decides” what mode to be in depending on what’s going on in the game.

My guess is that if you architect your program the right way, you should always, or nearly always be able to use this approach of tiny steps over many iterations. To extend the architecture metaphor a bit, if you’re laying bricks, to build a bigger building you just use more bricks — you don’t suddenly have to switch to bigger bricks that become unmanageable for one person to wrangle. That may not always hold true, but my feeling is that it should most of the time.

GameMaker 8 bug in TestVariable action?

games, programming
Comments

I ran into a bit of strangeness with my game project today. While testing a feature, I noticed something inconsistent in the way the program behaved. Upon investigation I discovered that the cause of the inconsistent behavior was that I used two different functions to do a comparison of a certain value in two different calculations, and these functions are not equivalent.

In GameMaker 8, there’s an Action called Test Expression, as well as an Action called Test Variable. It turns out that Test Variable isn’t so good when it comes to testing for equality, due to the way GameMaker handles typing of variables. For the most part, there are only two types of variables: strings and real (floating point) numbers. But in GameMaker 8 they also introduced a few new functions that return integer values. It turns out, if you use Test Variable to compare the value of a real number to the value of an integer to see if the two values are equal, Test Variable will never return true. However, if you use the Test Expression action to do the comparison, it will return true.

In most programming languages, it is impossible to directly compare an integer to a floating point number; you have to use type casting to convert one of the values and then do the comparison. Working with floating point math is tricky with computers, because of rounding errrors, where values are often +/-0.00…01 (whatever the precision is) off due to the way floating point math works. Yet, GameMaker does not display the full precision of the floating point number that is stored in a variable — it only shows the first two decimal places, and hides the rest. Thus, to GameMaker’s Test Variable action, the number 3, which might be returned by the irandom(n) function, is not equal to the real value 3.00.

Test Expression does get this right, though, and automatically accounts for the rounding error, and will consider int 3 to be equal to real 3.00(00…01).

Hopefully they’ll fix Test Variable in a future release. I have reported the issue to GameMaker’s bug tracking system.

Developing in GameMaker

development, games, programming
Comments

One of the first things I did with my gmk project is figure out how to do file I/O so I can write out to an event log so I can see what’s going on in the game. This is highly useful, since it allows me to track every action that happens, every value of every variable if I want to.

Once I figured out how to write a file I/O routine in gamemaker language, I put logging on a bunch of things in the game that I wanted to track so I could see it working and make sure that it was working the way I wanted it to. Mostly this was a check to verify that the way I understood the environment to work was correct.

After I’d written a logging routine on just about everything I’d built so far, I discovered that you can call scripts. So I got excited by the prospect of being able to write a reusable script that would save me from having to write out the same code again and again, like I’d just did. So I built my script, proved it worked, then went and ripped out all that redundant work that I’d just put in. I didn’t mind at all because it meant moving forward that I’ll have a lot easier time with building up code, and I’d discovered it way early in the project.

(I probably could have learned it even earlier had I read the manual cover to cover before starting, but I find it easier to engage with something if I play with it as I learn and read as I play with it whenever I get stuck.)

###

The next interesting thing I did was a feature I wanted to implement early. Trying to do the early stuff the right way is important, but you can’t second-guess yourself so much that you don’t make progress at all because you can’t decide what approach is truly best.

The feature in question has to do with the graphics. I wanted a way to graphically show the relative strength of the enemies to the player. Basically, we have a “strength” variable, and if you compare it to the player’s current strength, an enemy is either weaker, equal, or stronger than the player. I want to make this apparent to the player visually.

On my first development iteration, I simply implemented a separate object for weaker, equal, and stronger enemies, which all inherited from a base enemy class.

On my second development iteration, I figured out that I could have a single enemy class, and for the initial value of the strength variable, I can just assign a random number, and then based on this random number, compare it to the strength value of the player, and assign the appropriate graphic to the enemy. I got this to work pretty easily, and it eliminated the need for having separate objects to represent the weaker, equal, and stronger variant enemies. This might be a mistake, as it might make things more complicated to have a single object doing all three things. But I think it is the right way for now.

On my third development iteration, I needed to make the enemies update their graphics. The player’s strength increases during play, so as the player’s strength changes, the enemy’s relative strength might change from stronger to equal, and finally to weaker. I wanted to figure out a way to do this efficiently, and figured that having an event that fires whenever the player’s strength changes would be a good solution, and the “right way” to do it. I haven’t been able to figure out how to do this in GameMaker yet, however. It’s not an easy thing to do, and probably requires a bit more understanding of GML than I have at present. GameMaker handles instances of objects in a kindof kludgy way, and this quirk in the way the language works makes it harder for me to do what I want to do.

After trying to figure it out for about 4-5 hours, and not getting anywhere, I opted to go for something cruder but simpler, and found that it works just fine, at least for now. Rather than trying to fire an event that checks the relative strength of every existing enemy in the current room whenever the player’s strength changes, I simply created an event for the enemy class which checks its strength relative to the player each and every step of the game engine, and updates the enemy’s graphic. Obviously, this would not scale as well (I’m basically “polling” the objects 30 times/second, instead of simply calling a method as needed, which would be a much more efficient way of doing it.) So this approach may not work out so well if the game gets larger. But at the scale I’m currently working at, it performs just fine. I’ll have to revisit at some point if I have too many objects in play, but I’m not going to worry about that for now.

Game project

development, games, programming
Comments

So I’m working on my first serious attempt at a GameMaker project.

The thing with working personal projects is balancing how much you talk about your project with how much you work on your project. You can’t be all talk and no action, obviously, and you probably shouldn’t simply spring a new project on an unsuspecting world, either.

I’m not yet sure how to do this right. I don’t want to spend a bunch of time describing something that doesn’t exist yet, especially if I may change my mind about particulars a bunch of times before I decide to release it. On the other hand, not talking about it just drives me crazy. I’m into my project, and it’s interesting and exciting to me, and I just have to talk about it.

The other thing that’s hard about talking about working on personal projects is talking about it with a proper level of authority and confidence. I’m doing things that are new to me, for the first time in many cases. But most of what I’m doing is technically not all that difficult or sophisticated. As much as I want to be excited about figuring out something, I don’t want to make myself look dumb by blogging things that are the equivalent of what “Hey, guess what I just figured out? When you have a plus sign between two quantities, that means they’re added together!” would be to a math blog.

What I do like about this project so far:

  1. The fact that I’m doing something that I’ve wanted to do my whole life.
  2. The fact that I can do it.
  3. The fact that I am doing it.
  4. That the progress thus far has been fairly steady.
  5. My process: planning, building experimentally, testing, documenting. I feel like I’m going about this in just the right way.

In fact, I really like my process. Here’s what I do:

  1. Sit down and think about what I want to do. Brainstorming. Create a list, prioritize it. This becomes my backlog.
  2. Work an item on the list until it’s done to where I’m satisfied with it for now. This involves building and running it to test it, over and over. I try to conceive of my solution first, then build it, starting small and simple, and building off of what I just did. I’m more tentative with things I haven’t mastered yet, but that’s the natural way of things.
  3. Write up what I did in my version history. Update the backlog, to either remove the item from the list, or more likely, update it to reflect the next level of refinement that I want to get to with that item.

So far, so good. I have a ways to go yet before I have something that’s worthy of an alpha release. I might have it out in a few weeks, we’ll see. What I have right now is playable, but not interesting as I’ve yet to implement any enemy behavior. I expect that the enemy behavior will be very interesting to work on, and probably one of the trickier aspects of the game and thus may take me longer than what I’ve done so far.

New Card Game: War: Battle Lines

games
Comments

Today I attended a Cleveland Game Developers Meetup where we did a workshop on rapid prototyping and playtesting. It was very successful and fun.

We workshopped the card game War. Standard War normally is not a terribly interesting card game, with rules that are deterministic, and therefore involve no skill or strategy, but it turned out to be a good starting point for the workshop. We broke up into two groups, each led by one of the organizers, and brainstormed ways to improve the basic game, then ran the game through several rounds of playtesting, tweaking rules and refining. In little under an hour, what we came up with was actually fun enough to share with the world.

There were five of us in our group: facilitator Sam Marcus, me, Steve, Nadja, and Melissa. Sam set up the exercise and we worked together to come up with the rules. Sam and I seemed to come up with most of the ideas, but everyone contributed to running playtest iterations and helped to make the game.

Here’s what we came up with:

War: Battle Lines

For two players.

War: Battle Lines starts from the concept of the card game War and makes it more interesting by introducing elements of choice and strategy.

Initial setup:

Deal the entire deck between the two players.

Variant: Symmetric Start. Rather than dealing out the cards randomly, player one gets all the red suits while player two gets all the black suits.

Play:

To start a hand, each player deals themselves the first four cards from the top of the deck, called Skirmishers, and lays them out on the table in front of them in a horizontal line, like they were dealing Three Card Monte. Two of the cards must be face up, while other two must be face down. Each player may look at their own down cards prior to the round starting, or at any time throughout play, but may only see the other player’s down cards once they become involved in a skirmish.

A fifth card, called The Initiative, is played face up. The two Initiative cards are contested, and the player winning the Initiative round gets to make the first play.

The player who wins Initiative picks any one of their cards and may choose to “attack” any of the other player’s cards. The cards involved in the skirmish are compared face up, and the higher of the two cards is the winner of the skirmish. The winner of the skirmish adds both cards to their victory pile.

If the result of a skirmish is a tie, a “battle” breaks out. Both players immediately “call up reinforcements” from their deck of un-dealt cards, and these cards are compared to each other to determine who wins. The winner of the battle takes all the cards and adds them to their victory pile.

Players alternate turns until all four skirmishes have been resolved to complete the hand.

The game continues, with additional hands of four cards plus one initiative card dealt, and the process is repeated until the deck is exhausted.

Once the deck has been exhausted, the game is over. The winner is the player who has the larger victory pile.

In a 52-card deck, each player will have 26 cards to start out, and therefore would play through 5 rounds with their four skirmishers plus initiative card, leaving one lone card at the end of the game. In the event that a Skirmish turns into a Battle at some point during the War, there may be other endgames possible, with 1-4 cards left over at the end.

How we handle the last card at the end of the game is open for variation. In the “standard” game the last card is simply played at the end as a normal skirmish or initiative round. If there are 2-4 cards left over, they may be played out as a regular five card hand, merely short-handed. This is an area of the game that merits further play-testing and experimentation.

Variants:

  1. Deuces over Aces. We felt this made the game more interesting as it gave the 2s some value, and made the Ace less of a super-weapon. 2s still lose to everything else, and Aces still beat everything else.
  2. Low card wins Initiative. We experimented with this rule to see if it made the game more interesting by providing some advantage to holding low cards. It was inconclusive whether it made a meaningful difference to the game. I kindof liked the idea, but since the player has no control over what card they are playing for the Initiative, it seems not to make much difference. It might make some difference in a game where the deck is recycled rather than played through once.
  3. What’s up? Initially I had suggested that the players could determine how many, or whether to play any, of their battle line cards face up. My thinking was that this might lend some element of strategy to the play, and that players might want to show strength or hide it, or show weakness or hide it. We ended up opting for a more simplified mechanic of “even cards down, odd cards up” in the battle line. But I think there is still some potential for this to be tweaked into an interesting mechanic. Further study is warranted.
  4. Recycle the deck. In this longer-playing variant, rather than play through the deck one time, the players would recycle their victory pile back into play. Play would continue indefinitely until some victory condition is reached. The obvious victory condition would be one player holding all 52 cards. But that would take a long time to play out. There could be other victory conditions for this variant, such as holding all cards of a certain rank, such as Kings.
  5. Ace in the Hole. In this variant, each player retains one of their Aces as the last card in their deck. They may opt to play the ace at any time in the game to “turn the tide” of a Skirmish or Battle that they otherwise would have lost. If the other player still has their Ace in the Hole, they may counter and play it, creating a “tie the tide” situation which then results in the usual Battle resolution. In practice, this seemed to offer no additional depth to the game’s strategy.
  6. Jacks are Spies. We talked about, but did not play-test, giving a certain card rank the ability to “spy” by looking at an opposing player’s down-card without engaging it in a skirmish. How this would be worked out in practice remains to be workshopped.
  7. Flanking. To make play with low value cards more interesting, we talked about but did not play test giving players the option to combine two low-value cards in an attack against one of their opponent’s cards. The exact conditions to allow this and how to resolve outcomes were not determined. Further study is warranted.

Strategies

A few interesting/notable strategies were observed during playtesting:

  1. If you have a low-value card and have initiative, it may be worth attacking a high value card of your opponent, to “waste” their high value card by sacrificing the low value card. This is especially true if your low-value card is showing, since your opponent knows it is a sure victory and will likely send one of their low-value cards against it to defeat it.

The Takeaway:

Here’s some of the things I got out of this exercise:

  1. There’s still a lot of life left in a deck of cards. It surprised me that playing cards are so adaptable that we can come up with novel and interesting game ideas without a huge amount of effort. Perhaps this shouldn’t surprise me so much, a deck of cards is simply a mathematical system, which can be manipulated in so many interesting ways. Still, if you think that the only games there are to play with a deck of cards have all been discovered already, think again.
  2. War isn’t such a bad game. It might not have a great deal of depth to it like Poker, Spades, or Gin. But with just a few minor tweaks we turned War into a game that was pretty fun to play. If it’s not that far off from being strategically interesting, it’s doing something right. War is also a great game for teaching very young card players how to play games with cards, and the value of this is not to be under-estimated; it’s OK for introductory games to be trivial or even deterministic.
  3. Rapid prototyping and workshopping is a lot of fun. The best thing to do is to play ideas out and see how they work, not to argue merits for doing something one way vs. another. Our group didn’t argue at all, we just threw out ideas and tried them out and then it was pretty evident to all whether they worked or not. We kept what worked, and kept tossing out ideas until we felt satisfied that the game was fun. Working with the group this way made things very fun and we progressed very quickly. I’ve been in groups where endlessly arguing just results in ego clashes and slows things down and makes the whole project not just lose its fun, but often lose its chances of being successful.
  4. Sam Marcus is a sharp, likable guy who’s good at talking and listening, has good ideas and a good sense of judgment, and is therefor extremely easy to work with. I really hope I get to work with him again on future projects.
  5. I’m particularly strong when it comes to game mechanics. I have an intuitive grasp of what will work and what won’t, and how a rule modification will affect the overall system. While it always is necessary to test ideas out, most of my ideas turned out to test well, and worked much as I expected they would.