About triplefox (twitter: @triplefox)
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Ludum Dare 21
Ludum Dare 17
you know about SILX #LD27
Awarded by alvivar
on August 29, 2013
It’s a few days after the jam is over and I’m still motivated to work on this game. This is a really good sign.
How it came to be
When I found out that the theme was “10 seconds” I was in the midst of a nice long walk, checking Twitter idly. I spent a while going through possibilities, particularly the pun idea of “10 secondaries” that has appeared a few times in other entries. But the idea of an online game where you only had 10 seconds to play was intriguing, especially when I added the idea of waiting in a line to do it. Enforced waiting is actually a big part of most sports, not just for logistical reasons, but because it sets the pace of the game. Even sports that are implicitly “always on” like soccer and basketball have defined time segments and will further break those up following goals or penalties. And when you wait and watch specific players, you can build some empathy for them. Multiplayer games where you’re just continuously fighting your own battle don’t build that kind of connection.
Simultaneously I had some interaction mechanics waiting around to be used – a challenging, high-momentum, low-friction 2D plane where collisions cause death. I had first used these over a decade ago in a long-forgotten jam entry called “Spaceboard,” which was a simple time trial racing game with lots of deadly obstacles. That game proved to be very addictive, and recently I had started playing the Mario series again and realized that the Mario games were satisfying in part because the controls were made to be this way too – at first, a bit too slippery and frustrating, but rewardingly difficult, when played at a high level.
With the Mario games in mind, I remade the Spaceboard mechanics and had a prototype sitting around with a character that could maneuver very rapidly, but needed precise control when braking to avoid overshoot. And so I combined the two ideas of a player queue and the challenging movement prototype, and then added taking a token to the goal(ball? coin? still not sure myself) and planting mines so that there was indirect interaction and a changing landscape. Mines were a major obstacle in Spaceboard – although in that game many of them had the ability to chase you.
Finally, I had usable technology sitting around since I had remade Heartbreaker, my entry for LD21, as a generalized rapid-prototyping multiplayer system with some ability to adapt to other games, handling details like the connect process, rooms, etc. while allowing each room to focus on the gameplay-specific protocol using Haxe serialization as the transport(no fancy efficient binary here). As a result most of my time was just spent knocking out the Heartbreaker stuff and reworking it to the new gameplay – the player queue and one-player-at-a-time stuff being a cause for major reworks. I only did one late-night crunch, on my last “night” before it was due, when all the basic protocol and player queuing stuff was out of the way and the game started to come together.
How I’m getting players
Online multiplayer has a problem in that it’s hard to get a playerbase started. Fortunately I have a strategy that is addressing this for the purpose of current development, which is to schedule a session every day at the same time (7 PM Pacific) and then advertise it a little across multiple IRC channels and my Twitter as the time comes near – IRC is particularly great for this, especially when you go to channels with “gamer” types. I manage to get a few players every time, pretty consistently. At least half of the players drop out really quickly after being frustrated by the controls, but the ones that stay tend to get very addicted.
The open question is whether I can sustain this and turn it into a percentage growth. As they say, nothing lasts forever, but I think I have a good chance to build a community here, especially since there’s a lot of stuff that is just begging to be tried out. The opposite was a difficulty I ran into with Heartbreaker, where it wasn’t clear where to take what I had already made, so I let it go.
Mostly simple stuff! Little improvements to the instructions and indicators. There are bigger change ideas but they aren’t the most important things right now.
It will be called “Meditating Robot” (unless I come up with a more minimal title)
It will look kind of like this
Here is my basecode(it is a haxe/nme project) link
i am making a truly minimal experience
The following is an essay recreated and revised from a talk I gave at the Lost Levels unconference during GDC 2013.
When I was young I was a very avid user of game making tools. I tried them all – ZZT, Megazeux, RDS GM, OHRRPGCE, ACK, Verge, TADS, etc. In most I never finished anything. In part this was because I had very little to say via game design yet. But even if I was just making a clone of a game I knew with “one little change,” there were brick walls that suddenly appeared at certain points.
To get certain kinds of features, I had to know how to code, and most of these systems didn’t expose coding at all, or they exposed it at too low a level for my pre-teen self. I had been able to learn enough to make some small things in BASIC. But there was a huge gap in my understanding towards making anything more substantial than “guess the number” or maybe “match this calculation.” And so I used game-making tools, but those tools mostly weren’t capable of adding original behaviors to a game or writing an elaborate cut-scene. (ZZT was one of the more notable exceptions here, so I used it often – and later, Megazeux, when it became an option.)
Similarly, there was another brick wall with art assets. To make something beautiful meant learning art fundamentals that I simply weren’t aware of yet. And to make something ugly was still time consuming, enough so that I would usually call off the project after making a handful of assets. This problem was exaggerated by tools that shipped with a tiny number of demo assets, and then left it to the user to fill in everything else. Again, ZZT was a savior for me since it forced the aesthetic in a certain direction that required little skill to do well.
Of course, I was relatively successful with physical prototyping, and made some board and card games. But video games still seemed closed off to someone of my age and interest level, even though I had about as much access as one could hope for, given the era. You had to at least be deeply motivated to learn programming, and I didn’t, at that moment.
During my teenage years, I had already witnessed barriers starting to come down. I wasn’t conscious of it, but there was a clear trend. The costs were becoming considerably smaller over time – between 2000 and 2010 I saw an enormous improvement in the quality of resources, tools, advice, and references. Between that and generally having more experience, it was well within reach for me to do some things solo by the latter part of the decade.
However, I still saw the brick walls. If I was trying to push the limits, it remained a hard and expensive(in time or money) task. This was a very disquieting thought to me. “Why can’t anyone make this? Why is it just those big studios?” I thought. I managed to avoid pondering it further for many years, but I’m pretty sure now that it led me to sabotage my own work and bury the expressive parts under technical nonsense, where I could at least feel good that I was doing something complicated and challenging.
But more recently, I began thinking about what cost actually *meant* for gaming. And it became obvious that it was controlling almost everything. The whole dynamic of the industry is based around it being too expensive, in time or money, to just go out and make what you want to make in a few hours of spare time, so you have to think about making a profit. So you start a business. Then you work with other people who are business-focused, and start to discuss things in terms of what might be a hit. Somewhere along the way, your conversations become all work, no play.
And it is what I see as the root of the vast majority of problems in gaming; it restricts creators into making games about boring, easily marketed, easily monetized subjects. It produces an endless war to secure funding for the next project. It reinforces a privileged monoculture, by filtering out people who can’t bear severe costs or network “appropriately.” If you are looking for the poison of this industry, cost is definitely it. (And it goes for any other creative field too.)
And in that case, I don’t want to sell games anymore. I have no bone to pick with people willing to continue with that cause, but I’d rather devote myself towards bringing down the barriers of this field further. There are lots of paths towards this goal: Improving education, creating new or better tools, improving the funding mechanisms, increasing awareness of authors, preserving and curating the history… there are so many options beyond “sell my games as products” that it seems silly to continue restricting my focus in that way.
Before I forget.
My goal for this LD was, as is my habit, to prove some engine tech. (I’m tired of building tech, but I’m also having trouble stopping while pursuing the games I want to make.) In this case, I had three major pieces going on:
This thing is a bear, and it will probably continue to be one so long as I stay inside Flash and target my current machine(a 2009-era Intel dual-core laptop) as the baseline. Although I had enough ways to tune the quality to fit, it continues to suck up a ton of CPU with a relatively small number of voices(16-32). And I found flaws in my MIDI playback technique that made looping and dynamic tempo adjustment…”interesting.” Fortunately it works for the game to sound a bit hiccupy.
It works reasonably well, if you aren’t on Linux. I did have a last-minute performance issue where I was doing things wrong with the updates of the tilemap, but that was my fault and was more of an engine bug than anything.
Yeah…this game is actually doing a lot more work than you’d think, under the hood. It’s built on top of an engine that is intended to be multiplayer-ready… (someday, not now) and it sucked up so, so many hours figuring out solutions for things like “picking up items” or “timing the bombs going off.” A playthrough-stopper that I’m still unsure whether I solved or not, because it has a non-obvious trigger in normal play, is something related to the synchronization of entity despawning. All this added up to the game being very bare-bones, without some of the stuff I wanted like NPCs to oppose you or powerups or chain reaction explosions.
However…I managed to get through the jam without very many terrible hacks. So in the aftermath I can start going back and whittling away at the problems, and that is going to help make this codebase very strong…although I really want to get away from Flash at this point, I’m mostly waiting on Haxe/NME. It’s currently an NME-oriented engine, but I’m definitely considering dropping NME, porting towards the Haxe CPP and JS targets alone, and getting away from Flash for good \o/
A bit on the game design
It was actually pretty straightforward to come up with a design for this one, by shamelessly stealing from Wreck-It Ralph.
1. Villains tend to destroy things (but they don’t have to be evil mustache-twirlers)
2. Make a character whose ability is destruction and is driven to become the bad guy.
3. Give them a space to destroy.
4. Make the destruction engaging.
The only part I kind of missed on was the last, simply because of a lack of depth.
You can navigate with the arrow keys, and toggle the music/game over sound by clicking. Note that if you let the music run long enough it will destroy your CPU. I think I can make a solution for the final game, though, that won’t affect people with a low spec(other than the framerate being shit and the sound clipping).
Next things for tonight:
Jam entry(don’t care enough about the rules to do compo right now)
Main character is a bomb. “Bomb-It Bob” possible title?
Will walk around a city and blow up stuff like in Bomberman. Destroying walls = points. Explosive items littered around the map so that chain reactions possible. Hopefully time will permit NPC characters who might help/harm Bob.
Bob has a fuse, limited lifespan. Alarm clocks spawn to extend his fuse. Taking damage reduces fuse?
Start from other project code(2d Zelda-like tilemaps, client-server). Add wall rendering, item collision events, NPCs? Integrate Triad synth and use a MIDI track so tempo can increase as time runs out.
I don’t have a lot of time since I’m on a trip right now but I will try to bang out a little 1-2 hour game. Using Haxe with my Triad framework, available here: https://github.com/triplefox/triad/blob/master/
- Load and save songs
- Clear board
- Record .WAV (32-bit stereo)
It went relatively smoothly. I made a timelapse, which I’ll hopefully post a little later. I have some thoughts for a post-compo version which would add more stuff, particularly saving and loading.
The only major sources of lost time were problems within my own framework(bugs, misfeatures, etc.) and the sampleset I used(they each had weird patch settings which I fixed by hand) – but it was overall a relaxed feeling, especially after the second day was over. Very different from my experience in LD22, where I was coming down to the wire to build tons of content in a short period.
As a bit of reflection: The influences on this game are many and varied. A good portion of it stems from the feedback of my previous work(in which I’ve played with celluar automata systems, synthesis and procedural content). The ASCII emulation was made previously for a compo of the Moosader community, and I made a very deliberate choice to go for ZZT-like styling. And I had just come off of getting the sampler/sequencer working for MIDI demos, so I was prepared to reuse it for another project and round off some edges in the process. Last but not least, I had a lot of inspiration from all the games of this style(Falling Sand or otherwise) but got lucky in quickly finding a productive set of “playing pieces” to work with.