Mostly these experiments were created in the context of the Berlin Minijam, a monthly jam in which people have 8 hours to create something. It's a rush and always a lot of fun. And it doesn't take up too much time. Some experiments were made by a team, sometimes I do everything myself. I often choose to create software in Haxe because it is open source and usually allows me to convert games to multiple platforms, among them useful web deployment like flash and html5. (Haxe basically converts your code to native code for each platform, which is optimal, though sometimes it may take a little tweaking depending on the platform.) I use no rules for experiments but in general I make sure to have at least a vague emotion, a serious topic, and something funny in my head before I start.

Beware mortals, at the recent Berlin Minijam we (Charly, Martin and me) created a game fit only for rock gods. Translated that means: it can only be played by people with a guitar hero controller hooked up to their computer (I used a ps2 to usb converter).
I haven't implemented any other control methods this time, my apologies. This postmortem will also be a bit short, busy busy busy.

The jam took place at GameDuell this time, they have a large place in the middle of Berlin. It proved to be very popular with about double the amount of attendees I've noticed at the regular minijams. The wi-fi network unfortunately wasn't prepared for so many connections at the same time, so there was no internet for some, but there were free drinks made from the tears of internet junkies (like club mate) to soothe the pain.
So, Tobias (one of the organizers) had devised one of his usual devious schemes in order to get people talking. And as usual, that worked. I brought one of those plastic guitar hero guitars with me and started recruiting people for a game I wanted to make with it. In the end my partners in crime for this jam, Martin and Charly, were kind enough to jump on board.

From theme to game

There were three main themes as usual:
- local multi player!
- crossing the desert
- Games with procedural created stages. In general, games that aren't the same if you play them again.

As aspiring rock gods, we didn't really pay attention to them. Enemies spawn at random Y coordinates, and we intended to google a desert picture for the background, but no internet so that was out. No biggie. One thing we had plenty was ideas, so the brainstorming went really well.

A while ago, I came up with the general idea of using one of these guitar controllers as a proton cannon from the Ghostbusters, so we started out with that general idea. From there it morphed pretty quickly into a pixelated rock theme. We even added an Elvis hairdo to the main character at some point. The general gameplay idea was to zap some flying creatures with a beam coming from a device in the characters hands, which became the almighty axe guitar. And by tilting the guitar up and down you would be able to control the beam coming out of it.

Then, when creatures got close, you were supposed to bang them over the head with the guitar, like how you would use a real axe. Unfortunately it turned out the gyroscope output we got from the guitar was just a simple 1 or 0 trigger and holding the guitar upside down like an axe did not change that signal at all.
We also wanted to have different types/colors of beams which would affect different types/colors of enemies. And of course a whole lot more, but as always 8 hours is a very short time to make a game in.

Lessons Learned?

- For programming I used Haxe and Flashdevelop, and a little bit of Haxeflixel because I basically took my last minijam game that had dance mat controls (Yokai Stomp) and hacked the guitar controls into it. It was a bad idea, the code is probably the worst I've ever written in my entire life. I ran into some trouble with z-sorting or layering because I used both flixel sprites and normal sprites, which of course doesn't mix that well.
- At first we were working on a curvy/wavy beam, much like the ghostbusters version that had some weight to it and that you had to really pull up and down. I unfortunately wasn't able to work out the collision math, how the beam would hit the enemies, so we changed it to a straight laser beam pretty late into development. The lack of internet didn't really help there but still, Math is not my strong point. Keeping the curve beam simple and then simply copying and pasting some code would have been the best middle of the road solution here.
- All of the graphics were mostly designed on paper, we photographed them on a black background and cut them out, scaled them and put them into the game. It works totally fine and it proves you can make games without knowing the ins and outs of graphics programs. But because we inserted the graphics into the game one hour before the presentation deadline, I was unfortunately unable to properly animate them through code. Because of this a whole nicely thought-out title sequence got cut, which is a real shame.
- The biggest problem was the actual guitar input signal. You can get the buttons working easily, but the tilting turned out to be very limited and the whammy bar (the small iron handle which is analog) didn't send any signals at all. Of course, with proper drivers or programs like joy2key this probably could have been worked out, but I always like to have things functioning with minimal user action required, no special programs or installs. Unfortunately that's hard to pull off, just be sure to keep it in mind when you work with one of these old ps2 guitar controllers. It definitely had me stumped for a while. If anyone figures out a way that works out of the box, please be sure to let me know.
- Another issue, that might not be something anybody else runs into, is that the guitar stopped working when I plugged a mouse into the pc. I have a bit of a weird setup with a windows 8 tablet and all devices and hard disks are connected through a usb hub. (Which I can't show you right now because I loaned out my phone/camera-usb cable, and haven't gotten it back for over a month now. So don't loan out stuff to people at minijams! >_< ). For some reason (not power overload) it started acting weird. So I had to develop without a mouse, or lose the guitar, but if you get a weird response from your guitar controller you might want to check these sorts of things.

Free stuff!

You can play the game right here. Unfortunately you need one of those guitar hero controllers to play. I really haven't tested anything beyond a simple ps2 guitar with a ps2-usb converter, but it might work with different guitars as well.

Controls are as follows:

- Red, green and yellow buttons fire the different colored lasers.

- Tilt the guitar up to tilt the guitar in the game. And put it in a normal position to let the in game guitar tilt back down.

- Strum the guitar to add an extra laser that's very buggy. But it's an extra laser, what more can you ask for?


The full source code and project are available from here.

Category: Experiments | Views: 626 | Added by: Garfunkel | Date: 2014/Jul/27 | Comments (0)

Last year I moved to Berlin and started taking part in the Berlin Minijam. This is a game jam where people have 8 hours to create a game, whether digital, physical, board, pen & paper or just a design concept doesn't matter. There are no real rules, only guidelines. The jam usually starts at noon, participants mingle and vote on theme suggestions for about an hour. Then they form groups or go solo and start working until 21:00 (9pm) when the results are presented, these presentations are also recorded and uploaded to youtube.

Because of their nature videogames are multidisciplinary. However the most often seen backgrounds from participants tend to skew toward programming, probably because that's always been very fundamental to making videogames. I've participated in 12 minijams now, and I've written short postmortems for each of them. The most clear and concise way to consider the aspects of the minijam seemed to be a short list, so I'll start out with that, followed by a couple of boring but practical tips as intermission, and I'll close out with some thoughts on where to grow from there as developers and propose a concrete way to do this.

Aspects of the minijam

Monthly occurrence
+ Never a long wait for a jam, plenty of opportunities to participate and experiment.
- Regular interruptions, tend to occupy the mind, a lot of work for the organizers.

Short time (8 hours)
+ Small time investment, easy to try out, fits into people's schedules.
- Little time to get anything done, might deter people from trying out new ideas and instead fall back to cloning.

+ Lots of creativity, abundance of silliness, probably plenty therapeutic.
- Perhaps a bit too silly or noisy at times. For instance, close to presentation time some people are working really hard to get that last feature in, while some others are already done and eager to get an early peek at what everybody else is doing.

+ Themes focus attention, gives people something to talk about, gets them on the same page.
- Sometimes there's a tendency to conform and discard thoughts that deviate from themes.

Theme voting
+ Fair, most people will get something they're okay with.
- The lowest common denominators rise to the top. Themes like retro, 256 colors etc. do very well for instance.

Social stuff
+ Chance to meet new people.
- Sometimes you tend to talk all the time and not get much work done.

Brainstorming sessions
- Tendency for feature creep.
+ You do learn to cut features.

Creating, doing actual work.
+ It gives a decent impression of what making a game is like.
- The omission is of course the big content, refining and polish phases, which may lead people to think making games is little work.

Working together
+ Social skills, getting used to mindsets of people from different disciplines.
- Compromise on ideas, presentation, and redistribution of the work. Not everybody is comfortable with showing failure for instance.

New technology & techniques
+ A number of people use the minijam to try out a new framework or language. I'm impressed with how often this works out well.
You get exposure to different technology and techniques, and that helps you reflect on your own, be more critical, and find out what fits with you.
- It doesn't always work out. In learning new stuff you're very dependent on information, and that may not always be available.

Repeating and refining
+ Working with the same technology multiple times helps you build up a library of tiny helpful things. The code is horrible spaghetti in most cases with plenty of hard coded chunky bits. But, there's usually at least one thing you figured out, and that solution can be added to your utility belt.
- There's often a bit of arguing about which tech or technique is better, always sticking to the same thing can make you sensitive and devolve argumentation into snobbery and elitism (though I've rarely seen that happen, grasping at straws here).

