For the last couple of weeks, I’ve been citing an offhand comment some eyeo presenter made about the importance of experiencing “awe” regularly in your life. After getting over that slight discomfort I always feel when citing sources whose sources I absolutely don’t know, I’ve been finding it an easy justification for all kinds of actions and decisions I make.
So I did some googling. This interesting slate article by an “emotion scientist” suggests that the state of awe provokes thoughtful reflection and skepticism. This makes sense to me because I think one thing I find so appealing about “awe” are the big ideas. And big ideas give you perspective. If I’m contemplating the nature of the cosmos, that bug I’ve been working on for the last few hours seems rather less important. (Which I’d argue often helps to solve it, but that’s another blog post.)
This Atlantic article cites a Stanford study published in 2012 whose title says it all: “Awe Expands People’s Perception of Time, Alters Decision Making, and Enhances Well-Being” This huffpost piece cites a paper written in 2013 with another telling title: “Approaching Awe, A Moral, Spiritual And Aesthetic Emotion.”
This quest for awe is absolutely why I made it a priority to go to eyeo festival this year. It’s why I went to Northern Spark last night, and stayed up ridiculously late looking at art. The eyeo presenter that I quoted said it’s why we go to museums. Finding awe is often what drives my decisions around what to work on when I have spare time, and what to spend my recharge time doing in my evenings and off hours. Now I just need to figure out how to trigger it with the games I make.
I had a strange idea this morning. “What if every time you moved a piece in a game, you were also moving one of your opponent’s pieces?” I don’t know of any other games that have this same mechanic. I present for you here, a very simple abstract small-grid game I’m calling Entanglement.
Edit: A bit more details about how this came about and playtesting (over lunch) with my friend Nate. Usually when I have an idea for a new game, I enter some minor details in a google-doc/journal I keep for that purpose. I make sure to record the date, and what I was doing when I came up with the idea. In this case, it was such a simple idea, the game came to me practically fully formed, and I went straight to a new file to write out the rules. I jotted them down in about 20 minutes, and got back to work. Then over lunch I played the game a couple of times with Nate, and immediately it felt too complicated. (Which felt weird, because it was already SO simple!) So then I revised, and we played a few more games (without the variant rules listed in the .pdf).
Overall, I don’t think this is one of my better games, it feels likely to be “solvable”, but it has some interesting decisions to make, and I was quite happy with my 10-minute prototype. If you play it, please let me know!
I was recently asked by a friend my opinion about how often is too often to notify the player that it is their turn to play. I personally feel a player should not get more than two or three reminders total. I also feel like email notifications should be opt-in. (Push notifications are already, at least on iOS, but collecting an email at registration should not be license to send email turn notifications, IMO.)
I’m not sure if there are other options other than email and Push. It might be interesting to try an experiment where you make turn notifications tweets. I wonder if there are already any asynchronous games playable entirely on twitter.
So, sending a notification immediately when it becomes the player’s turn is a must. I also believe it’s a “best practice” to time out your games, and send a notification before that happens. I know I’ve seen other devs (who host their own games) post about how not having async games time-out also means there are thousands of abandoned games on their server that will essentially never go away. So when this notice is sent could be based on the time-out period, maybe when the game would auto-boot them in another 24 hours.
What Playdek has done is to allow the user who creates the game to specify a length of time for the game. This works like a chess clock, and the timer starts when you get the notification that your opponent has played their turn. (The options are 10 min, 30 min, 1 hr, 2 hrs, 1 day, 3 days, 7 days, 14 days, and 28 days.) They only send one push notification when it becomes your turn. If the game times-out, you only find out after you log in again.
That solution actually feels a bit overly complicated to me, and I’ve recently started playing Star Realms, which has a similar but slightly simplified scheme where you choose a “time per turn” limit when starting a game. (The options are 3 minutes, or 48 hours.) With the 48 hour turn limit, you get a notification twice, once when it’s your turn, and another when you have 24 hours left to play. (They don’t badge the app when you’ve got pending turns though, which is just PAINFUL.)
For Catchup, I’m using the simplest possible implementation of GameCenter, which is not to have timers at all. (Timers were only introduced in a later version of the API anyway, and I wanted to support versions of iOS farther back than that.) The way their push notifications for async games work is super opaque, (and they come from the GameCenter app, not your app, which is also annoying), and one of the biggest limitations of using GameCenter, in my opinion.
One other thing I have seen, (but don’t necessarily endorse), is the ability for the user to nag the player whose turn it is. I can’t remember what app it was that did this, (maybe Trivia Crack?), but there was essentially a button that you could press in the app to send a notification to the other player.
I certainly don’t know what the best choices are, but I do know that there are different categories of asynchronous player with very strong opinions about how to play. For instance, vocal proponents of short timers who only want to play games that last less than an hour or so. Whereas I personally prefer to play games with the maximum timer limit, because, for me at least, I tend to batch all my asynchronous game play in one or two sessions a day. (And some days I skip entirely!) So player choice seems important.
Yesterday I had the opportunity to play with Parse for the first time. (Essentially migrated a project from using Google Analytics to Parse objects in a day.) I never knew it was so easy, and I have to admit that now I sort of want to use it for an asynchronous game. We’ll see.
It’s been a while since I’ve posted any Tetris stuff on here, and I ran into some interesting hardware implementations today that reminded me I hadn’t posted about L3D Tetris yet. So…
Last week at the bar after our monthly igdatc meeting, I was showing off the L3D, and took this vine of CubeTube user hape’s L3D Tetris. (Shortly thereafter, the official CubeTube youtube channel also posted a much better/longer video of it in action.)
Frankly, this existing was a load off, since I had already said I was going to write Tetris for the L3D. Now that I don’t have to, I’m focusing on some more original game designs. I should have one I’m calling Match-L3D playable later today. (Though I’ve been saying that for a few days, and I spent most of this morning cleaning up code I wrote last night when it was too late for me to have been realistically coding.)
My impression of actually playing it was basically that there are far more satisfying 3D tetris implementations, unfortunately. It’s just plain HARD, and can be really difficult to “line up” the pieces, especially the farther into the cube you’re looking. The L3D has a pretty serious problem with reflections off the plexiglass, and that didn’t really help with the playability either.
Over at the HackADay blog, they posted yesterday about user Alex’s Arduino Tetris on an LED Array. That one was pretty plain looking, (not to diminish Alex’s efforts, I’m sure he learned a lot putting the project together!) That post links to a previously posted project (shown above) called Breadboard Tetris, as well as another running on an oscilloscope. But their blog is actually a cornucopia of LED Tetris links! Many more are findable by searching their website, including Tetris wearables, like this LED tie, and a sweet looking arduino bracelet.
If you want to build your own LED Tetris, there is an instructable you can follow, (although comments imply it’s incomplete, so maybe you’ll have better luck with this other one). Anyway, hardware hacking is getting easier and easier all the time.
Many of these projects post their Tetris code, and it would be a fun exercise (though not one I’m about to undertake just now) analyziing how they all go about implementing the various challenges inherent in writing Tetris. (Piece rotation would probably be the most interesting to analyze, although 2D grid storage would also be worth comparing and contrasting.)
I’ll leave you with this custom LED Tetris project next to an inflatable dinosaur. It’s a tossup which one is a bigger waste of space. At least you can deflate the dino. ;)
2014 was the first year I spent almost entirely working on games. (One or two freelance projects didn’t qualify, but the majority of them were games, which is very exciting!)
As usual, I tried to split my time about 50/50 between freelance work and product development. I spent a lot of that product development time in 2014 working on Catchup. And, as expected, I still spent the majority of my time this year in Xcode, working on iOS apps. iOS is definitely the platform that it is still easiest for me to prototype in, simply because I am most familiar with it, and to some extent because I can re-use code from previous projects. I think I did less iOS prototyping this year than in previous years, but there are still a few new projects sitting around that I would love to give more attention to (and release) in 2015.
But the point of this article is that I also spent a lot of time thinking about different platforms. And when I started thinking back on this, I realized there were a lot of them. So here is a rough list:
- Unity – I’d “played around” with Unity before, but early in 2014 I spent a weekend at the Global Game Jam working with a rather large team on several games in Unity. Since I was such a newb, I ended up just playing pinch-hitter, helping out where I could, and in general learning as much as I could from the other more experienced Jammers. I left the game jam feeling like I could code a Unity game from scratch if I had to, which was far more skill than I’d had when I started.
- PuzzleScript – In the middle of the summer sometime, a few of us at #Doughvelopment (game dev co-working on Fridays from a donut shop) started playing with PuzzleScript. Mostly this was Ian’s fault, but several of us ended up working on PuzzleScript games. I was intrigued mostly because PuzzleScript is a language written to encode a particular type of game (box pushers in the Sokoban family) as simply and flexibly as possible. I got a couple of levels into a pretty derivative design before abandoning it, (in PuzzleScript it takes a lot of extra effort to be original, I think), but I spent at least a day working in the web-based editor, which is just very different from most of the coding I’ve ever done before.
- Board Game Development – I’ve designed a lot of board games over the years… but very few of them have had the sort of iteration usually associated with a polished (or better yet published) game design. Board Game Development is the process of playing and testing your design, then iterating on the rules (or as in my case, specific cards), playtesting again, and iterating again, etc.. The actual work involved ends up being quite different from game design, and this year was the first time I actually spent any time and effort at it during work hours. I’ve sort of put that game away for the near-future, but I do hope to get back to it again in 2015, possibly in a publishing context.
- Physical Games – This year I had some ideas for playground-sized games, including one idea that stands out above the rest. That game is something that I now consider to be a long term goal to actually see played / implemented. It will be expensive though, which is why it’s a long term goal. Incidentally, I can think of very few projects that qualify as “life sized” video games. There are a few, but nothing like what I’m envisioning. There is a blurry line here, for sure (is laser tag a life sized video game, for instance?), but the point is that I am moving slowly toward a real life implementation of this game. There will be programming involved, for sure, but that is only a small slice of the project in this case.
- Unreal Engine / Oculus – I do occasionally have ideas that are “bigger” than the 2D puzzle type games I typically make. Adding the 3rd dimension is not something I’m excited about, but sometimes I have designs that feel like it’s probably necessary. I subscribed to Unreal Engine ostensibly to start working on some Oculus games. (As usual, I’ve got lots of ideas.) I made a tiny bit of progress toward that goal, (got some of the sample projects working with my Dev Kit 2, as well as watched a bunch of Unreal tutorials), but ultimately haven’t really started coding anything yet.
- Processing / Arduino / L3D – I’ve always been peripherally aware of and interested in the Arduino / hardware Maker movement. In the fall of this year, partly as an extension of the physical game I eluded to above, I started thinking a bit about prototyping games with simple LED arrays. Then the L3D project fell onto my radar, and now I’m super into creating games for it. There is a Processing plugin to stream signals to the L3D, but in my testing so far, it’s relatively bandwidth intensive, so while I’ve done a bunch of work in Processing already (a platform I’d only dabbled in years ago), I’m now moving the project to “native” code running on the Spark core that powers the L3D. This means taking a step backwards in terms of functionality, but assuming what I want to do is possible, (reading Xbox controller input from controllers plugged into a USB hub that also powers the L3D) it should be much faster, and has the added benefit of not requiring a laptop/computer to run it on. I’m waiting for a powered USB hub from amazon, then I should have a quick test for this shortly thereafter. Anyway, in the mean time, I’ll be playing with some L3D visualizations needed to help “juice” the games anyway.
There are of course infinite things to learn and do, even limiting your activity to “game development”. I made a deliberate decision when I went independent to continue working in iOS so as not to lose the “depth” of skill needed to pick up a full-time job again if Abstract Puzzle didn’t work out, and I’m definitely not going to abandon that decision in 2015. That having been said, dabbling in new platforms gives you perspective! And as hot as IoT is right now, it probably won’t be a bad thing to have some microcontroller programming on my gamedev resume.
I’ve seen a few posts and tweets by game designers about their favorite games of the year. I thought I’d collect those and comment. (Maybe even compile my own list!)
iOSGoTY: Helix, A Dark Room, Kero Blaster, Woah Dave, Stellar Smooch, Pair Solitaire, Flappy Bird, ALONE, Threes, Monument Valley.& DrawType
— Zach Gage (@helvetica) December 23, 2014
It’s hard to believe that Threes! came out this year. Amazing really, considering how much time and effort was spent thinking about it, re-imagining it, not to mention playing it, of course. It probably gets my vote for game of the year.
I almost didn’t mention A Dark Room because it came out last year, but wanted to say that it’s well worth playing (as are all of these, now that I put it that way). Any game designer will especially like the “extras” that are unlocked after the first playthrough.
I got Stellar Smooch after reading this post, and LOVED it. It’s very short, and I was able to finish it in less than an hour, but everything about it made me happy. I did also pick up Woah Dave! on my 3DS, and played it for a few hours. Don’t think it would make my top 10, but it was worth $.99, for sure.
Monument Valley would also make my list. It was too easy, and I’d have liked MORE, but neither of those are reasons to deny yourself this absolutely amazing experience. It’s the best Escher inspired 2D puzzle game I’ve ever played. (I believe I also played Antichamber for the first time this year, although it came out in early 2013.)
Through a weird quirk of metacritic, VVVVVV's ended up as game of the year with a score of 95. Suck it, Hearthstone! http://t.co/DryjMQhoO1
— Terry (@terrycavanagh) December 18, 2014
The linked MetaCritic list is definitely worth reading. Cavanagh’s VVVVVV does take slot number one, and I would put it near the top of my list as well. I’d never played the game before (on any of its many platforms) and was absolutely blown away when I downloaded it earlier this year. I’m not even all that huge a fan of platformer games in general, but VVVVVV is definitely a game worth playing for the sheer number of ways platforming is re-invented (mostly around the central mechanic of reversing gravity at will).
ok i’m not making a goty list or wtf ever but iOS had an amazing year http://t.co/8028WIaZqL that is all
— adam (@ADAMATOMIC) December 22, 2014
After I read Adam Saltsman’s post in bed a few nights ago, I picked up Alcazar and played it until I fell asleep. Also, I’d completely forgotten that I wanted to buy Framed, so picked that up, as well as Hitman Go, (which I had been resisting, but is on sale currently for $.99).
Saltsman also mentions Michael Brough’s Helix, which I have played for a fair share of hours, and would probably make my top 10 (especially if limited to iOS).
Finally, after thinking about this long enough to write this post, I said:
— Martin Grider (@livingtech) December 25, 2014
Hoplite came out December 21st, 2013, but that may as well have been 2014, I think. Galaxy Trucker has been around for years, but I’m speaking specifically of the iOS port that came out this year. We’ve already talked about VVVVVV. Anyway, off to play some more games!
If you haven’t already seen the L3D kicksterter, head on over there and check it out. As of this writing, there are still 13 days left to get one of these awesome LED cubes.
I’m excited to announce that I’m working on some games for the L3D. As of last night, I’ve got a project with 4 game controllers working with the L3D “simulator”. You can see one controller working with my sample project here:
I’ll be posting the code in the next week or so, after I get my cube in the mail and test on some actual hardware. The L3D library (including primitive simulator shown in the video above) is all written as a plugin for Processing, (which, incidentally, I’ve wanted to work in for AGES), so it was a relatively simple matter to get the L3D plugin working with the Game Control Plus plugin.
Now that I’ve got them working together, I’m planning on working on the following projects:
- L3D Snake — a 3d version of this classic game, for 1-4 players — this one is practically done in my example code, just needs some auto-movemet, and an array of previous spaces for each player, and end-game conditions.
- text library — I’ll be helping write a general library for scrolling “marquee style” text. This should help with displaying who won once the game is over, along with maybe showing the score, or even game selection, if I get around to wrapping up several games into a package of some kind.
- some games of my own design — I’ve already got a simple color-selection territory game ready to go. This should look really pretty, as well as (hopefully) being fun to play. For 2-4 players. There are some other ideas I’m floating around also.
- L3D Tetris — This just needs to happen. I’ve written a lot of tetris variants, but never a 3D one (though I’ve always loved 3D tetris), so I think it’s finally time.
- L3D Invaders — A 3D space invaders could also be really fun.
I’m also really interested in the possibility of designing some turn-based “board games” using the L3D. I haven’t written anything down yet, but there are some ideas percolating in the back of my head.
I recently answered a short barrage of questions by some non-technical folks researching the business feasibility of board game conversion. Since I gave them these answers freely, I thought I would also post them here. This is all based on my own personal experience, so feel free to exercise skepticism and I absolutely welcome your thoughts or differing opinions in the comments below.
1. What resources estimates and how much time do you feel is needed to do a strategy board game conversion to digital?
The answers for this question are as varied as the answers to the question “how much time is needed to do a mobile game?” In my experience, if you’re paying your programmer(s) what they’re worth (which is not a given in the gaming industry), you’re probably looking at a budget somewhere between 30k and 120k. Less is certainly possible with an experienced team, maybe with a code base they’re reusing, but it would raise a red flag for me. (I get a lot of potential clients who come to me with 2-5k, and I politely tell them that we can possibly make a prototype without graphics for that much.)
2. If using Unity as a gaming language, what do you think is involved in porting to another platform say from iOS to Android or vice-versa?
I am familiar with unity, but no expert. (So take this with a grain of salt.) My feeling is that android is more work, what with supporting all the different screen sizes and hardware/processor idiosyncrasies, so if you’ve already done that work, porting to iOS should not be that much more difficult. (Depending on the project, of course.) Going from iOS to android on the other hand could take longer, especially for complex games. (It’s going to depend on how many screens or “scenes” you’ve got to prepare in unity.)
3. Are you aware of what the maintenance/support costs would/could be, if so what do you believe is involved?
This is a great question! Not something a lot of clients think to ask. It’s easy to throw something in the App Store and forget about it, which is exactly what everyone else will do too.
There are obviously diminishing returns though, so I recommend planning a release with at least one maintenance update about a week or so after the initial lunch, and maybe evaluate then whether it’s worth doing another “feature” update a couple of weeks to a month later, also with a follow up maintenance update if your budget can stand it. If the game is still doing well at that point, it’s a good idea to plan to spend some time and push out littler updates as frequently as you can, more for marketing purposes than for any development related reason. All of this will require developer involvement, but it’s the person crafting marketing and messaging that should be spending the most time after launch. I generally think this is underestimated, and can easily be a full-time task.
4. Do you have an idea of hosting (storage/bandwidth) costs?
This is only relevant if you are hosting your own server for some reason. The game should have a website, which is another often overlooked marketing piece, but it will cost far more to create that than to maintain/host it. (Hosting fees shouldn’t run more than $20/ month, or you’re probably getting ripped off somewhere. I pay $5/month + $10/domain, but that comes with doing mostly my own support.)
If you ARE hosting your own backend multiplayer server, you can think of it as another domain name. (It definitely cost you more up-front to develop, so make sure your dev is including that in their estimates.) And unless the game is super successful, most hosting plans should include enough bandwidth. If you get to the point where you are paying ala cart for bandwidth, it still shouldn’t be more than a handful of dollars unless you’re at an extreme end of the spectrum, which is a problem you wish you will have.
5. What’s your thoughts on the digitization of family board games, and what may happen, and when?
Well, “family board games” is a term that might mean a bunch of different things, but here are some initial off the cuff thoughts:
a) it’s already happening to some degree, see Monopoly, Scrabble, Jenga.
b) The family market is much larger than the hobby market, but much tougher to crack. Quality is going to be a very important consideration, as is ease of use and first-run experience, including tutorials and teaching.
c) It’s possible that the aforementioned digital game examples are mostly getting played by board game hobbyists, rather than the general populous you’d expect to be playing a family game, which would be hard to prove either way unless you are the publisher of one of those games.
d) In general, (this is advice I like to give to anybody thinking about physical game conversion), the advantage that board game conversions have over their fully-digital counterparts is that there is already a population that knows about that game and to a lesser extent how to play that game. So the bigger that group, the bigger your advantage. How successful your board game conversion will be is very much influenced or enhanced by how successful a game you are choosing to convert.
6. Are you familiar with Steam, and would you recommend porting or building for that platform?
If you want to target desktops (OSX, Windows, or Linux), then I would highly recommend building working with Steam. I cannot make a recommendation about whether those platforms are viable for board game conversions in particular. Steam is a bit like Apple’s App Store and Game Center rolled into one, but cross platform for desktop games. There is an API that you as a developer can write to, and implement Steam achievements and various other social offerings.
7. Do you feel the effort to port from say Android/iOS phones requires more work to port to Tablet versions as well, or not?
Generally there is a portion of every project devoted to UI work. The amount of time spent will be different for every project, but generally I think it’s a higher percentage of the project for games than other application types. Let’s say, for a game, 50% of the development effort was put toward UI work. If you had only developed for one screen size at that point, you might have to re-do or at least re-touch much of that work. If you plan from the beginning of the project for multiple screen sizes, you can save yourself a lot of pain in “porting” to a different screen size, but it is still more work, no doubt about that.
8. What about PC/Browser porting, are you noticing or see the need/demand or value in doing that, and if so are you familiar with the effort in that case let’s say after a mobile version has been completed?
I do see this happen from time to time, though not with a lot of board game conversions. My concern would be monetization, since the folks who play web-based games are used to getting their games for free, and you have to have a very large active userbase (in the hundreds of thousands, from what I understand, although I’m no expert) to make money with advertising alone.
9. How many people do you believe is needed to convert and maintain a board game digital conversion, and what roles?
For a “full featured” conversion, I see the following needs:
– Artist/graphic designer
– Sound Effects person and Musician (often can be the same person)
– Some kind of project manager or person making feature decisions
– A person (or team!) in charge of marketing
I have worked on a lots of projects where there were a couple of developers who split duties. This includes several apps with Tysen Streib, who would expertly craft the AI and game logic, while I handled all the rest of the application, including ultimately integration of his code into the project.
Another optional role I’ve found myself filling briefly at the start of smaller projects is that of UX designer. It is always nice to have a blueprint to work from, and good wireframes can really speed up development as well as help keep your team on the same page if there are multiple developers.
The mix and makeup of all of these roles will be different on every team, no doubt. There are certainly some indie developers who tackle all of these tasks for every project! I’ve found that keeping scope small is always a good thing, work toward manageable milestones, and you’re less likely to be surprised by how long something takes you to complete.
Below you can find my slides from the presentation I gave at last night’s IGDA Twin Cities meeting.
I think the presentation went okay, but I should have realized ahead of time how boring a topic spreadsheets can be. I saved the demos for the end of the talk, and by the time I got to them, I was really feeling the boredom radiating from all corners of the room. Anyway, I hope these slides are helpful to someone.
While preparing for the talk, I came across an interesting article about the history (origin) of spreadsheets called A Spreadsheet Way of Knowledge.