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.
I think I’m done for today. It’s a lot of fun to play with. Tomorrow I’ll clean up any issues and add some instructions and a title!
It functions, it makes noise. I need to figure out some features to add now.
I do this thing in my sequencer where I convert MIDI note events to frequencies. Only, I forgot about this, and I didn’t use good naming, so the sequencer was calling the frequencies “note” too.
Then I went to create a sequencer event using “note” and put in 63 (a middle pitch MIDI note) and wondered why nothing was playing. Answer: Those sampled patches did not want to play at 63hz. Duh…
Making progress towards a music toy…I just spent a half-hour “debugging” a feature of my emulated-ASCII library: char 0, bg 0, fg 0 is used as transparent and thus showed the purple backdrop(255,0,255). Oops…
I have some MIDI playback tech that I’ll probably be focusing my game around:
The graphics, on the other hand, will be emulated ASCII. Less time on art, more time on sound! Or that’s the idea at least.
I’m getting this down before I forget everything.
I had the explicit goal of doing a content-driven platformer, since I hadn’t gone for that before and it sounded like fun. I hedged this bet by doing a substantial amount of framework building to get the platforming going and to have a rough-and-ready in-game editor. Even so, it was an enormous crunch to complete this game.
I currently use a model for game design based around language; every game is described as an expressive medium in its own right, with a specific vocabulary and forms of sentence construction. The content of the game suggests possible sentences, compelling the player to engage in conversation as their vocabulary affords. It’s the most successful model I’ve used yet and lends itself to any genre without getting mired in worship of a specific mechanic, conventional structure, or balancing.
For this game I went off to Wikipedia and looked up “Loneliness,” and found a reference to rites of passage. This was a promising avenue since it let me work with concrete elements instead of the metaphysical. The basic idea took shape pretty quickly – some tribal warrior type of character doing various outrageous tasks to prove himself – inventory and a task list were the main elements introduced at this stage. I also included a time limit as a way to cap off the concept with a finite structure, although looking back at it I don’t think that was necessary. The day-night cycle added some extra flair to the graphics, but the details involved in being able to lose the game were a chore and don’t add much to the experience other than to pad out playtime.
Day 1 (6:00 PM-12:00 AM PST, Dec 16th)
I fixed some things in the framework early on and started on a prototype scene, developing my concepts in a text file. The day concluded with bits of graphics work to get my player and some tiles started.
The palette I used for this game is one I had made some weeks ago. It is developed from a very color-theory informed basis, using the wheel to build a heavily coordinated set of hues with a saturate-desaturate alternation through the values, and I credit it for 90% of the look of the game. As I get better at game development as a whole I increasingly recognize that fundamentals are the key to all the involved skills – if you get a better understanding of color and shape, you get better not just at illustration or pixel art, but at graphic design, typography, architecture, etc. Similarly: rhythm can affect speech, music, athletics; and writing tends to tie together most skills in doing this sort of self-reflection. (Coding can be reflective writing, too, if you stop being scared of it.)
Day 2 (12:01 AM-12:00 PM PST, Dec 17th)
Early in the morning I did the bulk of work on backgrounds. Although my framework has both scrolling and flipscreen modes, I chose flipscreen for this game specifically because it let me use a more detailed approach to backgrounds in each scene with less reconciliation at the borders. It also lends itself to better performance which is always a boost.
The waterfall came in at this point; the waterfall is both one of the coolest elements and also the most expensive. I told myself, “wouldn’t it be awesome if the first thing the player did was jump off a cliff and dive into a raging waterfall?” Although I had Pro Motion if I wanted a traditional colorcycle setup, Flash doesn’t support palettized color cycling natively, so I had to come up with a technique to emulate those effects on the spot – and I had never tried doing cycling anims before, although I had studied some of the most ambitious color cycle anims in the world earlier this month. I resorted to four copies of the background and did the rotation by hand, alpha fading one over the next and then swapping. A linear fade gave nasty looking results, but I found a way to overcome the artifact: first I squared the tween value, and then I tuned it some more with a specific exponent factor(my final value was 1.8).
I added in the day-night cycle soon after I had the waterfall in place. I figured that a color shift over the tilemap would look good and would help characterize the backgrounds, even if they didn’t change at all. As it turns out, it was not hard to set up a table with one entry for each hour of the day in game time(the game runs 6 AM to 8 PM – 14 hours game time, 15 minutes real time) and tween a Flash ColorTransform’s multiplier values. Between that, the auto-tiling sets I had made yesterday(this framework has nifty autotiling algorithms – I see room for improvement on more arbitrary uses of tiles though, like what I did on the trees), and the backgrounds, the look was feeling pretty well established. I still had plenty of sprites to work on, though, and the map needed filling out.
As the day drew to a close, I had the task list working, the timer, opening screen, and win/lose working, some sound, and one proof of tasks(pearl diving). I even got the environmental sounds working, which the game massively benefited from. In testing these things the in-game console was a huge help; you lose a lot of iteration time if you have to actually play the game to do anything. The final game has tons of leftover debug commands to tune the colortransform, set time of day, and set task completion, in addition to the map and graphics editing. So much happened all crammed into the later hours of this day that I’ve already forgotten a lot about it.
The last thing I did before I slept was the music. I don’t really like the end result – it starts off with an oppressive, John Carpenter Escape From New York feel, moves to a more contrapunctal style, and then finishes with simple repeated chords and arpeggios. All of those styles have merits; none of them exactly fit the game, in my opinion. However, I did not get a second chance. Ship it!
Day 3 (12:01 AM-6:00 PM PST, Dec 18th)
As on the previous day, I started in with graphics, and had most of my sprites done before my morning walk. One thing I found myself doing a lot, both on the previous day and this one, was to go back and polish completely random things. I did not restrain myself when this happened, figuring that if I had the motivation, I might as well follow through on it. In the timelapse you can see that I did a major revision on the opening screen, for example. The main character also went through four revisions – single color(too low-fi), outline color(too naked), and two revisions of clothing(too neon and then the final, which more-or-less hits my target of reading the outline first, and then the details).
Of course, what really loomed over my head was the completion of the rest of the gameplay. I switched back and forth between the various things to do – making sprites, integrating them as entities, map editing – until I finally hit the point where I really needed to start on more mechanics. If I remember correctly I did the dragon first, then the orange, some of the bird, then the lanterns, the rest of the bird, and then the pickaxe and gem.
The dragon was a scary problem to solve. Any time the character controller changes there’s a potential for massive bugs; fortunately I had had a bit of practice on it from doing the diving mechanics yesterday, in which the controller changes as soon as you touch(or emerge from) water. Those turned out to be more streamlined than I expected, with no actual swimming going on, and the same proved true with the dragon. I knew going in that I would place some entities and make a tweening path for the dragon’s flight to follow. Lack of planning meant that the path steered around the win/lose rooms, which is why the dragon flies up a cliff. After some work I had the player tweening along, and the dragon sprite following. But then the question was what kind of control the player had and how it was integrated; I realized it would be easiest to just add a y value on top of the basic tween y, and move the tween path down to the lowest level in the flight areas. The control turned out stiff but serviceable, and some patching up later, the dragon flight was done. I could have tuned that control to have more acceleration in it…oh well.
The orange was a straightforward addition to the dragon, and the basics of the bird were too – I already had projectile throwing from the framework demo and just adapted that to have a stone and use the inventory system(instead of a bow and arrow, an earlier concept that would have taken more effort). Around this time I finally got all the inventory working. I waited on finishing the bird in favor of the lanterns, though.
The lanterns were simple enough – touch and change animation, do a test to see if all are hit(the framework lets you iterate over tagged entities so this test can be done in a very reliable fashion). They caused a performance issue in that each one has animation callbacks every frame, though. In the final hours I somewhat optimized this so that they weren’t rendering offscreen, at least, but didn’t do anything about the callbacks themselves, which I suspect added a substantial load.
At this point I could see the finish line. I did some environmental sounds, the credits scroll, revised some sprites, got the bird’s flight in, did some more layout work, and finished the pickaxe section(which was again, pretty straightforward – I started from “projectile” behavior and adapted it to be more melee-like – it would have looked nicer following the player but I wasn’t about to care by then).
And….that was pretty much it. I finished with about 1 hour 30 minutes left on the clock, plenty of time to do my uploading and start the submission and documentation process. Later I got some feedback that indicated lack of clarity with dragon controls, so I added up arrow to it(instead of just jump); the LD website was (as usual) blowing up, so the change squeaked into the submission period.
What Went Wrong
Map editing was a bit slower than it could have been – more tool dev needed. Level layout suffered a bit because of this.
Performance got a bit impacted by the end; tuning the framework to let me optimize around flipscreening rules(e.g. making actors disappear when out of the room, putting the anim callbacks on the actors instead of a platforming controller) would help matters.
Some of the later aspects ended up less polished than I wanted as a result of time pressure.
The music wasn’t anything like what I wanted.
Some of the art techniques I used I was unfamiliar with; I could get faster/better at them.
What Went Right
Map iteration was great because it was all in-game.
The console, the console, the console. If you want to debug gameplay quickly, you need one.
The code did not degenerate into an unmaintainable mess, no siree. A lot of this stuff is reusable – and some of it I actually went and reintegrated into the framework base during the jam!
I finished all of that content!
The combination of the palette, the animation, and the environmental sounds really came together.
HaXe and NME were troopers, as expected. My personal stack for HaXe work is probably going to include NME more in the future(instead of my own hand-rolled build system), although I haven’t yet found a way to include SWF libraries seamlessly as in my own builds. Technology is never perfect…
Although it was a really tiring, stressful endeavor to do this, I’m struck by the result. I find myself wanting to return to the little world I made. Maybe elaborate on it with a sequel, even. Maybe that’s why people get stuck so much on pixel platformers – for the amount of effort, you can fabricate concepts pretty quickly, especially if you have nice tools to work with.
As always, I credit maintenance of a sound lifestyle for keeping me healthy and sane during the compo. Getting out of the house, getting enough sleep. Taking my vitamins, balanced meals with a side of vinegar. Caffeine in moderation. If I’m going to party, it’ll be around other people, not just sitting in front of the screen. And even doing all that, I’m still exhausted by this, psychologically speaking.
I should sleep now.
I have a song pretty much done, it’ll play for the “end credits.”
I succeeded at most of my goals for the day – did more polish than I expected, less content. But I’m in good shape. I just have to blast through the rest of the content tomorrow.
dragon flight code get it spawning bird flight code birds placed in map are spawners? or we just have them run on a consistent cycle? spriting: obstacles for dragon area(attacking birds) (reuse birds for hunting segment) three tasks: diving hunting(birds) fly dragon some sounds hit finish sounds add two or three tasks mining collect fruit make fire Ending celebration/failure
I’m getting worried that I won’t hit the targeted scope at this point. The assets needed aren’t too much, individually, it’s just that I have a pretty hefty list and I don’t feel as confident about being able to pump out content consistently right up to the deadline.
Got some environmental sound in – waterfall noise, and it changes as you enter different screens.
However I haven’t made much progress on the gameplay lately. I really want to get some of the gameplay in there before I sleep.
TODO new block type for water - the surface toggles platforming/swimming, or somesuch start sketching out whole game and getting bgs in place goals for rest of today: inventory working pick up stones one more button to drop vs. use("shoot") dragon flight code diving code bird flight code birds placed in map are spawners? or we just have them run on a consistent cycle? spriting: pearl sprites bubbles swimming sprites dragon sprite idling flying hit obstacles for dragon area(attacking birds) (reuse birds for hunting segment) throwing stones(instead of bow+arrow) three tasks: diving hunting(birds) fly dragon some sounds splash throw (replace the current thingy) hit _integration_ goals for tomorrow: finish sounds, add music? add two or three tasks mining collect fruit make fire Ending celebration/failure