+ Resonance with peers, seeing what is doable (If he/she can do it, I can do it), learning from others, social skills++, free applause.
- Scary, sometimes feels like an obligation and that can make people leave early if things didn't really work out.

No contest
+ Room for showing failures to others. Everybody learns.
- Perhaps less drive because of lacking fear of competition. (Though the 8-hour time frame proves to be plenty challenging by itself.)

Small games
- Too small to make money off of them. No room for grand and complex structures in design.
+ Good for testing prototypes, new ideas.


Practical tips from personal experience

- Make sure you're well rested and prepared. Have everything you need ready and installed. Not having code completion sucks, not having the proper drawing tablet drivers sucks. You don't want to lose time on this.
- Bring pen and paper. It really helps communicate ideas and sometimes it helps as a reminder of why you chose to go with A instead of B.
- Bringing up existing games that everybody knows helps communicate your thoughts but also tends to keep new ideas confined, because everybody now has that game in their heads.
- Staying pragmatic often leads to good results. Make sure everybody can work, and doesn't have to wait on each other. Figure out at least some basic visuals and mechanics before you flesh out the story for instance so programmers and artists can start working.
- Make sure everybody's on the same page and knows what to do. Getting something on screen helps.
- Mostly the time limit is hard to deal with. You do not have the luxury to get stuck on a bug, rewrite code, or make lovely placeholder graphics first. In the subway ride to the jam I already tend to design more than I can implement in the time there is. But you learn to cut stuff often and early.
- Iterative development is very stimulating. Get something very simple working first, that helps give everybody a boost. And you'll see new ideas and even completely new designs popping up regularly.
- Don't change filenames, just overwrite files. It's ok to keep a _v1, _v2 around for yourself of course. But others should be able to just copy, paste, new files are in the game, done.
- Being able to show off some basic interactivity really helps. Interactivity is magic. I definitely suggest focusing on that first.
- Artificial Intelligence == Math.random(). Works fine for a 5 minute play session. The same goes for proper balancing, it can be done later, people will get it.
-Re-use stuff from previous jams, use public domain resources like graphics from opengameart.org or take pictures with your phone to create a quick background or even photorealistic in-game characters.
-Save early, save often. You really don't want to lose work because your OS crashed or somebody accidentally unplugged the wrong power cord.


Level up

A thing that often comes up is finishing/expanding the game after the jam. Adding some more features, perhaps try to sell it and make a couple of bucks. It rarely happens, because that's where a lot of the long monotonous days are required. And also, in case of a group of relative strangers who may not all continue to work on the game, it's likely reasonably difficult from a financial/legal perspective. Still, people often do want to do something more with it and not leave the small unfinished experiments as they are.

Some free options, doable by solo developers:
A pragmatic approach that might work could be to release a pack of prototypes in the style of Warioware or Mario Party. You could make a couple of these microgames in one day, collect a bunch of them over time, and release it as a single game. It's reasonably flexible but does have its constraints and you'd need to keep this in mind during development though.
Another approach might be to provide a marketable handle by doing something like Sharecart where certain games share a file between them which influences some aspect of the game, like colors or object placements or whatever. It would cause these games to have something in common to identify them by, so they could present this common thing as a front / image, which might be easier to market.

Of course it also happens sometimes that teams do actually develop jam games into full games. But often these are pre-formed teams from already established indie game studios. A lot of indie developers actually work solo and take jobs as freelancers to get money, and in the time left they make their games. It's not easy and it often happens you can't do everything by yourself, so you have to hire someone else. That quickly becomes expensive, so you end up not working on quirky games as much as you'd like. This is still the same way a lot of studios develop games, do some games for a publisher (movie tie-ins for example) in order to finance your own ip. This is a hard road to take by yourself.
At jams though, everybody works for free...

There might be some middle road here, a hidden path beyond those thorny bushes over there. So I'm proposing to have a look and test a new model. It's still in pre-alpha or whatever, so everything might change. I'll call it rotational tyranny for now. (Don't worry about the name, it's meant to provoke criticism. Consider how a large number of people spend most of their waking lives living in the voluntary dictatorship of a company rather than in an actual democracy as a reason.)


Rotational Tyranny

Minijams produce very small games, decent prototypes, and are small enough in scope that they can often can be polished, finished, adapted and released in a short amount of time. Let's say a week or 4 days by a team of 4 people. If you had to pay each team member let's say $1000 a week ($200 a day), that would be expensive. We're poor. It's an obstacle. It creates overhead. The smaller you are, the harder it is to deal with. So let's try to do without the money.

When would you want to work for free? Making your own game perhaps? Royalties? How about trading hours of work?
Let's say everybody on this team has a small game they really want to get out there, polished, finished, marketed. But it remains unfinished because they can't handle everything themselves or it would simply take too much time and resources for what is not a major project.

You could help each other out for a few days and get their help in return, the bonus being that everybody gained experience from working on multiple released games. Granted, they'd be tiny, but having a list of tiny polished & released games looks a lot better on your C.V./Resume, and that tiny size still allows for original designs and experimentation. The experience of taking a game from start to finish, including concept, multidisciplinary development, website, marketing etc. is very valuable. And it would be a step in closing the gap from creating unfinished gamejam experiments to having a regular job in the big game industry.

