Human Nature Through the Lens of The Binding of Isaac’s Game Mechanics (By Jonathan Kittaka)
Posted: May 18, 2013 Filed under: Uncategorized | Tags: binding of isaac, essay, game design, game mechanics, Jonathan Kittaka 1 Comment »By Jonathan Kittaka – (Artist, Writer, etc for Anodyne)
Note: this essay was written in an academic setting, so it’s in a slightly different tone than I would use for an average article or blog post. It also is written assuming that the reader may have little to no background in video games.
Humans are programmed to search for patterns and to find confirmation for their feelings and beliefs. These quirks and biases come out strongly in the face of the randomized and mysterious events in Isaac. For instance, on each floor, there is an item room containing a single item that grants new abilities or changes the players stats (movement speed, damage done to enemies, attack range, etc). Naturally, some items are much better than other items, and this can have a dramatic effect on the player’s perception of how frequently they appear. Across many runs, a powerful and coveted item may seem extremely rare, while an item you hate is exceedingly common. In reality, Edmund has confirmed that the items found in item rooms are “literally random” and not weighted to bad items over good items (McMillen, Formspring). One explanation for this phenomenon may be that the player frequently hopes for the good items, thus noticing every single time they don’t appear. All of these small disappointments add up to create the illusion of the rarity of the desired item. Even regardless of “good” items versus “bad” items, random chance sometimes leads to a player getting some items more frequently than others. It’s hard for a player not to desire some sort of meaning in the distribution; players will ask Edmund about this on Formspring, making statements like, “I’ve seen harlequin baby and chocolate milk in almost every run I’ve done over the past month, and things like stigmata and mom’s eye haven’t shown up since may” (McMillen, Formspring).
The strange psychological effects of The Binding of Isaac become even more apparent while watching someone else play and describe their thought process throughout. “Let’s Play” (LP) videos on YouTube and other sites provide that exact opportunity. Northernlion, a popular Let’s Player who uploads Isaac runs every day to YouTube, makes frequent commentary on the item combinations and character of the runs he’s been having, creating a narrative across runs out of an essentially random series of events (Letourneau). Perhaps even more interesting is the way he personifies the randomly generated aspects of the game, frequently thanking or cursing “The Troll Engine” for the items and enemies encountered throughout the game. For instance, if a single key could spell the difference between life and death, and a key is trapped across a chasm, Northernlion might say that the Troll Engine is messing with him. Of course, rationally speaking, Northernlion is not convinced that there is a real personality behind the random events in the game. Nonetheless, when facing a particularly unique, ironic, or unfortunate outcome, it is easy to feel—on some gut level—as if someone is pulling the strings.
Notably, not every situation in Isaac is up to pure chance. For instance, some items and statistics can change how often you receive money, keys, and other items. Some playable characters have secret stats that make them more likely to find certain items. In other words, sometimes correlation is due to causation. Experientially, this is true to life—there are factors that affect every situation that are not obvious or explicit but are also more relevant than random chance. The presence of these factors only serves to encourage speculation about hidden effects that other items or characters might have; the fact that the odds occasionally do change feeds directly into hypotheses that can essentially function like superstitions.
All of these facets of Isaac’s design serve to highlight the strange ways that humans tend to deal with information and events in our own reality. In particular, Isaac serves as a potent exploration of religious belief. In many cases, religious experiences are comprised of sequences of events that simply seem too meaningful to be random. Similar experiences can occur in Isaac through verifiably random incidents. However, Isaac’s structure does not lend itself to simply condemning religion as pointless superstition. The sense of wonder engendered by engaging with the mystery of the game’s mechanics is one of the main reasons to play the game at all. Ascribing a god- or fate-like persona to the game’s random generation is an intensely human response, and allows the game to have an emotional and personal relevance. And beliefs about the game’s mechanics—whether true or not—can change the decisions that the player makes, for better or for worse.
Why Nintendo’s LP Crackdown might make business sense
Posted: May 16, 2013 Filed under: business | Tags: business, nintendo 1 Comment »On my first hunch, Nintendo banning monetization intuitively seems like it is a bad marketing idea, and others feel the same, too – You generate negative PR, at least in some social circles, some people don’t see your game, and the general consensus is they lose sales. It’s suicide to do this as a small development group.
But Nintendo is a very large company. So things are a little different from their scale – why might they be doing this? Our emotional and kneejerk response is that they are losing out on tons of sales by snubbing the Youtube community – but, perhaps they’re not?
Let’s try to reason out from their point of view for a bit…
My guess is that:
Nintendo wants to discourage LPs of their game that are being monetized, not so Nintendo can get the money which is relatively pocket change for them, but so audiences will be driven to seek out other outlets that focus on previews – traditional reviews on websites, quick previews outside of Youtube – ones which give a quick taste of the game and a recommendation, but not enough in the way of a traditional demo.
The idea might be that they think, or have some data that suggests that LPs reduce sales in an analogous fashion to demos, i.e., people will tend to watch the videos, then decide they’ve seen enough, and not buy the game. This seems feasible enough to me, as I’ve heard that that for large companies, demos tend to hurt sales – large companies have large enough advertising budgets to not really need word of mouth and demos.
It’s just one idea, and whether or not it’s true, it’s important to remember the inherent differences in business operations between , Jon and I, and Nintendo, whenever we reason about one entity’s decision. The “game” of profiting between me and them are worlds apart.
The word of mouth from demos and LPs? Those might not matter when you have the budget to front page magazines, websites, and mail catalogs from the largest retail chains in the world. With that much advertising money,you might actually *gain* sales by lowering the number of LP videos, even though that would be an idiotic move for a small team. Remember, while Nintendo might be in it for making fun games, they’re still primarily in it for being a profitable business. Thus while they might snub the Youtube community, they don’t care, as long as it increases profits.
Am I pissed off? Certainly, I know a few people who make money off of the LPs. But before we label Nintendo as “stupid”, let’s remember that their means for existence are far different from that of smaller groups. If the data shows the right trends (which we don’t know), then Nintendo’s move can make sense from their standpoint.
anodyne by the lines of code
Posted: May 4, 2013 Filed under: actionscript3, Anodyne, game programming | Tags: Anodyne, code, programming, stats Leave a comment »| Hey everyone! This isn’t quite a source code release (that won’t be for a while), but I recently had to send off the source code for a review (anodyne might be ported to 3DS!) so I thought it might be interesting to post these stats. line counts via cloc.exe. At least, I’m very interested in other peoples’ game structures myself, so I’d like to see more posts like this!This count is only what I had to write myself, it doesn’t include the flixel library (I made a few modifications to it but they are mostly minor). Doesn’t include CSV (level data), XML (entity data), or dialogue, extensions (steam code, controller extensions)And of course, doesn’t include the music, sound effects, TONS of tilesets and images, level data we created!
What is here is the names of AS3 source files (and some lua/python) If you have any question on what the files do, feel free to ask here or ask me on Twitter! Below I included a quick overview of the files. We used Git as version control. About 1,100 commits over the April 2012-March 2013 period, though I did a little work in March 2012. One dayI’ll post the commit logs -sean hogan
|
, sorted by code size. About 36k LoC in all for these files. I would say most of it comes from bad style – I hard code a lot of song/tileset data, the enemies are mostly things that probably could have been scripted in some way,e tc.| File | blank | comment | code |
| —————————————– | ————————————- | 2980 | 35953 |
| src\states\PauseState.as | 206 | 56 | 1591 |
| src\states\PlayState.as | 276 | 225 | 1542 |
| src\entity\player\Player.as | 207 | 87 | 1310 |
| src\entity\interactive\NPC.as | 116 | 53 | 1260 |
| src\Intra.as | 235 | 169 | 1144 |
| src\data\TileData.as | 65 | 56 | 1121 |
| src\entity\enemy\etc\Briar_Boss.as | 142 | 71 | 1052 |
| src\entity\enemy\circus\Circus_Folks.as | 101 | 42 | 862 |
| src\entity\interactive\npc\Mitra.as | 89 | 32 | 784 |
| src\states\TitleState.as | 141 | 38 | 741 |
| src\entity\enemy\crowd\WallBoss.as | 105 | 65 | 728 |
| src\entity\enemy\redcave\Red_Boss.as | 115 | 38 | 700 |
| src\entity\enemy\etc\Sage_Boss.as | 116 | 85 | 680 |
| src\entity\interactive\npc\Trade_NPC.as | 93 | 22 | 673 |
| src\entity\interactive\npc\Sage.as | 75 | 46 | 654 |
| src\data\SoundData.as | 167 | 56 | 634 |
| src\entity\enemy\hotel\Eye_Boss.as | 112 | 32 | 609 |
| src\entity\enemy\apartment\Splitboss.as | 65 | 15 | 575 |
| src\entity\gadget\Door.as | 95 | 69 | 573 |
| src\states\EndingState.as | 56 | 30 | 567 |
| src\global\Registry.as | 89 | 101 | 566 |
| src\entity\enemy\bedroom\Sun_Guy.as | 74 | 37 | 526 |
| src\helper\SpriteFactory.as | 25 | 19 | 496 |
| src\entity\enemy\circus\Lion.as | 61 | 14 | 468 |
| src\states\RoamState.as | 116 | 41 | 458 |
| src\helper\Cutscene.as | 50 | 19 | 400 |
| src\global\Keys.as | 53 | 21 | 373 |
| src\entity\gadget\KeyBlock.as | 39 | 17 | 368 |
| src\helper\EventScripts.as | 68 | 119 | 358 |
| src\entity\enemy\redcave\Slasher.as | 63 | 40 | 347 |
| src\entity\gadget\Treasure.as | 40 | 6 | 343 |
| src\entity\interactive\npc\Shadow_Briar.a | s 42 | 103 | 329 |
| src\helper\DH.as | 81 | 101 | 327 |
| src\states\DialogueState.as | 51 | 34 | 316 |
| src\entity\enemy\bedroom\Slime.as | 40 | 13 | 304 |
| src\Save.as | 47 | 53 | 285 |
| src\entity\player\Broom.as | 44 | 18 | 277 |
| src\entity\enemy\bedroom\Annoyer.as | 52 | 9 | 265 |
| src\entity\enemy\suburb\Suburb_Walker.as | 35 | 3 | 265 |
| src\entity\enemy\crowd\Frog.as | 43 | 12 | 256 |
| src\entity\interactive\Health_Cicada.as | 24 | 5 | 253 |
| src\entity\gadget\Propelled.as | 37 | 19 | 252 |
| src\entity\enemy\apartment\Dash_Trap.as | 34 | 9 | 245 |
| src\entity\gadget\Big_Door.as | 33 | 23 | 243 |
| src\entity\enemy\crowd\Spike_Roller.as | 35 | 10 | 241 |
| src\helper\Joypad_Config_Group.as | 42 | 5 | 237 |
| src\entity\gadget\Console.as | 37 | 6 | 237 |
| src\entity\gadget\Checkpoint.as | 34 | 19 | 237 |
| src\entity\enemy\circus\Contort.as | 48 | 13 | 236 |
| src\helper\Achievements.as | 50 | 25 | 236 |
| src\data\CSV_Data.as | 48 | 42 | 232 |
| src\entity\enemy\apartment\Silverfish.as | 43 | 15 | 226 |
| src\entity\player\Foot_Overlay.as | 31 | 11 | 226 |
| src\entity\enemy\crowd\Dog.as | 39 | 18 | 220 |
| src\entity\enemy\etc\ControlsDeity.as | 17 | 6 | 190 |
| src\entity\enemy\bedroom\Shieldy.as | 24 | 9 | 185 |
| src\entity\player\Transformer.as | 44 | 18 | 182 |
| src\states\ControlsState.as | 21 | 4 | 181 |
| src\states\MinimapState.as | 45 | 14 | 180 |
| src\entity\enemy\hotel\Burst_Plant.as | 31 | 6 | 177 |
| src\entity\interactive\npc\Happy_NPC.as | 17 | 5 | 177 |
| src\entity\enemy\redcave\On_Off_Laser.as | 20 | 15 | 174 |
| src\entity\enemy\apartment\Teleguy.as | 28 | 15 | 172 |
| src\entity\enemy\apartment\Rat.as | 33 | 11 | 171 |
| src\entity\enemy\hotel\Steam_Pipe.as | 28 | 11 | 170 |
| src\entity\enemy\etc\Chaser.as | 24 | 3 | 168 |
| src\entity\enemy\redcave\Four_Shooter.as | 20 | 6 | 165 |
| src\entity\decoration\Light.as | 18 | 22 | 163 |
| src\entity\interactive\Elevator.as | 45 | 12 | 160 |
| src\entity\enemy\apartment\Gasguy.as | 41 | 7 | 156 |
| src\entity\decoration\Water_Anim.as | 40 | 11 | 150 |
| src\entity\enemy\bedroom\Pew_Laser.as | 30 | 15 | 149 |
| src\entity\decoration\Solid_Sprite.as | 13 | 16 | 149 |
| src\entity\interactive\Black_Thing.as | 41 | 11 | 148 |
| src\helper\ScreenFade.as | 19 | 9 | 147 |
| src\entity\gadget\Gate.as | 20 | 46 | 147 |
| src\entity\enemy\crowd\Person.as | 23 | 12 | 140 |
| src\entity\interactive\npc\Forest_NPC.as | 11 | 4 | 137 |
| src\entity\enemy\hotel\Dustmaid.as | 21 | 7 | 135 |
| src\entity\gadget\Dust.as | 25 | 15 | 132 |
| src\entity\gadget\SinglePushBlock.as | 17 | 5 | 132 |
| src\entity\interactive\npc\Space_NPC.as | 13 | 4 | 121 |
| src\entity\interactive\Red_Pillar.as | 24 | 7 | 116 |
| src\data\gen_npc.py | 16 | 17 | 113 |
| src\entity\gadget\Jump_Trigger.as | 20 | 5 | 111 |
| src\entity\enemy\circus\Fire_Pillar.as | 17 | 0 | 109 |
| src\states\IntroScene.as | 17 | 4 | 103 |
| src\entity\player\Miniminimap.as | 21 | 19 | 101 |
| src\entity\player\HealthBar.as | 17 | 13 | 94 |
| src\entity\interactive\npc\Redsea_NPC.as | 13 | 6 | 93 |
| src\entity\enemy\redcave\Mover.as | 21 | 12 | 90 |
| src\entity\gadget\Button.as | 17 | 4 | 90 |
| src\helper\S_NPC.as | 17 | 24 | 87 |
| src\Main.as | 17 | 11 | 87 |
| src\entity\gadget\Go_Detector.as | 28 | 0 | 86 |
| src\entity\player\HealthPickup.as | 8 | 11 | 80 |
| src\entity\enemy\etc\Follower_Bro.as | 6 | 4 | 76 |
| src\entity\enemy\etc\Wall_Laser.as | 9 | 4 | 76 |
| src\entity\interactive\Dungeon_Statue.as | 11 | 4 | 75 |
| src\entity\decoration\RetroEffect.as | 21 | 39 | 71 |
| src\entity\interactive\Fisherman.as | 8 | 4 | 71 |
| src\entity\gadget\Switch_Pillar.as | 13 | 4 | 66 |
| src\entity\gadget\Dash_Pad.as | 21 | 0 | 65 |
| src\entity\enemy\suburb\Suburb_Killer.as | 19 | 0 | 64 |
| src\data\CLASS_ID.as | 7 | 14 | 62 |
| src\entity\gadget\Pillar_Switch.as | 18 | 4 | 61 |
| src\helper\Parabola_Thing.as | 17 | 31 | 60 |
| src\entity\interactive\Terminal_Gate.as | 19 | 6 | 60 |
| src\lua\Intra.lua | 26 | 11 | 56 |
| src\entity\enemy\crowd\Rotator.as | 16 | 9 | 56 |
| src\entity\enemy\etc\Sadbro.as | 11 | 10 | 55 |
| src\entity\gadget\CrackedTile.as | 9 | 4 | 53 |
| src\data\Common_Sprites.as | 10 | 6 | 52 |
| src\entity\enemy\etc\Red_Walker.as | 12 | 4 | 49 |
| src\states\FillerTitleState.as | 3 | 6 | 48 |
| src\entity\enemy\etc\Space_Face.as | 20 | 3 | 47 |
| src\entity\gadget\Key.as | 8 | 4 | 46 |
| src\entity\gadget\Hole.as | 6 | 4 | 45 |
| src\entity\gadget\Growth_Gate.as | 8 | 7 | 45 |
| src\entity\gadget\Challenge_Gate.as | 12 | 6 | 42 |
| src\entity\decoration\Nonsolid.as | 8 | 6 | 36 |
| src\entity\decoration\Map_Preview.as | 6 | 4 | 31 |
| src\entity\gadget\Stop_Marker.as | 7 | 4 | 31 |
| src\states\PushableFlxState.as | 7 | 10 | 30 |
| src\entity\decoration\Eye_Light.as | 6 | 4 | 27 |
| src\lua\csvTilemap.lua | 15 | 5 | 25 |
| src\entity\interactive\npc\Huge_Fucking_S | tag.as 6 | 4 | 24 |
| src\data\demo_xml_clean.py | 4 | 0 | 23 |
| src\data\remove_dialogue_for_demo.py | 6 | 6 | 19 |
| src\Preloader.as | 3 | 4 | 16 |
| src\helper\SteamThing.as | 3 | 4 | 11 |
| src\lua\csvTilemap_settings.lua | 2 | 1 | 4 |
| src\lua\Intra_settings.lua | 2 | 1 | 4 |
| src\data\make_demo_npc_data.bat | 0 | 0 | 3 |
| src\data\make_npc_data.bat | 0 | 0 | 2 |
Inside of Intra/src
ca – MAc joystick extension code
com – Steamworks code for mac/win
csv – Tilemap data
data -
CLASS_ID.as – used for id’ing some classes, stopped using it halfway through dev but it’s still in some of the entity code
Common_Sprites.as – Embed code for overlays, backgrounds
CSV_Data.as – Embed code for CSVs, also for picking out what CSV should load in an area
NPC_Data.as – The AS3 object format of npc data with state:
SoundData.as – Handles embedding SFX, music, has some helper functions for that, also code for choosing what song plays in an area
TileData.as – Embeds the tilemap files, also has functions for tile callbacks (spikes, etc), setting bindngs (what is solid, etc), picking what tilemap to use in a map, data on animated tiles
dialogue.py – Raw dialogue stuff
gen_npc.py – turns dialogue.py into NPC_Data.as
entity – Not counting the player folder, these are source files for things you can place with the level editor (usually) – signs, rocks, NPCs, enemies, dungeon elements. mostly straightforward
extension – Joypad code for windows
global – Input handler (Keys.as) and the registry.as (global state variable). Holds a lot of random constants and state about the game. Also contains code for loading and parsing the XML
helper – Random things,
DH.as handles back-endy dialogue stuff,
Cutscene.as does some stuff for cutscenes,
EventScripts.as is helper functions,
Joypad_Config_Group.as – the joypad configuration at start of game,
Parabola_thing.as – interpolation for bullet arcs (usually),
S_NPC.as – helper functions for NPCs whose state change throughout the game,
ScreenFade.as – the downsampling effect when moving between areas,
SpriteFactory.as – called for each xml element, generates an entity
lua – Has the lua exporter, Intra.lua, for DAME (map editor)
mochi – random code for mochi ads in this online demo version
obj – ??
org – flixel code . modifications were made in parts
res – image assets. all .png
states – play states (more or less groups of objects)
ControlsState: Set keyboard controls
DialogueState: DIsplaying of dialogue
EndingState – The credits
FillerTitleState – not used
IntroScene – The “wake up!” thing int he beginning
MinimapState – The minimap in the map section of the menu
PauseState – Pause menu
PlayState – All of the overworld/dungeon screens
PushableFlxState – some unncessary abstraction I made
RoamState – not used
TitleState – title screen
xml – Intra.xml, the entity data.
Intra.as – Game loop, mostly related to resizing windows and choosing where the game starts, debug flags, different build flags, mobile GUI
Main.as – handles initalizing extensions, starting game
Preloader.as – I don’t think i use this
Save.as – Handles saving the game to the .sol file
Discussion of Game Dev Tycoon’s DRM. And the game. And piracy.
Posted: May 1, 2013 Filed under: piracy | Tags: Discussion, Game Dev Tycoon, piracy, Review 4 Comments »I want to talk a bit about piracy. (Again.)
Game Dev Tycoon, released recently, has an interesting DRM strategy with regards to piracy – playing the pirated copy will make you lose after a while, because too many people pirate your game, and you go bankrupt.
(I will note this has really done wonders, press-wise for them. Not going into whether this was a marketing stunt (I don’t think it was, for the record – their blog post comes off as this DRM was more of an emotional response))
This strategy roughly says, as conveyed through the gameplay: “Piracy hurts sales and doesn’t let us make any money, and makes us go bankrupt”. It’s a bit harsh, especially since it makes you prematurely lose the game, so hours spent might go down the drain.
It’s sort of clever how the DRM is implemented, but the lesson being taught isn’t entirely accurate – piracy might hurt sales, but it doesn’t guarantee bankruptcy in all cases – hurt profits in larger studios, possibly.
Here’s one negative. When you do this, you are shutting off anyone playing the pirated copy from playing your game. In this group of people, there exist people who don’t have the money to buy the game, simply want to try before buying (And won’t buy otherwise), and people who just never pay – with some overlap between the groups.
You’re genuinely pissing off the former and latter party, which are possible fans. In my experience, some people didn’t have the money to pay at the time, but later paid. Or they told their friends to buy it.
I suppose it’s a VERY strong way of conveying the feeling of getting pirated – by playing the pirated version, you can never reach the goal of making enough money to stay alive. But it’s not entirely accurate. Other studios and I have had benefits from piracy, you don’t necessarily go bankrupt with piracy. Most pirates probably weren’t going to buy it anyways. But some of them would have!
And this is why I’m so mixed on this. The party of people who pirate and don’t think about it – maybe you’re teaching them something, it’s hard to say. But that’s at the cost of negatively affecting people who can’t afford, and people who were trying before buying.
I wonder if this lesson could have been taught more gently, without cutting off anyone playing the pirated version from finishing the game. But, that would have reduced the impact on the party who are “the problem” of piracy – people just pirating even though they can afford the game.
So…hmm. I suppose that, in the grand scheme, maybe this experiment was a good idea. In the short run, it hurts some of the studio’s fanbase. It’s sort of a not-entirely-true “lesson” being taught, and is a bit unfair for people losing their time. BUT, where the real win is, is that it does plant the idea of “hey, maybe I should pay for this” in the minds of the people who won’t pay for it, even if they can. Even if that’s conveyed through a message that is not true – that is a bit of empathy towards game developers, the sinking feeling of not making any money off of something you worked hard on. (Even if, again, Game Dev Tycoon itself isn’t very realistic about this)
But, that’s only part of the battle in reducing piracy in people who don’t need to pirate to play games – I think the other part also lies in increasing players’ empathy towards developers. Showing the human side of development, etc, which I think over time can make people think twice before pirating a game and never paying for it (if they can!) . At the same time, this also includes REALIZING that pirates can sometimes be people who can’t afford the game. It’s not just a group of evil, middle-upper class kids who will steal at every opportunity!
————
(Oh, and yes, I’ve purchased the game. It’s good at conveying the complexity of scaling up a game company, the issues inherent with taking risks with IPs, having tough publisher experiences, the nervousness of release…and I think that gameplay itself can foster some empathy towards developers.)
For your amusement, here is “Andoyne” not doing well in Game Dev Tycoon 
Mini Anodyne-postmortem, by the commits
Posted: April 27, 2013 Filed under: Anodyne, game development, game programming | Tags: Anodyne, commits, game development, workflow Leave a comment »In Anodyne, we used Git+Github for version control (backing up work, sharing a codebase between multiple people). This is a graph of my “commits” – or changes to the codebase/assets, from May 2012 onwards, though work on Anodyne started in March 2012 and mostly ended in March 2013. I think it might stand as an example of how deadlines can be useful (school terms starting, IGF, etc)
I just realized, that the beginning few weeks of block “7″ were actually me preparing Anodyne for standalone-distributions (on Steam, for example). The latter half is mostly work on new game.
Some nice games #1
Posted: April 18, 2013 Filed under: games | Tags: bonfire, cool games, games, risk of rain, roguelike Leave a comment »Here’s my attempt at spreading the word about games.
Bonfire (By MoaCube, Windows/Mac, Demo available, purchasable alpha)
Check it out here:
http://forums.tigsource.com/index.php?topic=27800.0
Bonfire is a game that boils down the strategy and leveling up from many a turn based RPG into a very tight loop – essentially, taking the drudgery of dungeon crawling away and keeping only the turn-based battles which must be carefully planned, lest you die – which you will :) – but without the time commitment of having wandered some dungeon for a long time! This is a good thing.
You play through quests, which are rounds of battles, gain gold, which if you lose a quest (and you will), can be used to increase some stats on your characters. I have only played a few rounds so far, but this seems like a great game if you were a fan of strategizing in many turn-based RPGs.
Risk of Rain
Demo and kickstarter: http://www.kickstarter.com/projects/riskofrain/risk-of-rain
An action platformer with roguelike tendencies. Pick a character, and use its four skills to get through pre-designed levels with randomly placed treasures. Activate teleporter and defeat a boss to reach the next stage, level up and gain skills as you go along – but if you die, start over! (Though you can unlock items that will appear in future rounds).
It’s not finished, but looking to be pretty good once they do finish the game and add more areas. There’s a bit of strategy in initially surviving, but finding the right set of items still lets you brute force your way for a while until the difficulty level gets too high (oh yeah, the difficulty of enemies rise as you play further on…). That’s only a minor balance issue, though, and possibly only with the character I used. Or I just got really lucky. In any case, it is worth your time!
OH yeah, and Chris Christodoulou, who did the music for the Kyratzes’ The Sea Will Claim Everything, is doing the music! That is definitely a plus.
On a weird side note, I got very Maple Story vibes from the combat. That game and I go embarrassingly far back, so that appealed to me. It was like the good game-mechanic parts of maple story, though!
Pixels in the Present (By Jonathan Kittaka)
Posted: April 16, 2013 Filed under: Uncategorized | Tags: Anodyne, art, game development, Jonathan Kittaka, pixel art 2 Comments »Pixels in the Present (By Jonathan Kittaka, originally appearing in Russian Igromania video game magazine)
The rise of independent games over the past few years has brought with it a resurgence of pixel art and other visual styles in the vein of games past. For the purposes of this article, I’ll focus on pixel art, specifically (I made the pixel art graphics for the game Anodyne, which recently released on Steam, so I have been thinking a lot about these issues recently). The visuals of early games were born out of hardware limitations that no longer apply to modern gaming platforms, and this has led some people to question the place and purpose of these retro-influenced graphics in games today. Some argue that this nostalgic focus holds back the visual potential of video games. By holding tightly to such a characteristic visual style, developers stagnate and limit their potential audience to people who already appreciate pixels. I think that these concerns are legitimate and interesting, but that they overlook the virtues and opportunities that pixel art offers. I believe that there are still lessons to be learned from pixels, and that, if nothing else, the accessibility of working with pixel art makes it still a valuable tool for each new generation of game developers.
Recently, there have been many games receiving HD remakes that keep the game’s mechanics but update the visual style to a convey a greater level of detail and visual information. I don’t think this is a bad practice, but I do sometimes question the idea that any and every game would be better with modern graphics. Simplification and the reduction of visual information can have a profound effect on the experience of a game. When visual details are withheld, there is room for the player’s mind to fill in the gaps and bring the world to life. Activating a player’s imagination is a powerful tool in immersion; a great example of this is the story-focused game To the Moon. The modest pixel art in To the Moon allows for a great degree of emotional weight to be carried by the smallest gestures. For example, the character River has a characteristic way of averting her eyes–a change of one or two pixels–which becomes a subtle but powerful link to her character across the different time periods in the game.
Another advantage that I have found in some older games is the tight connection between gameplay and visuals that is afforded by their stark imagery. For example, Zelda II, a NES game with very simple graphics, features some of the most dynamic swordplay of any game I have ever played. Many 3d games have combat based on button-mashing, lock-on targeting, buttons to automatically block attacks, or quick time events; the complexity of the visuals in these games prevents you from being able to receive the combat information fast enough to react, so games must automate these features in order to convey an exciting battle. In Zelda II, however, you are in complete control of your character–every parry, every swing, every hit happens very precisely based on your input. This is possibly in part due to the simplicity and abstraction of the graphical style, which allows the action onscreen to be surprisingly quick and subtle. I’m not saying that everyone should or would necessarily enjoy Zelda II more than a modern action game, but I do believe that its visuals contribute to a very unique gameplay experience that has the potential to be extremely rewarding.
Now, even though these successful design elements that I’m describing occur in games with pixel art, it doesn’t mean that the pixels themselves are necessary to achieve these effects. However, I believe that we still have so much to learn about what makes games good, and that it’s worthwhile to keep looking back as well as forward throughout this learning process.
I am uncertain of the future of pixels in my own work and among game development in general. I grew up thinking about and working with pixels, and I’m very attached to the process. To me, pixels are simply a part of life. At the same time, I understand that a lot of people aren’t really able to look past pixel art, especially if they didn’t grow up playing video games; to some, pixels are signposts to a subculture where they feel they don’t belong.
Whatever happens, I believe that pixel art will continue to have a place in game development for quite some time. At the very least, the relative simplicity and efficiency of pixel art helps to open up game development to a wide community of people. Pixel art doesn’t require any expensive software or physical materials, and it’s more forgiving than hi-res or 3d rendered graphics in terms of performance issues. In the right circumstances, pixels can serve as a portal to an incredible universe of creativity, opening up the form of video games to a wider pool of people with new and interesting ideas.
Follow Jonathan on Twitter, and make sure to check out development of Jon and Sean’s next game over at TIGSource!