Think of it like in the M.A.S.K. cartoon, or Mission:Impossible, or Shadowrun, or wherever you're the cool person that gets to put together a cool team to go do something cool. During your jams you see all this cool work from all these cool people. Imagine if you could work with any of them, cherry pick a well balanced team, and make a kick-ass game.
The trade-off would be that all the other team members get to do the same thing. And you'll have to work on their game as well. Of course every team member would have to agree beforehand, which is why it's a good idea to refine games from previous jams, so everybody knows what they're getting into. And if you can't offer anything of value to the games your team members want to make, you may have to compromise on cherry picking. It might prove a nice balance between specialists and jack-of-all-trades...

There's a lot of flexibility of course but let's take the example above where a team of 4 people (including you) is working on 4 games for 4 days each. That's an investment of 16 days everybody is making, including you, 16 * $200 = $3200. With that you'd pay for 3 other people working 4 days on your game, 3 * 4 * $200 = $2400. You could see it as working for 75% of your income, or a 25% pay cut.

But it's just an example, amount of people and days can vary of course, though I strongly suggest each team sticks with the same team members and amount of days until all the games are done. Otherwise it's likely things will get messed up.

Some more examples, just to get used to the idea:

4 people team, 4 projects lasting 3 days each. Comes to 12 days This could be done in 2 weeks, which makes it viable for a lot more people I think.
In 12 days by yourself, you might make about $2400.
Instead you'd get a team of: (4)3 people * 3 days * $200 = $1800
75% pay.

3 people team, 3 projects
(3)2 people, 3 days = $1200
9 days by yourself = $1800

(3)2p, 4 days = $1600
1p, 12 days = $2400

(2)1p, 2 days = $400
1 person, 4 days = $800

(5)4p, 5 days = $4000
1p, 25 days = $5000

(5)4p, 2 days = $1600
1p, 10d = $2000

(8)7p, 3 days = $4200
1p, 24d = $4200

I doubt really large teams or really long time investments are a good idea. Cover all your bases, from initial design to development with graphics and sounds, to publishing and marketing. But, ensure sure all team members you pick would have something to do all the time. And I'd try to stay below a month at least. Anything bigger is probably a step up from this "rotational tyranny" model. I'm not sure how it scales but it just seems impractical and more safeguards would have to be in place in case something went wrong.

Now you could say I'm being stupid and my time as a programmer is worth more money than the time of a story writer or game designer. But I'd say you were a capitalist and it's more important to create a solid group with solid motivation that can deal with tyranny. That tyranny comes from the leadership. Every team member has their own game which means they lead the development for that game and tell the other team members what to work on. To ensure people are invested in all games, I'd suggest splitting the revenue of all games equally. Perhaps even only selling the games together in a bundle. This also makes all team members look critically at each others games before they commit to working on it. And bundles might make a concise presentation and marketing effort easier as you can provide one front with a decent backstory, you could even provide a mini documentary, focus on leader personalities or whatever.
(Regarding game development order, I'd suggest throwing some dice to determine which goes first, second etc...)

It would probably help to aggregate these bundles on a single website, together with all the promotional material etc. So consumers really learn about what they can expect in general, and which developers they might want to keep an eye on. This also helps developers present themselves to other developers, which becomes a lot more important of course. I'm a strong believer in picking people based on the work they've done. Jams are a great way to illustrate what somebody could do with a couple of extra days and what skills might be relatively useless. (For example I programmed C & C++ for years and created a whole bunch of tools for Square Enix and did data visualization etc.. but it wouldn't really be of much use to these sorts of projects.)
Perhaps it could all be combined with a developer forum, profiles etc. It's very useful to have one place where you can go to get an overview of developers, their skills, their work, what they want to work on, in what capacity, taste in games etc. You want to get an impression of people you're forming a team with, though partially you'd know because you've been going to gamejams right? So it's all stuff that can be figured out after a couple of projects have succeeded.

A large part of this is wishful thinking of course, but I'm willing to give it a try. And it seems like a good way to have time investments in game jams pay off while at the same time maintaining game jams as a rich breeding ground to add to your personal repertoire. Might take a while to get something underway for me personally, and I'll do a writeup once I've got something, but there really is no reason why that should stop you from trying this out yourself right?

Category: Experiments | Views: 702 | Added by: Garfunkel | Date: 2014/Jun/18 | Comments (0)

It's pretty much summer here in Berlin, blazing hot. Which is probably why there weren't many people at the minijam this time. There were a lot of great games though and the warm weather provided me with an enlightening insight. For the past month I've been sitting on my butt doing promotion for AnimalAlbum and it's getting me fat :) So it's the perfect time to start sweating with purpose and make a game using a dance mat.

I ignored all the suggested themes, as usual I guess, sorry. But since a long while I've had this idea of how to make dance mats work for standard 2d platforming games, I just never made time to implement it. In this platformer game you'd of course play as a sumo, stomping everything beneath your mighty feet. It worked out pretty well, so please have a look.



From design to game

When you're making a 2d platformer, gameplay is king. I may be biased as a big fan of the genre. But how the game feels in terms of controls (gameplay) really is super important to 2d platformers, and there can be an incredible difference in this between the best of them, there's not one best way to do it. Compare for instance the platforming of games like Super Mario World and Cybernator (Assault Suits Valken) or something more modern like Braid and Super Meat Boy. In each of these games their platforming style is something crucial to their identity. So getting the right feel is important, especially if you're using a weird controller like a dance mat.

For those of you who don't know what a dance mat is, it's basically a mat with big flat buttons on it that you can press by stepping on them. Below is a picture of a reasonably complicated one, the cheapest ones like these cost about 10-15 euros/dollars (cat not included). A lot of people have them lying around, much like Guitar hero controllers (guess what I'll be working with in a future jam :).

So with this dance mat control method, I felt it was important to focus on the feet of the player. In real life, walking is pretty much an automatic thing. But if you have to consistently remain in the same place and step on the right buttons on a dance mat, then it can feel pretty sluggish. What came to mind was the image of sumo wrestlers preparing, throwing their legs up in high arches and planting their feet in the sand. The idea of japanese demons or Yokai as enemies was a short-sighted knee-jerk association (as both are big parts of japanese culture, and I'm an ignorant westerner). But I really like these demons from games like Pocky & Rocky (Kiki Kaikai) and Otogi, and it all seems innocent enough anyway. So that became the setting.


So the first thing I had to do was detect input from the controller, anything. That turned out to be pretty easy at first glance. On the subway ride to the jam I thought about how you would control the character exactly and made a few sketches in typical game manual style. With that done I spent about two hours implementing and tweaking how it feels to walk and stomp enemies. There's a lot of room for improvement but it gets the job done and feels fun to do.
During this testing process I had added a basic platforming level from an experiment I made exactly one year ago. And from there I started to work on getting enemies to appear and move about and get squashed, which took more time than I had expected. Then in the last half hour I added the graphics (I had been working with basic blocks all this time) and in the last 10 minutes I decided to add the jumping ability.

Lessons learned?

So what was up with the jumping ability? Initially I had planned jumping to be standing with both feet firmly planted on the left and right buttons and then just jump. You could charge your jump, much like Super Mario Bros 2, by keeping the buttons pressed a while before you jumped. But at the last moment I implemented jumping by simply pressing and releasing the down button, which doesn't feel good at all. The problem was the signal I got from the dance mat.
The problem is how a basic gamepad functions, you can't normally press left and right at the same time. Those directions map to the X-Axis, and that has only 1 value. -1 is far left, 1 is far right, nothing is 0 and both is 0. This is something I lost hours of time on trying to find a nice way to deal with it. I wanted to make sure I couldn't make the distinction between going from both pressed (0) to nothing pressed (0). And when I couldn't I decided to leave the matter be. I did think of some other options but ran out of time to try them out.
I guess the lesson here is to not fuss over these things during an 8 hour jam. But as the controls were integral to the experience, I can't really recommend not fussing about it. (And as it turns out, the signal issue apparently also has something to do with my Playstation 2 to USB adapter, but you want to support the broadest amount of devices possible so...)

In the same vein there were a lot of other things I wanted to implement but didn't get to. You probably already imagined all the cool things that you could do with this design. Jumping and then butt stomping enemies, double jumping by landing on the up button after you jump, sending out shockwaves if you charge your foot stomp long enough etc.
One of the most vital things for this design that didn't make it in was a simple procedural level generator. I personally feel dancing games are boring, but the same goes for playing the same platformer level over and over again. You want to be surprised and be kept busy, because playing a game with a dancing mat is tiring. (I've tried playing many normal games with it.) So the game really has to pull you along and I think one of the best ways is to keep offering new stuff to the player.

An issue I ran into while testing the game on other computers was the numerous sizing artifacts, possibly purely a Haxe issue that I simply didn't think to take into account. Usually a computer just runs a certain screen resolution and that's that. But it seems to be pretty common nowadays to have the OS do some automagical enlargement of things like text, default buttons and sometimes stretching complete windows. As I love pixelart and absolutely despise randomly stretching pixels I don't size my art to fit the window, I make my art and tell the window to be a certain size. That doesn't seem to be very consistent within Haxe / Haxeflixel at the moment, and it's possible it's a bigger problem. But it's also possible it's easily solvable. But it's something to be aware of when you're testing your games, Haxe or not. I'm not fixing the issue here so you can try different settings yourself and see the result.

As I said earlier, while testing the controls I added a platform level. I was able to take it from some old code I made earlier and just slap it in. And it worked pretty much without a hitch. It's a good argument for re-using code and building up a large set of scraps and examples you made and keep them at hand during jams.
It's also handy if you remember how that stuff works or document it, for some reason I couldn't figure out why my enemies weren't moving as I expected. It's probably a small thing I overlooked but it was one hour before the presentations so instead of working with the engine I decided to just hard code the stuff and put in a timer that spawns enemies in front of the player. They also completely ignore gravity and such as a result.

I was also working with a fresh re-install of Haxe and code auto-completion and redirection wasn't working. Meaning I had to look up exactly where that one function I wanted to use came from a lot of times. Could have been prevented by preparing a little better.

Save early, save often. After a couple of hours of coding and stuff not working out I like to take a break by doodling something. On jams, that's usually when I draw a title-screen. It's never something fancy but for this game I looked up the kanji for yokai and doodled everything with a nice brush and added some nice blending effects etc. And then the program crashed, selected the wrong font I guess. Damn. Hadn't saved. 30 minutes of doodling and relaxation gone. Replaced by frustration and stress. Could have been prevented.


Free stuff

First of all you can play the game by going here. I added keyboard support, but the game isn't meant to be played like that, and it's pretty tiring for your fingers. If you want to use a dance mat the game requires flash 11.8 or higher.

Controls work as follows:
Stomp: Keep left and right pressed, then slowly raise your right foot/finger, then press it back down.
Walk: Alternate left and right.
Jump: Press down and release.
(You can also walk while jumping, use that to get onto the platform)

The full source code with project and art and stuff is available from here.

Category: Experiments | Views: 690 | Added by: Garfunkel | Date: 2014/Jun/08 | Comments (0)

The May minijam was a bit frantic, lots of people, lots of tiny troubles, lots of fun. I didn't really prepare this time and it turned out my usb hard disk got corrupted. As I was re-installing the Haxe environment Christiaan mentioned to me what a pain it was to get Haxe properly set up when you have an old version installed. Oh dear...


From theme to game

Turns out I wasn't going to use it. Adam had an idea in mind for a game and wanted to try and program it in javascript with the Panda JS framework, daisy-fresh. I liked the idea so I jumped on board, sort of half installing the necessary tools and half learning javascript and Panda JS.
Unfortunately the new framework didn't have a lot of example code yet and on top of that it was all hosted on github which was only sporadically available, if at all. So we made slow progress. And when we did, we ran into a possible bug in the framework (turns out it we just didn't use a function reference/pointer correctly). I did some of the graphics while Adam kept wrestling with the code, and we got some help from the nice people around us, but in the end we didn't get around the issue in time. Adam was able to get a tank on screen and have it move about the place, but to implement the rest of the design we simply needed more stuff to work, or more knowledge of workarounds. It's not a good spot to be in when working with something unfamiliar. So in the end we didn't really have anything to present.

I liked the thought behind it though, so the next day I decided to fiddle with it in Haxe for a bit. I didn't keep to the design 100% but it gets the point across.

I'm not familiar with this myself but the background story is that, in 1968 Czechoslovakia was invaded by a number of countries. I believe this was called the Warsaw pact. Loads of tanks moved into the country and these are now well known apparently, the T-34 tank (I know nothing of tanks besides the cute ones in Advance wars). It was an overwhelming power but it seems a bunch of Czechoslovakian citizens were turning the signposts around so the tank drivers would get lost and couldn't find the way to the capital that well. So the idea was to show this struggle of deviating the invading forces.

Adam had already come up with the basic design, I just made a few changes in my implementation of it the next day, simply because I also had other things to do and didn't have that much time. The initial idea was to make it more of a controlled puzzle, and when tanks would bump into each other they would change directions or crash or possibly fuse into a super tank ala games like Threes or 2048.
So to keep it simple I just made every hex position a directional pointer that the player could alter to divert the tanks. And also made it so the tanks change the direction once they're past (To sort of symbolize they had a vague notion something was wrong). Sometimes it happens that they instantly recognize a problem and reset the signpost to point the way to the capital again. It makes the game less deterministic and more of a frantic chaos that slowly creeps up on the player.
It looks very clear and easy at the start, and it is. But because the tanks keep appearing faster and faster and their slight "smartness" breaks the reliability things get worse and the overview is lost.
It has to be noted that at this point there are probably so many tanks that it's hard to even see the arrows in some area's.
Another flaw that I find a bit annoying is that you have to click on the arrows instead of on the hexes. It's more about intention then about pixel perfect control. And when you lose, which can happen unexpectedly, one often tends to click away the game over screen.

Lessons learned?


* Setting up stuff took a lot of time and a lot of disk space. This is stuff that's probably better done before the jam. Just have an example project up and running, that can save you a lot of trouble. 8 hours go by fast.
* Personally I think the best way to learn a new language is to dive into example code and modify that. Everybody might have their own preferences, but it's probably a good idea to make sure you have access to some examples at all times.
* The sunday after the jam as I was sort of half working on the game I found it very nice to mess around with it. Tweak some parameters and try out some different simple actions. If time allows I'd totally advise it, it can be very inspiring. During development I could spawn tanks by clicking on hexes, it turns out that this is actually pretty fun to do. I see a lot of potential for using this to create a sort of real time "Advance wars" game mixed with "Threes".


Free stuff!

The full project and source code is available here. It's written in Haxe and includes all the graphics. You can also get the graphics from opengameart.

And of course you can play the game here.

Category: Experiments | Views: 1064 | Added by: Garfunkel | Date: 2014/May/24 | Comments (0)

First of all a great big thank you to Rico, Anton and Chika for being playable characters in the game!

The April minijam took place pretty quickly after the last one. I also happened to have an unfinished game leftover from the March minijam, so I decided to try and extend that. Needless to say I ignored the jam themes in doing so.

The basic idea was to create a parody of a typical side scrolling fighting game (like double dragon or final fight), where instead of simply hitting everything and everyone in range of your limbs, the player would be encouraged to think about avoiding fighting. At the last jam I ended up with only a very rudimentary fighting game clone, which was exactly the opposite of my intentions. If you played the result, you'll have noticed it was pretty horrible.

So I wanted to try and turn the game more into the parody I had been thinking of. And it makes sense that you need some original implementation in order to be able to criticize and reflect, and build a parody out of it.

This jam I was able to fix the horrible collision detection, depth sorting, the loading issues and such, which makes the basic game more enjoyable. And once the worst issues were out of the way I concentrated mostly on the consequences of the player's actions and the management aspects.

From sleepy ideas to game?

I came up with the general idea for a managed fighting game a while back. But on the morning of the minijam I woke up at 6:00, my neighbours were having a fight. Under circumstances that might have been inspirational, so I drew up the design right there. Below is the hyper advanced flow diagram that came out of it.

When designing the stuff to do in a game you generally have to think in terms of actions or system design, and story or the context of these actions. You could see it as: How things happen and Why things happen. The system is what people play, so that's what they'll develop a feeling for in the back of their minds, and therefore is the most important of these two in my opinion. But it's very valuable that there's something that explains to players why they're doing these actions, something that provides a context. Which is where the story comes in. Ideally these things are intertwined and well connected and thought out. Not something I do on an early saturday morning.

The basic idea is that, as a parody of final fight, you're the mayor of a city, in times of food shortages. Your goal is to balance out state money and your popularity with your citizens (while you're beating them up).
Money allows you to order random food drops into certain areas of the city, which you can try to acquire personally and then redistribute to the hungry children as part of a sneaky propaganda campaign.
Citizens will be getting in the way though because they want the food as well, and if you beat them up they'll need to be treated in the hospital, which in turn means the healthcare system ends up costing the state money. That's also not the best way to gain popularity.

It's a bit convoluted and a hassle to explain in words, but games have the advantage that you'll automatically get a feeling for how a system works, picking up bits and pieces as you play.
Unfortunately I didn't have time to implement all the options I had in mind, nor to properly balance out the consequences, so sadly that feeling is absent from the game at this point. But with a little imagination you can see where the game could go. You'd start to set up your own small battle arena's (publicity opportunities basically), picking and choosing the most opportune time to act, to maximize the publicity effects of your public actions. While in the meantime you would be trying to get more food into the city and improve the situation in general.
This changes the typical beat'em up game flow pretty drastically, so now the experiment I regarded as a flaw has turned into something I can live with. Even though the implementation is still so far from perfect that it's very hard to see anything else than a basic beat'em up.

Lessons learned?

- First of all, taking pictures with your phone and using them for game visuals works pretty fast and looks alright. It's worth trying if you don't have anything else.
- Don't start a jam day completely tired. I had very little energy and it simply made things less fun. Puzzles to figure out become bothersome instead of fun challenges.
- I'm happy I extended the initial failure of the last jam. It may still be very unfinished but this time I was able to implement enough of the management stuff that I can see how this kind of game could turn out. How the flow changes etc. For me that's a way to learn, expand design theory and such.
- 8 hours is little time for making and balancing out some sort of management system. It's very important players get a clear sense of the consequences of their actions and that tends to get lost in the rush.
So if you make a game with a system of values behind it, the player won't be able to get a feel for it, and you can't start to balance it out either, until it's finished. That makes these designs pretty unsuited for game jams I think.
- As always cut early, cut often. Here's a list of some of the missing parts to illustrate more of the general design:
* No visible hospital + victims, I intended to show the amount of victims in the hospital at all times. Literally stacking up hospital beds with injured people. It was important to me to establish a clear absurdity, because you can't treat food shortages and violence lightly living in wealthy western society.
* As soon as an ambulance came to whisk people off to the hospital, your money was supposed to start draining slowly. Like an inverse cookie clicker basically. The more victims you made, the quicker your money would drain. This would have made the pace of the game way more frantic and as you could only heal them outside of battles it would add to the stress of players, possibly resorting to more violence in order to get out of the situation.
* The ambulances were supposed to hit you when they drive by. Actually they were supposed to stop, have people come out and pick up the victim and then drive off. At which point you could also beat up the ambulance or the drivers for more mayhem and general sillyness.
* The bars are very unclear. Green is money, yellow is popularity, red is your health. And the consequences are way too imbalanced. It's very easy to keep your popularity high. Which should be the opposite, thereby forcing you to go on publicity campaigns in the first place.
* You were supposed to only go into areas with food. So you'd have to invest in random food drops first. I removed the limitation because it just confuses players at the moment. The less food there was in an area, the more enemies there would be.
* Even though the different player characters have their own strengths and weaknesses, there's a bug with hitting people, so everybody just "dies" after one hit. I think I do actually factor in strength but it simply hits every frame without an invincibility period, resulting in the instant kills.
* Another bug is that the general money, food and popularity don't get reset when you have to start over.

Free stuff!

The full project and source code is available here. It's written in Haxe and uses Haxeflixel. I've replaced some of the assets with stick figures and such because they depict actual people and locations.

You can also play the game right here.

(Click on the game once to make sure it has keyboard focus.)
The controls are:
- Arrow keys: Select player + area, and move around.
- Enter: Confirm selection.
- Space bar: Hit people.
- 1 and 2: Spend money on the map screen.

Wait what?
- The red bar is your health
- The green bar is the state's money.
- The yellow bar is your popularity.
- The guy showing up is a random paparazzi photographer off the internet who's there to take your picture with the happy children. The screen even flashes. Be quiet.

Category: Experiments | Views: 624 | Added by: Garfunkel | Date: 2014/Apr/13 | Comments (0)

So, the March Minijam happened and was a bit of a train wreck for me. In a good, inevitable way :) I hope to explain, show some of the issues I ran into, and decisions I made, in this postmortem.
The themes of the jam were: This game hates you (dearly), Revolution, Rails, and Under the ground. I pretty much ignored them since I already had an idea in mind. I did make the game a little harder than usual though, which definitely showed during the presentation.

How did it go from design to game?

So the basic idea was to make a parody of the typical side scrolling beat-em-up games where the gameplay is basically you indiscriminately punching and kicking your way through some lovely landscapes in order to get what you want.
In Final Fight, a classic in the genre, you play as the mayor, beating up your citizens as you go through the game. (I have no clue how he got to be elected in the first place.) But because you're the mayor I thought it would be interesting to add some responsibility and consequences to your actions. Mayors need to deal with things like that right?

I started out writing a very rudimentary side scrolling beat-em-up, and the idea was to then add some simple elements to the game that show the consequences of your actions. For example an ambulance driving the people you beat up to the hospital on the side of the screen, where you see the victims and the health insurance costs stack up, that the city (you, the mayor) has to pay.

The idea behind it was that you could then no longer blindly and mindlessly beat up everything in sight. And that you would have to think about avoiding conflict and attaining your goal in non-violent ways. Which is pretty strange for a beat-em-up.

So I needed some sort of goal for the player to attain which is how I came up with the food shortage story. In an area there would simply be a piece of food that everybody would want but you'd have to get to it first. And in the least violent way possible although everybody is fighting you for it.

Lessons learned?

One big problem with 2d games, fighting games especially is the amount of graphics work and animation they require. To deal with this problem in the 8-hour timespan of the jam I would be using photographs and minimal animation. I needed people willing to be in the game though, so I strategically dispersed pie and cake among the minijam masses in order to bribe them. That part was successful, and everybody seemed very happy with the Kuchen and Torten so I can recommend this approach to anybody who needs graphics in the future ;)
What was a big problem for me though was that my development computer was brand-new (after my cat demolished my old one), so it had the new windows 8 and a minimal amount of development software installed. As soon as I tried recording people the basic camera app hung and the computer crashed. We bypassed the problem by recording video from which I grabbed stills afterwards. Cutting the people out of the stills was also very cumbersome since I forgot my drawing tablet and my graphics program went nuts. It tripled the mouse cursor and refused to load previously saved images, requiring restarts all the time.
The fancy new stuff also brought with it some issues with the new Haxeflixel version, the software library I used to create the game more quickly. There was a big architecture update in Haxe / Openfl since I last updated, so some of the things I was used to had changed, assumptions had become incorrect, which slowed me down considerably. Some of these things were the unclarity in registration points of images (used for rotation, but not for positioning) resulting in the bugs with depth-sorting. And another was something about the collision routines that I somehow couldn't get to work properly and ended up implementing really crappy ones myself. So the new-ness slowed me down considerably. It's probably better to make something a bit less ambitious when you're dealing with that.

A lesson to take from working with people's likenesses, is that those people care, and in turn you may feel responsible. In my case for instance I recorded 3 people, but only 1 hour before the deadline I started actually turning the recordings into sprites and putting them in the game. So it was a complete rush job and I only managed to cram one extra player into the game before the presentation deadline. That doesn't really do the people I recorded justice so I also added the other two players last night. (Simple enough but it also seemed to trigger a host of extra bugs.) The additional characters and movesets add a lot of variation to the game. Without them there would have been only a single player character to play the game with.

I'd like to thank Rico Nemetz, Anton and Chika Ngwu for their help, great movesets everybody! Sorry I wasn't able to get all of them in.

Right, now to get to the train wreck part I mentioned in the beginning. Game development is knowing what to cut and when to cut. That goes for multi-million dollar projects just as well as the small ones. Game development in 8 hours is mostly just Malkovich all the way. And bugs will sometimes cut stuff for you, because you simply don't have the luxury of dealing with them. To me it seems like a speeding train that's falling apart but still tries to reach the station. Which is totally fine and even great for minijam experiments because everybody can see that and learn from it. (You might be surprised how many "professional" games have something similar happen, which should be a completely different matter of course and is very disrespectful to your players.)

I've already mentioned some parts that didn't make it but here are some more examples that flew off:
- Early on I was making a system with which you could add masks for a background that would determine where players could walk and where they couldn't. Yeah.. that piece fell off quickly.
- Then I decided to add jumping, as a way of avoiding people, and generally looking funny, like mexican jumping beans. That added to my collision problems so another part flew off.
- I had photographed the pies/cakes I brought, to turn them into food pickups in the game. (You know how you can find pot-roasted turkeys in the walls in Castlevania.) At 20:58 (two minutes before deadline) I feverishly added a pie from a google image search because connecting the usb drive that held the images of the pies would take too long.
- I actually had a number of different location backgrounds and was planning an overview of an upside down map of Berlin as a level select. But I ended up coding the basic fighting game up until 20:00. In the last hour, I cut out the animations for an extra character and added him to the game, which left me with about 30 minutes to create a menu and some sort of game loop. In the player selection menu you can see the wobbly selection rectangle as a result. So that all stumbled and rolled into the station more or less.
- Most importantly though, I didn't get to the actual consequences part. Where the player was supposed to see the consequences of his/her actions (ambulance / hospital / costs / lawsuits) and has to consider them before resorting to good old violence. That was basically the largest part of the train, and the interesting core of the experiment, the reason why I chose to do it. And that failed.

I think I cut about all I could, I needed basic characters, scrolling, animation and at least some sort of fight-collision, otherwise you couldn't send people to the hospital right? And I needed some sort of goal. That took me most of the 8 hours, so in the last hour I thought I would spend time just adding characters, menus and err.. polish. Instead of cramming in some sort of consequence / management thing that wouldn't make sense.
So that means I didn't get to try out the idea at all, and despite of all the other ideas bouncing around, I still want to. Which is why I'll be taking this game to the next minijam (april 12th) and use that jam to add the whole consequences stuff.

Oh and also I understand now the difference between Kuchen and Torte. I can see the Matrix. Many thanks Fabian & Iwan for opening my eyes to the wonderful world of pastries and pies (and cakes).

Free stuff!

You can play the game here. It's in flash, which means you should be good to go if you can watch youtube videos. If the game hangs on the loading screen, try refreshing the page. I think it's an issue with the newfangled Haxe preloader, sorry.

The controls for the game are:
  (first be sure to click on the game to set focus to it)
Arrow keys: To move around and select your player.
Enter: To confirm selection.
Space: To hit people in the face.

The collision tends to work very differently depending on the player character, which isn't what I intended at all and is very buggy.

As usual the game is open source, and as usual it's a bit messy. Feel free to make a bigger mess of it. Grab the full project package here.
Because the graphics are photographs of real people and real places they are not to be re-used please. I've added some funky replacements graphics in the source package instead, in the assets/images folder, you're free to use those. Till next minijam!

Category: Experiments | Views: 740 | Added by: Garfunkel | Date: 2014/Mar/30 | Comments (0)

This is Mike Haggar.
Mike Haggar is the mayor of metro city.
He's also got major muscles and piledrives sharks.
He's from the game Final Fight by Capcom, which is totally cool.
Ah yeah...

He also beats up his citizens.
But they kidnapped his daughter, so it's all good.
Final Fight is a side scrolling beat'em up.

I was thinking how it might be nice to add some consequences. Have the beaten up citizens being whisked away to the hospital, where each one of them has to be taken care of, costing the city and healthcare system tons of money. Which you obviously don't want, being the mayor and all.
So it sort of becomes a side scrolling management game...?

That's right, it's time for another experiment at the berlin minijam next saturday! >_<

For the graphics I've been taking some pictures we could maybe use as backgrounds. And I was thinking of using photo's of people for the game characters. Perhaps with 2-frame walk animations like game-and-watch or south park or something, to save time.
Here's a picture of a guy in a pillow-stuffed kungfu-suit to illustrate:

Dunno, seems doable in 8 hours. Anybody want to join? Or be a character in the game or something?
I'm not doing more design right now to ensure we still have some brainstorming left at the jam.

There have to be Street Apples and Barrel Cakes in it:
Category: Experiments | Views: 610 | Added by: Garfunkel | Date: 2014/Mar/23 | Comments (0)

This is a tiny postmortem about our game at this month's minijam which took place yesterday, it's written from my perspective.
It was a full house this time, so it didn't prove very difficult to lure unsuspecting people into creating a game together with me. I got talking to Andrew and Henrihs and presented them with the basic design concept I made earlier, and it went from there.
Sure, there were themes: Minimalistic, Cube & Local multiplayer. But we ignored them mostly.
For this game Andrew did almost all of the artwork and Henrihs programmed the entire thing in java. I drew the sprites and did basic design.

How did it go from design to game?

So the basic idea was to make a sneaking/chasing game where you'd be an elderly person in a nursing home, trying to escape. When you manage to get away though, you're confronted with billboards for gravestones and funeral services and in general with the harsh way the world deals with your situation, and that would be the end (it's based on a real life place, see the early concept for more info).
So the most obvious thing about the design was that there wasn't a clear win or lose condition (besides from escape), which is pretty standard for games. We had some extended ideas in mind but it would always come down to a situation similar to those classic endless arcade games like Burger time and Donkey Kong and such. You were always going to lose eventually. Your death would always be inevitable. But hey, that doesn't stop us from living in the meantime right?
So we mused on that a little and got to a pretty clear point of what tasks needed to be done. Andrew started working on a couple of photographs I had taken so that we would have scenery for the game to which we could match the action. Henrihs started creating functionality for scrolling image layers, movement paths, animation and scaling. And I doodled some sprites.
Of course there were a ton of ideas left that we didn't get to implementing, like the street chase scene on ice or the nurses sending you back to your room. But almost all the assets that were created made it in and from the result it's pretty easy to imagine how the game would be expanded.

Lessons learned?

- One of the things that always happens when you talk through ideas with people is getting loads more ideas from everybody. Which is great! Chaotic inspiration is one of the best things ever in my opinion, like perpetual energy. This of course goes hand in hand with trying to focus on the basic elements first and keeping a core intact that can still be created within 8 hours. Knowing when to cut and what to focus on is very important.
- Modular design is nice too. It allowed us to build everything up from the ground and make sure and steady progress. In this case we focused on visualization and movement first. As a result most gameplay logic didn't make it in before the deadline, but because mostly everything is visualized it's very easy to understand and communicate how and where the interaction would take place. So things like adding animations for chase behaviors or having nurses order you back to your room would all be small additional tasks that would make use of the pieces we built so far and could be accomplished in a short time.
- When walking on ice, shift your center of gravity forward and walk like a penguin. You won't fall over that way. Penguins are smart.
(Or buy a walker/rollator instead of a gravestone)

Free stuff!

You can get the game right here, it contains a java jar file, so you'll need to have java installed. It should run on pretty much any machine. You can control the grandma by using the arrow keys.
The game is also open source, you can download the full java project right here. It contains everything, including the art.
The character sprites I made are public domain, so feel free to use them however you want. The background art however is probably a bit sensitive since it has real names and real locations so it's better to not re-use them.
The sprites can also be downloaded separately from open game art.

Category: Experiments | Views: 1031 | Added by: Garfunkel | Date: 2014/Feb/24 | Comments (0)

On the 23rd of February there will be another minijam. This is a design sketch of what I want to work on this time. I thought: why not share it online in case anybody wants to collaborate?
I know it's a bit more than a theme suggestion but maybe this works, we'll see I guess. It's just an experiment.

So here's the general idea:
Near where I live there's a home for the elderly. In front of the entrance there's always the same billboard displaying a commercial for funeral services. 20 meters further there are gravestones being sold. At the back of the home is a graveyard that stretches for a kilometer. Here's a googlemaps picture to illustrate it:

What bothers me is how cities become processing plants for humans. Now, I'm known for being blunt and I'm not a big fan of cities, so therefore I am biased and hypocritical. Still, think of how it feels when you are that old person, and you live in that place and sit in your room everyday, looking at the endless graves.
Or maybe your son or daughter has come to pick you up and you had a great day with your grandkids, but now they are driving you back and out the window you see nothing but graves passing by.

So that's basically what I see as the core or the thought behind it.

It doesn't mean the game has to be sad. (Ever heard the slogan: "We put the fun in funeral"?)
For instance I was thinking it could be a sneaking game where a grandma had to escape from the home and could get away by ice skating over the streets. (You don't fall with a rollator contrary to the people chasing you!)
Maybe the intent was to go out and have one last big blast in the snow!

But maybe you'll run into commercials for gravestones on either sides (you can't get out, oh no!).

And maybe you'll get exhausted, and the ghostly hands from the grave would grab at you till you finally give out.

Perhaps you try this everyday, and everyday your strength is weakened a bit more.

And perhaps you can get some strength back when your family comes to pick you up for a day. But you wish they'd come visit more often.

It's looking grimmer..

As you can see I took some pictures of the place about two weeks ago. Not great quality, and I'm not a photographer at all but it could be useful. I was thinking of using them as backgrounds and then draw upscaled low resolution sprites for the characters and objects. A bit like the style in this video: http://www.youtube.com/watch?v=TjLwrnz9e-U (Less effects of course, we only have 8 hours!)

Well anyway, if you want to collaborate let me know or simply come talk to me at the minijam. I'll make sure to mention the idea.
See you there!

Goldie - Inner City Life
Category: Experiments | Views: 648 | Added by: Garfunkel | Date: 2014/Feb/09 | Comments (0)

The january minijam started a bit earlier for me than usual. Christiaan wrote a comment about the growing realism of spambots on facebook, that it's becoming harder to filter them out from the real people.
At the same time electronic oversight has been expanding at an alarming rate we've never seen before.
So I thought it would be funny if that combination would lead to a future in which all that was left were social networks populated by spambots trying to sell each other crap, and them being spied upon by the SigInt (Signal Intelligence) agencies like the NSA, BND, GCHQ etc. I chose this as the theme for my game. It became kind of a complex monster so please bear with me.

How did it go from theme to game?

I scribbled down some thoughts before the jam started and read up a little on Signal Intelligence or what is called the Electronic Order of Battle. As with all of this I find it pretty scary to realize how many "secret" internets there are and what sorts of things these agencies can do. For instance, did you know webcams can be turned on remotely, providing a video feed without the typical blinking light indicating to the user they are being recorded? (info)
But I disregarded most of my reading on this and limited it to just basic internet user observation. I just wanted to express the initial idea in a videogame. In the end, the lists of actions that are undertaken are made up to fit the needs of the game, but there's definitely some truth to them.

So, I started out with a model of two parties, the sigint agencies (SIGINT) on one side and the spambot corporations (CORPs) on the other. Between them is a Wide Area Network (WAN/internet) which they use to achieve their goals.
For SIGINT the goal is to gather as much data as possible: all user profiles, names, addresses, emails, phone calls, you name it.
For CORPs the goal is to get a maximum number of pageviews, adclicks, whatever. People looking at their advertisements and buying their products.

Side effects are that they invest in the network's infrastructure. They buy more and stronger servers so they can store more user profiles. They buy more and better cables so the data throughput goes as fast as possible etc.. This grows the network slowly but surely.

At this point the game concept was basically a Real-Time Strategy (RTS) game. But those games are typically defined by direct control from the player and I thought it would be boring to go in the same direction, so both parties simply perform actions by themselves with the player having no role whatsoever. So I started to think of it more as one of those Tower Defense or Management games but where two players were playing eachother competing and cooperating to reach their goal in the fastest way possible. The "tech trees" in the game were born from this, and I also implemented a tiered structure, somewhat like how you upgrade units or towers in one of the aforementioned games.
Well, this would be nice and good by itself, but the player was not a factor at all and I did want some involvement. So I thought about that for a while and remembered the game Ogre Battle and its very laid back approach of influencing a battle.
Also there's a well-known science fiction theory that says that if you connect enough computers with eachother a spontaneous consciousness will emerge from the network, the Ghost in the shell.
Those two clicked for me and that's how the player's identity was born.

(Ogre battle, Desktop tower defense, Cookie clicker)

The player plays as a third party, the ghost in the network. Their goal is to expand the network, make it as big and complex as possible because as the network grows, so does the consciousness, more processing power, memory capabilities etc.
But the player is a ghost, a consciousness and cannot add servers or cables or do anything physical for that matter. So it's dependent on the other parties to reach it's goal. Therefore the player has to try to influence them by modifying and manipulating data: "These are NOT the user profiles you are looking for", "Pageviews were down this week, it looks like the server response times are slow". Basically the modus operandi is to frustrate either SIGINT or CORPs into investing more into the network's infrastructure.
At the start, when there are no servers and no connections at all, the player is powerless and cannot do anything. There's no network so he/she doesn't exist. But as servers get added and connections are made the player gets the abilty to start manipulating the data in places.

Lessons learned?

* Not unexpectedly I ran out of time. It's not really a positive or a negative since I knew what I was getting into and I think I cut the design down to the bone. Early on I took out the government and the actual people. Some leftovers of this can be seen in options like "Jail activists" and the presence of the government as a money source. Stuff like this was all done in the design phase so there was no waste of time. I started implementing the player's options almost immediately but then I realized that implementing a simple menu would probably take up too much time and decided to leave it as just a trigger mechanism.
10 minutes before the end and the presentations would start I added the win states for both parties. Unfortunately I never got to a win condition for the player. At this point I was making the design up as I was coding. My general thought behind it was that the size of the network can be interpreted as a highscore similar to classic arcade games like space invaders and asteroids. There is no real feedback to indicate how good the player's performance was though, which is pretty crucial to the experience.
Anyway, as a result of all the cutting and rushed development there is too little room for play and feedback for the player and that's a shame. I think the idea of a human player playing as a ghost of the network is pretty nice. It sort of reverses the typical roles of artificial and human intelligences, which makes a lot more sense to me :)

* Which also brings me to the extremely realistic simulation of human decision modelling. This was needed to show how the intelligence agencies and transglobal advertisement corporations would behave. It's Math.random(). That is: make a list of all available options, and pick one at random.
Sorry. There's no smart stuff going on. No Artificial Intelligence. No actual decision making or action valuating. There's not even any actual user data being collected or pageviews increasing or money, costs, economy going on. I did plan for it, and if you look at the code you'll see all these dummy functions in place but 8 hours go by so fast.
But, and this is the lesson, it sort of works.
Everything is extremely crude to non existant but, because there is something going on that does not expose a clear pattern it intrigues people for a short while.
So yay! for smoke and mirrors.

* The concept was a bit hard to explain. And it's a bit boring until everything is in place and influences eachother subtly and that this can also be perceived by the player. Because that is what needs to draw people in. But that was hard to reach in an 8 hour jam.
I'm not sure if I could have made it much simpler, or would have if I could. I see the minijams as 8 hours of complete experimentation where I'd rather fail at something complex or weird than go for something that I can exactly predict and doesn't move me. (Luckily I'm not very smart and easily pleased. :)

* This was the first jam that I was present and worked alone at. Which I'm totally fine with. But maybe I should have asked for help a bit more because there was so much to do.
A lot of the stuff that goes on in code behind the scenes, implementing and tweaking the subtle influences for instance, I find pretty boring once I know what it should do. I perceive them as menial tasks, so I don't want to push those on to others.
At the same time, because the design was not easy, the risk of failure was high and I wasn't sure if I wanted to drag people down with me :)

Free stuff

The source code and Haxe project are available here.

And the game can be played right here.

How to play:
* First, just sit back and observe, because there's nothing you can do at the start. There's no network for you to traipse around in, yet.
* When pink circles (servers) appear, you can click them so SIGINT will add more servers. (A menu will appear but it doesn't do anything besides show you that you clicked correctly.)
* When white lines between servers (cables) appear, you can click those so CORPs will add more user profiles to a server. (Another menu will appear but it doesn't do anything besides show you that you clicked correctly)

Unfortunately there's no option to add more cables, so you'll need to wait a little until one of the parties decides to build them. (But don't worry, they do need them to proceed.)

Fortunately you can adjust the speed of both parties.
* Down key: speed up game, shorten decision making time.
* Up key: slow down game, increase decision making time.

* If any party reaches their win condition a message is displayed. You can skip this message and continue playing by pressing the spacebar.

* Green blocks are user profiles. But I never got to the part where you can mess with them, sorry.

Category: Experiments | Views: 788 | Added by: Garfunkel | Date: 2014/Jan/11 | Comments (0)

1 2 3 »
«  October 2016  »

External sites:
Gamasutra profile
Youtube channel
Facebook page
Twitter page

Contact me: (English, Deutsch, Nederlands)
Your name *:
Your e-mail address*:
Message subject:
Message text *:
Security code *: