@Tuism: thanks! The core ice-sliding "move till you hit something" mechanic is actually quite old, but I've usually seen it as a small part of a larger game. I'm interested to see what they do with Blocko cause it looks like they're focussing a lot more on that core mechanic.
BTW, this is still very much a work in progress, but the direction we're probably taking Streamline is something in this direction:
The colors and shapes are so lovely. I think it's definitely the best out of the other mockups you've done - the simplicity suits the gameplay better :). There was one thing about the image I just didn't like and I didn't realise what it was until I put it through a Grayscale filter:
The colors are lovely and contrast each other well, but purely from a value standpoint, a lot of the elements in the game are shouting for the same amount of attention. The line is basically the same value as the background, which is maybe an issue? I think the 'Line' should have a stronger contrast to everything else, whether it be brighter/darker. I don't know much about art though, so this could be bullshit. I'm interested in how the graphic design of the elements communicates their functioning too. The arrows look a bit too solid, and the wood blocks don't look solid enough. The remaining pieces make it hard to tell what they will do without playing to jog my memory :).
I have to be honest - I'm a big sucker for the Giraffe one :'D. I chuckled when I saw it. I think a humorous art direction is an interesting direction to take with a puzzle game - it kinda relieves the intensity a bit. When you're struggling with a hard puzzle, at least the art makes you smile. I think this effect is reasonably present in Snakebird, and to a lesser extent, Stephen's Sausage Roll. I also like the tongue idea mock-up, but not sure about the design of the tongue, it looks a bit too shiny. I think it also needs animation to be funny, but I also imagine little saliva trails everywhere :). Also maybe the end point is a really delicious morsel of food or something? Dunno.
@Bensonance: 100% agree with your contrast criticism. That mockup was more of a quick investigation into an alternative aesthetic direction. I maybe didn't emphasis how much of a WIP that is ;)
Our motivation for choosing the noodles over the animals (the idea was to potentially have more than just the giraffe) is that it's also a very saucy design space, but probably a lot more cost effective. I think the noodles would also easily be able to have a bit of a humour direction, but the animals definitely get the cuteness much more easily. I could also see the argument that making it too cute could be a bad thing - I think that might have counted against Snakebird as it's a bit misleading to some players.
It also seems like the noodles fit a bit better with the mechanics. You can do a lot of stuff with noodles, like cutting them, but I think it would be a bit jarring if you cut the giraffe's neck...
One last aspect is: how many pun-heavy pasta-themed games are there out there? So yeah, that more-or-less our thinking on why to go with that direction. Thoughts? We haven't committed yet, but probably in the next couple weeks.
Oh yeah totally didn't get how WIP it was :D. Think most of the crit is still good though, so maybe better that you didn't say it was WIP? :D
Oh it's a noodle? That makes sense now! It doesn't *quite* come across as that for me, but I like the idea. I think the noodles is a good balance between cute/puzzle aesthetics. Although, I think you might have more leeway than Snakebird for cuteness if (presumably) you're going to mobile? Mobile I figure(?) will target less intensely puzzle orientated people than PC would?
Lol yeah wouldn't want to witness a cut giraffe neck :D.
how many pun-heavy pasta-themed games are there out there
There will never be enough in my opinion :'D. I like the noodle/pasta direction :). Especially with those colors :).
Oh yeah I agree, your crit is good, thank you :) (sorry if it seemed like I was dismissing it)
We will apply our noodles to make it look more like brains noodles.
Currently we're thinking of a cross-platform release, possible starting with desktop, or maybe simultaneously, or maybe mobile first (we're a little unsure, you might be able to tell). Our not-too-distant plans include posting it to Greenlight, and assuming it gets through, we'd definitely also release it on Steam. if we can't manage a simultaneous release, it seems like going desktop first and then mobile would be better than vice versa.
@dammit: Good question! The reality is that I don't know for certain, so the tldr is it's mostly a gut feeling, but I'll outline my thought process (it was some time ago, so I've probably forgotten some of it).
Firstly, I've mostly heard of other devs going simultaneous or desktop then mobile. My impression is that this goes down better with "gamers" and it's generally easier to write for desktop, cause mobile can need a bit of optimization (for CPU and UX). I'm also under the impression that generally you'll make more on Steam than mobile, but when I asked Alan Hazelden (creator of A Good Snowman Is Hard To Build), he had some different experience so YMMV.
I also created a spreadsheet that tries to analyse a bunch of similar games. I looked at games on both desktop and mobile, and used SteamSpy or other stats to estimate sales. I included a factor to try account for sales, and where I was skeptical or unsure, I estimated lower. For each game, we then tried to evaluate it, based on a few factors, and try work those into a prediction of sales. I then used a similar process to try estimate potential sales for Streamline (so estimating lower gives more pessimistic estimates). I'm very weary of the numbers tho, they seem too optimistic, but it's at least something. I think the most valuable part of the process was analysing similar games in a structured manner and looking for trends and such. If anyone is interested, you can have a look at the spreadsheet, but it's kinda opaque and badly documented. If I look at the spreadsheet, it seems kinda random whether a game did better on desktop or mobile.
I also did a bit of analysis of typical sales numbers on Steam for badly-performing similar games (again, trying to be pessimistic), and compared this a bit with some of the numbers I've seen on mobile. My impression is that Steam is a much safer bet and we'd be more likely to hit our break-even point. It's also worth noting that desktop price will likely be a bit higher than mobile, so it seems more natural to launch with a higher price and then have lower-priced options a bit later.
Having said all of that, the game is already running well on mobile, so I think the chance we'll try a simultaneous release is quite good, probably much better than the average, and especially now that we've sorted out selling on Android. Also, we don't have to make the call yet, and we'll almost definitely do cross-platform eventually, so the implications on scope and timeline are also not that much.
It's been a long time since we've shown much progress on this, and that's mostly due to other projects keeping us busy, but things haven't been dead! Since the last update here, we tried implementing that noodle art aesthetic, but unfortunately we found that it didn't really work so well. Fortunately, we've settled on a new and improved aesthetic, along with a new name: Jetstream. I'm working full steam on this project now, so there are likely to be a couple updates in the near future. For now, we have a small landing page, including an HTML5 demo build of the game. In the next couple days/weeks when I have more time I'll try post some updates here.
Note: there are some issues with running this on mobile devices at the moment (input is sometimes ignored?) - sorry, we're aware of this and I'll be looking at this soon!
The current dev plan is to roll out the new aesthetic to the rest of the mechanics in the game, and add buckets of juice and polish. We're looking for any feedback you folks have on the landing page or the game itself; especially the game. Anything broken? Any suggestions?
[-] Kind of feel that there should be a score of some kind as it's possible to finish the levels in multiple ways. [-] Also feels like it would be nice if the playing area was a bit bigger. [-] It's polished and well presented. [-] Site is nicely simplistic, could benefit from a screenshot or video.
Also feels like it would be nice if the playing area was a bit bigger.
Good point. Smaller levels are easier, but the levels certainly get larger as the game progresses and the difficulty ramps up. This is already in the original prototype, Streamline (look at the "scale" levels), and will be coming to Jetstream soon, although probably not in the demo.
Kind of feel that there should be a score of some kind as it's possible to finish the levels in multiple ways.
I've given this some thought before, but I can't think of any good score measure. The only scores I can think of are the number of moves and a timer. The number of moves would either almost always be the same (if you don't count undos), or punish the player for making any mistakes, giving the game a very different feel. I want players to be able to play a few moves to see how the game state changes - I don't want them to have to plan everything out in their heads.
As for timers: I vehemently dislike them in puzzle games, for a few reasons. I could probably write an essay on this, but my quick thoughts: having a timer immediately puts pressure on the player to play quickly and generally makes them feel bad when they spend even a moment considering a move, so they tend to only play with their gut and this means they can't really think about what they're doing and form strategies and theories, at least not at the pace you can get with a more relaxed un-timed game. So similarly with number of moves, this leads to a very different kind of game.
Anything else for a score you had in mind? Something I haven't thought of?
On the other hand, why should there be a score? What would it actually accomplish? The best puzzle games I can think of don't have scores you need to beat, they have easier and more difficult puzzles.
Site is nicely simplistic, could benefit from a screenshot or video.
Yip! A video that shows more of the gameplay, especially after the demo, is on the cards. However, it's costly to get a really good video made, so we want to wait till the game is a lot more fleshed out before we do that. Some screenshots would be really simple tho - I'll look at getting that done sooner :)
Anything else for a score you had in mind? Something I haven't thought of?
I was thinking about using 'fuel' as a score parameter, you could use it as a bonus rather than a hindrance, the fuel that is left over could be used for a bonus of some sort, that way it's not a negative pressure on the player, but a positive one, a reward. It could even be used for cosmetic upgrades like sparkling clouds or whatever.
Fuel is a better idea than moves (although some later mechanics, like other vehicles we intend to include, might slightly complicate it), but it's also not very different to just a plain ol' move counter. So I guess my criticism of move counters is still applicable. It is definitely a more relatable and thematic idea than moves though.
However, I'm still not sold on the idea of a score mechanism in the first place, I feel like it conflicts with other parts of the design and it doesn't really gain much, especially in this game. There aren't many reasons for replaying levels, and making levels you can actually replay is significantly more difficult, so it seems like rather just making extra levels would be a win-win from the dev/player perspectives.
The idea behind including something like fuel is to give the player some kind of feedback of how they did, at the moment that feedback loop is missing and so the game feels a tiny bit off. It doesn't need to be a direct score, but some indication of what is a 'good' way to solve the puzzle would be nice.
For instance, there was a puzzle or two where I could have taken a short path or a long path, yet the decision of which is preferable wasn't part of the game, I wasn't nudged in the right direction. Also think it was the last puzzle in the demo where it was possible to finish the level without using one of the special tiles. Yet the decision of should I try and use all the special tiles or try to use the least of them was not supported.
Ah ha, so I think the difference in our thinking comes in because I don't actually want to indicate to the player a "good" way to solve a puzzle. In my mind there are no good and bad ways, either they get the concept I'm trying to communicate to them, or they don't. Sometimes puzzles have multiple disparate solutions, and in those cases it's typically a mistake on my part as the designer (for instance the last puzzle in the demo, although that one could be something like an achievement)
BTW, I hope I'm not coming across as contrarian, I just think the direction where you have scores is generally a different kind of puzzle game. If you look at this article, I'm trying to make a combinatorial puzzle game, whereas I think procedural puzzle games are better suited to score mechanisms. If you're interested in combinatorial puzzle games, there's another great article on them with insights from Alan Hazelden.
@francoisvn Gonna find time to give more feedback soon, but just wanted to jump in here to discuss the feedback thing. I agree about the micro level feedback about solving the puzzles, like indicating a score or something is a design choice, but I think it's better to not guide a player to a given solution. It's great that players can just find multiple solutions.
However, I do think some sort of meta-feedback is super helpful. Alan does this quite well in his recent game Cosmic Express. You're always zooming out after you finish a level to see a new level(s) or world unlock, and then you get to choose again which level to try. This is great, because it continually gives you feedback on your progress through the game. I think Jetstream kinda lacks that right now? The individual puzzles are great and they flow really nicely into each other, but a sort of meta-progression would be great. You have the level select screen, but that's only really for when you come back to the game after leaving it, not for conveying progress. I could imagine a neat little overworld screen kinda like Broforce, where you're zooming around the earth itself? Some sort of meta-progress that's in your face would be effective, imho.
Also did you read the most recent RPS interview with Alan? What I found quite interesting is some of the puzzles he designed to have hidden harder, more obtuse solutions, that players would try come back for perhaps. This sort of thing is interesting, in terms of the feedback discussion on a level-to-level basis. That 'metric' or 'spectrum' of solutions that a score per level tries to convey could be more subtle and add another layer of gameplay for committed players (obviously most players won't engage with this content though).
@Bensonance: Good point about the meta game progress! That's just completely lacking in the demo, but I definitely want to have it in the final game.
The current plan is: after completing a level group (there's just the one in the demo right now), it zooms out, back to the collection of stamps for that level group, and then you can progress to the subsequent level groups by swiping to the side. I got this idea from the excellent little Zip Zap. Maybe it would be good if you zoomed out to this level selection after each level? I feel like that might break the flow of the game, but it's also really easy to try. Jetstream's puzzles are inherently a lot easier than most of Alan's puzzles, so I feel like the game is the best when you play through a few of them in a go. However, that is also just an assumption on my part, I should test it.
Another idea for meta progress I had was: the levels are laid out in a 2D grid, where completing one will unlocked the orthogonally-adjacent levels. Very much like in Snakebird. There would be a final level somewhere, perhaps in a corner and you wouldn't have to solve all the other levels to get there. Eventually, when you reach the final level you realise that every normal level is really just a tile in the bigger level, but it's a black trap cloud (the crosses in Streamline) until you solve them, at which point they become the real tile in the final level, and if you solve enough of the normal levels you can complete the final level. At the moment this idea has been mothballed because I figured it's a clever idea, but I'm not sure it does much more than sound cool. Also, having levels in such an open structure is much more difficult to design, cause players are likely to miss some important concept I tried to teach in an earlier easier level. However, it could be revisited again, even at a relatively late stage.
We could also do something like a world map with locations for levels, and then you expand the web of travel routes as you solve levels (similar to Cosmic Express), but that doesn't seem much better than the current plan, and not as cool as the 2D grid, although it would be a lot more work to design and communicate to the player.
Also did you read the most recent RPS interview with Alan? What I found quite interesting is some of the puzzles he designed to have hidden harder, more obtuse solutions, that players would try come back for perhaps. This sort of thing is interesting, in terms of the feedback discussion on a level-to-level basis. That 'metric' or 'spectrum' of solutions that a score per level tries to convey could be more subtle and add another layer of gameplay for committed players (obviously most players won't engage with this content though).
This is an interesting topic. I would love to include something like that in the game, and if I start including some really obtuse puzzles I intend to make them optional. I also feel like the player should be able to "finish" the game without these, so they feel like they can walk away satisfied having "completed" the game, and then have a super ending for players that really engage with the tough obtuse stuff. That article is still on my reading list, together with this one, so I'll go read those and come report back :)
I caught up on my reading on Cosmic Express and I just had to highlight a part from this article that made me a little giddy:
In every constellation, or group of themed levels, there is one with an unobtrusive black monolith placed somewhere in the scenery. Click on it, and it’ll animate one of the aliens and one of the boxes. To succeed at its challenge, you need to draw a route which takes that alien to its box, as well as solving the rest of the level.
I love that concept! I'm guessing that's part of what you were referring to @Bensonance. I played an earlier version of Cosmic Express that didn't have the monoliths (or I just completely missed them). Doing something like that in Jetstream would be easy and I think it would fit in well with the mechanics. Tap a "monolith" and it shows some tiles you either must visit or must avoid. This doesn't solve the meta progress thing, but it's a lovely extra little thing I can pretty easily add into the game for very little effort :D
I like the final visual style that you went for. The symbols used are very recognizable, and once you see what they do the symbols become obvious. Got through the demo with only the last two puzzles really posing a challenge.
I also feel that the reward for me is solving the level and moving on to the next one. I'm not the type of person that will return to a puzzle to get a higher score, but the alternative "monolith" solution would definitely entice me (though I get that they are waaay harder to design).
Ah ha, so I think the difference in our thinking comes in because I don't actually want to indicate to the player a "good" way to solve a puzzle.
I'm really trying to get a subtlety across, let me try again.
Some of the concepts are not defined and so it's hard to judge the intended underlying approach. There is obviously 'distance', 'number of moves' and 'special' tiles as concepts present in the game. Now the game does not quantify (for the lack of a better word) those concepts. Sure you can leave them as undefined, but there is a good opportunity to define all of those and give the player an underlying goal.
Should distance be minimized, should moves be minimized, should use of special tiles be minimized, or should any of them be maximized? It doesn't need to be blunt and visible, like a score, but it would be useful to quantify those concepts to the player.
Some of the concepts are not defined and so it's hard to judge the intended underlying approach. There is obviously 'distance', 'number of moves' and 'special' tiles as concepts present in the game. Now the game does not quantify (for the lack of a better word) those concepts.
@critic: I'm not quite sure I understand what you're saying, especially the distinction of "concepts" and how they can be defined/undefined or quantified. If what you're saying is: there are a number of potential metrics in the game that are ignored or just not counted, ranging from obvious things like the number of moves, to obtuse things like "the number of right-hand turns", then I completely agree with you, these things are (intentionally) not measured.
Sure you can leave them as undefined, but there is a good opportunity to define all of those and give the player an underlying goal.
Why do I want to give the player multiple goals (a main goal and an underlying goal)? Why is just solving the puzzle not enough of a goal? If you're saying I'm throwing away potentially valuable information, you might be right, but I don't think most of these measures actually add anything to the play experience for the player, and possibly even detract from it.
Should distance be minimized, should moves be minimized, should use of special tiles be minimized, or should any of them be maximized? It doesn't need to be blunt and visible, like a score, but it would be useful to quantify those concepts to the player.
What I'm saying is: these values are not relevant in this kind of game. The number of moves (and any of the other measures) should neither be minimized or maximized, it's not relevant to the goal of the game. The only goal that matters is: can you get the little plane to the destination pin? If one person does this in 5 moves, and another takes 25 moves, I don't want to differentiate their solutions. Or if one person takes 10 seconds and someone else takes 3 hours, they both get the exact same result.
Am I not understanding you? It seems like you feel like I'm missing something, whereas I feel like I understand, I just don't agree.
Rule-set is just wonderful for an algorithm, so I decided to make a small program that can solve these puzzles. Got a big smile on my face, thought I should post it here. @francoisvn sent you a PM.
@critic: that's really cool! What's the 12 to the left of calculate? Is that a depth limit to the tree search? Did you find anything interesting? What sort of algorithm did you use? Have you tried adding some of the mechanics that are present in Streamline but not yet Jetstream, like the portals or multiple lines?
I already have a built-in level editor and I have some plans (might not get to them) to improve the analysis tools in the editor. Having them a button-press away from playing the level helps a lot with design. BTW, the LD jam version already had the editor, and you can still get the source code on the Ludum Dare website.
I currently use Monte-Carlo simulations in the procedural generator (only in Streamline right now) to avoid trivial levels and apply a few design heuristics. I was thinking of using a full tree search for level analysis, so I can see a bunch of things, not just the solutions, but also things like: are any of the tiles inaccessible? How many options did the player have to consider (at the start you generally can go either up or right, but in a corner there is typically only a single option)? If I overlay all the solutions, do they have something in common? At the very least, having a tool to show me all the solutions and see if I missed anything would be very useful. I spoke to a few people at GDC about design tools and I think this is something that'll be getting better in the next couple of years. It's certainly very interesting to me :)
Glad you like it, it uses a breadth first tree search and yes that's the depth restriction field next to the calculate button. I haven't included collecting of anything except the solutions, but it shouldn't be too hard to collect certain classes of rejected paths.
I was surprised how fast the algorithm works, since it's basically splitting every possible move into 4 paths, the way the puzzle works really cuts down on valid moves. Unfortunately that's about all the time I have to spend on this, I do hope you find it useful, source is in your mailbox. :)
I just pushed out a small bugfix release (0.1.1). The game should now work reasonably well on Android, but we're still seeing some weird issues on iOS. If you play on mobile, pls let us know how well it works. Are there any functional issues, like things not working? How is performance?
Quick update: we're working on a zero-text tutorial:
How it works: at the start it shows both possible moves you can make, using little pictograms. Once you've made a move it tries to draw your attention to the destination pin by bouncing, and if you take a while it shows you the move you should make. On mobile this only shows the swiping gesture (no arrow keys).
The goal was to teach the input interface and basic goal in a language-agnostic way. From there on the game teaches through level design. Thoughts? Any suggestions?
So I just played this again at work today (shh don't tell anyone).
Initially I was a bit jarred by the theme (plane stopping suddenly feels calamitous), but the design telegraphs super well now! Eg black clouds are super obvious. Compass works great. Other icons seemed good. Grats! (though granted I did play streamline)
I'm not bothered by the lack of scoring. If you really wanted to encourage users to find alternate solutions you could do the cosmic express thing and and have different end points unlocking different meta branches.
This is going to either seem really ironic coming from me, or jaded words of wisdom - but this feels super ready to go, ship it! I mean yes, add a meta layer - but beyond that you have something that feels real good and is easy to c-l-o-n-e. I realised today that even as serious puzzle game player I hardly ever finish any puzzle games - for this reason I would be extra weary of iterating until your inner designer is totally satisfied. Feel like being first to market in this case is worth way more :)
Initially I was a bit jarred by the theme (plane stopping suddenly feels calamitous)
Do you think that's a concern? I haven't heard anyone else describe it as calamitous yet, haha, but I'm also not sure how to soften that (or if it needs to be softened).
This is going to either seem really ironic coming from me, or jaded words of wisdom - but this feels super ready to go, ship it! I mean yes, add a meta layer - but beyond that you have something that feels real good and is easy to c-l-o-n-e. I realised today that even as serious puzzle game player I hardly ever finish any puzzle games - for this reason I would be extra weary of iterating until your inner designer is totally satisfied. Feel like being first to market in this case is worth way more :)
It comes across well, and I think we're on the same page here. We won't make it "official" yet, but we have a pretty hard 3 month deadline (till end of July) to finish production. We anyway wanted to limit the scope quite aggressively, but the deadline gives a bit of a "time budget" that I can work with. The plan is basically to make the best game we can within that time, and my feeling is that we can make something pretty cool. In broad strokes, we're looking at adding a few mechanics, spending some time making and designing the levels, and then oodles of polish and juice. If we get done sooner that'll be great, but that last 10% is prone to eat up any time we might have.
This is a pretty small update, but it includes: * The new tutorial * Better trap/storm clouds (see the lightning!) * More land (no gameplay effect at this point, but a future mechanic will change that...) * Some other minor improvements and bug fixes
The next update should include a few small things, one of which is a performance improvement that is already taking the game from <10 FPS to 60+ FPS in some scenarios (I just need to roll it out to the rest of the game). I'm also looking at a feature to make super tiny custom builds of the game that include one or a few levels, so we can demo new mechanics and other stuff in isolation - just run a special build command and it plops out an HTML5 build I can upload and share.
Just played again... it's something one soon ignores. I think it's the really strong bounce animation. I means planes don't bounce, generally speaking. But thinking about how I would fix it, tbh I can't think of good solve that wouldn't take you further away from what you've already got which is working well. The bounce animation is important telegraphing... so I don't know.
Also, first time I played with sound - sounds were instantly annoying. ;)
@TheFuntastic: oh I see. Yeah, the plane's animation is probably the issue; it is quite jarring at the moment. I have some thoughts on how to improve that and will revisit it a bit later, but it's a low priority for the moment
Hey folks, we're officially looking for someone to help the project with audio. We're looking for someone to work together with us to figure out the best sound profile for the game, including music and sound effects. Here's more details on what we're looking for and what to do if you're interested: http://bit.ly/JetstreamAudio Feel free to share that around or contact me directly with any questions :)
Hey guys, we're currently looking at adding waves and other small doodads to the ocean in an attempt to make it a little less monochromatic and more visually interesting. We've had some back-and-forth and discussion internally, but now we think it might be interesting to get some public opinion.
In this first mock up, items A - D experiment with conveying waves in an abstract way, unobtrusive way while trying to keep to our overall aesthetic. E & F are concepts of deeper water and doodads or visually interesting elements that could appear randomly in a level. Note that for the purpose of the mockup these levels are exceptionally busy and only 1 or 2 items would appear per level.
In this subsequent mockup, we took the ideas we felt worked the most and refined them a little. We also chose one or two of our favourite doodads and polished them a little to give a better idea of how they might appear in the game.
Which do you think is the best way to convey waves without being too "visually busy"? Do you think the square deeper regions fit better with the game's grid-like world, or do the rounder ones provide a nice visual respite? Which doodads are the most appealing to you, or do you have ideas for things you'd like to see?
We're looking for some feedback to aid us in moving forward.
It's a bit hard to tell how they'd look full screen (I mean, something that feels right as a thumbnail might be too low detail at phone screen size).
Personally I like A and B the most, they feel like postage stamp designs... although I don't like where they intersect with the waves from the islands... And expect that A and B are the most difficult designs to work with, they feel the most "swish" in an Apple iPhone kind of way, but the least friendly (so I guess it depends on the tone of the game that you intend striking, for instance the bouncing airplane motion feels closer to friendly than swish).
I also like C, whereas the representation of the waves in G,H and I feels like it comes from a different art style than the cloud borders (which are more cartoony/Nintendo than the geometric wave shapes in G,H and I). I feel wary about pictoral icons that don't have any gameplay function, having a variety of decorative illustrations on the map doesn't feel in line with the minimal airplane and red map marker designs... I'd expect the decorations to be something specific that occurs more often that is clearly non-gameplay but has some entertainment value rather than just decorative value (like flocks of ducks that are displaced by your flight path).
I find A and B difficult on the eyes because of the high noise ratio it introduces to the otherwise flat design elsewhere. I think C works really well because the waves are less distracting overall and nod to the more iconic understanding of the wave shape. The mantra I'm trying to instill at work is "Everything in service to gameplay". Thinking on that the doodads in the ocean that have short lifespans could act as a hint. Overall I think the values and colors of things in the gameplay layer should be distinctly different enough from the doodads which is going to clear up any confusion players might have of something affecting their path. I really like the clean style.
Another vote for C :) Conceptually, I like the aesthetic and charm behind the others, but in context it feels distracting - drawing attention to something that should not be noticed. I like the idea of the odd doodad animating in for a brief cameo, as perhaps a touch of charm, but not to steal the show...
Thanks for the great feedback on the water doodads and effects! It's not final yet, but we think our plan is to go with something quite simple, like C, possibly having some transient effects that happen randomly, like a fish jumping out of the water and landing again, appearing and disappearing quite quickly. We're happy with this mockup/investigation phase and we've pushed the implementation back a bit cause we have more pressing tasks.
I'm happy to report that the search for someone to handle the audio went well. We got 30 applications that we had to carefully review and select from, which I found quite tough (I'd rather write code any day of the week, hah!). We're still finalising arrangements with that, but I should have something to report on in a week or two. I'm really excited to start getting some proper audio in the game!
We've also been chatting with someone that we will likely be partnering with to make sure we get Jetstream in front of the people that would love it and (hopefully) make it a real success. I don't have anything more I can publicly share on this, but I think it's great news for Jetstream and I'm excited about telling everyone more in the coming weeks or so.
Then we haven't been slacking around the past few weeks on the development/production front either. I just uploaded a new version (0.2.0), which has a whole host of changes:
New gfx system. This was a big change that took some time, but should help a lot in the long run. The game gfx are all batched now (they weren't in the past) and there are some other tweaks, which means performance is a lot better. We can add some extra features to the system, but I think this should carry us into release :)
Micro builds. This is a new feature for Jetstream that allows me to really quickly and easily make and share a tiny custom HTML5 build of a game with a subset of mechanics or other things. Expect to see a couple of these tiny builds popping up soon.
New mechanics.. We've added 3 new mechanics (that weren't in Streamline). Unfortunately you can't play with them in the demo, but very soon I plan to put out little micro builds that showcase these mechanics and let you try them out.
Level icon previews. We've revamped the look of the menu icons. Performance isn't great, but we'll fix that in a later update.
Better cloud bumping. Bump more of the cloud. More bumpiness. More cloud.
Some improvements to the editor and other internal process tools.
Improved basics/demo level design. I've removed a few levels near the start, and added a few more near the end. The difficulty curve should be a bit more pronounced near the start (but hopefully still quite smooth) and peak a bit at the end, hopefully to pique people's interest :)
Some plane highlighting and better movement. The plane is more snazzy.
New reset icon. We've replaced the white abstract icon with a red/orange jerry can. Check it out!
I'm probably also gonna start sending out some close beta testing builds in the coming weeks. If you're interested in being part of that and seeing the latest stuff we're working on, please sign up for the mailing list.
ICYMI: it's official, Liz Rainsberry will be joining the team as the music composer and sound artist. We're really excited to have her on the team, you should probably go follow her and check out her work.
Just pushed a new build (v0.2.1). Most of the changes are behind the scenes or not present in the demo, but here's some highlight from the changelog:
Basic gfx for all mechanic. We've now ported all the mechanics from Streamline and drastically improved their look!
Some improved backend services and tools, including a new audio middleware layer.
Fixed some iOS issues and re-enabled the demo on iOS. Sorry if you've missed it!
I like how the cloud growing ties in with the theming. :) It makes the visuals feel more like they matter, as opposed to being a re-skin of the previous version. I'd enjoy seeing more things like that! (I think some of the existing mechanics and their visuals have a rather tenuous link, though I struggle to think of any better ones. XD)
The expanding storm clouds are pretty aesthetically aligned, but it turns out they aren't quite as interesting in terms of puzzle design, so their use will be somewhat limited. One or two of the other new mechanics are also more tied-in with the theme, but to be 100% honest there is a bit of a disjoint between the theme and the game design in general. I'm not too worried about this, I feel like there are enough elements that bring the game together as a whole, but it is worth noting and we are aware of it.
The mechanic that's probably most tied-in with the theme is internally referred to as "different travel modes." The idea is that you can land on the land regions and drive around there. You still leave a line you can't cross, but the difference is that you're restricted to land and you can move a single tile at a time (not move till you hit something). We've just implemented the first mechanical version of this and we'll be testing it to see if it results in interesting puzzles :)
Quick update: just uploaded a new version. The gap between the demo and the internal full build is starting to widen. That makes it difficult to see what we're up to from just looking at the demo, but also means we're getting closer to being finished with the game!
Some of the changelog:
New pushable block mechanic
New travel mode mechanic
New tweening system, now with 100% less memory leaks
I'm pretty excited about seeing everything come together with the game. The list of things we need to do is diminishing at a rapid pace, thanks to the hard work of the team :)
Here's a GIF for the interface, including splash screen, a few levels, and new menu:
@roguecode: thanks. I think I can see what you mean. I wonder if the reason they stand out is due to the harsh edges or because their outline is quite thin? I've noticed it before but can't quite put my finger on what the issue is. Either way I'll add a task and have a look at it a bit later :)
The progress is exciting! ... But please improve the sounds (I imagine it's very hard to recommend a game or share the link to the demo when it sounds like this)
@francoisvn Re: keyboard arrow keys: It matches the game logo, but for everything else you haven't really used strokes (shapes in your game art are outlined by their shadow, which vary in width, as opposed to a single weight stroke like the keyboard keys) so I think that, the sharp corners, and the high contrast between shape and stroke is where the difference comes in.
If you wanted to match it up with the art style, I'd try losing the stroke and wrapping the light grey shadow around the key (thin top, medium sides, fat at the bottom) so it looks like the bevelled vibe most non-mac keyboard keys have, and then it also matches the perspective of the rest of the scene.
Yeah, I thought somewhere in between those two would be a solid fit for the art style, though now I'm thinking just round it it out and fatten it up a bit. Roughed it out. Your font might contain a nicer glyph for the arrows themselves.
Comments
BTW, this is still very much a work in progress, but the direction we're probably taking Streamline is something in this direction:
Some of our other mockups: http://bit.ly/streamlinemockups
The colors and shapes are so lovely. I think it's definitely the best out of the other mockups you've done - the simplicity suits the gameplay better :). There was one thing about the image I just didn't like and I didn't realise what it was until I put it through a Grayscale filter:
The colors are lovely and contrast each other well, but purely from a value standpoint, a lot of the elements in the game are shouting for the same amount of attention. The line is basically the same value as the background, which is maybe an issue? I think the 'Line' should have a stronger contrast to everything else, whether it be brighter/darker. I don't know much about art though, so this could be bullshit. I'm interested in how the graphic design of the elements communicates their functioning too. The arrows look a bit too solid, and the wood blocks don't look solid enough. The remaining pieces make it hard to tell what they will do without playing to jog my memory :).
I have to be honest - I'm a big sucker for the Giraffe one :'D. I chuckled when I saw it. I think a humorous art direction is an interesting direction to take with a puzzle game - it kinda relieves the intensity a bit. When you're struggling with a hard puzzle, at least the art makes you smile. I think this effect is reasonably present in Snakebird, and to a lesser extent, Stephen's Sausage Roll. I also like the tongue idea mock-up, but not sure about the design of the tongue, it looks a bit too shiny. I think it also needs animation to be funny, but I also imagine little saliva trails everywhere :). Also maybe the end point is a really delicious morsel of food or something? Dunno.
Love this general direction, though! :)
Our motivation for choosing the noodles over the animals (the idea was to potentially have more than just the giraffe) is that it's also a very saucy design space, but probably a lot more cost effective. I think the noodles would also easily be able to have a bit of a humour direction, but the animals definitely get the cuteness much more easily. I could also see the argument that making it too cute could be a bad thing - I think that might have counted against Snakebird as it's a bit misleading to some players.
It also seems like the noodles fit a bit better with the mechanics. You can do a lot of stuff with noodles, like cutting them, but I think it would be a bit jarring if you cut the giraffe's neck...
One last aspect is: how many pun-heavy pasta-themed games are there out there? So yeah, that more-or-less our thinking on why to go with that direction. Thoughts? We haven't committed yet, but probably in the next couple weeks.
Oh it's a noodle? That makes sense now! It doesn't *quite* come across as that for me, but I like the idea. I think the noodles is a good balance between cute/puzzle aesthetics. Although, I think you might have more leeway than Snakebird for cuteness if (presumably) you're going to mobile? Mobile I figure(?) will target less intensely puzzle orientated people than PC would?
Lol yeah wouldn't want to witness a cut giraffe neck :D. There will never be enough in my opinion :'D. I like the noodle/pasta direction :). Especially with those colors :).
We will apply our noodles to make it look more like brains noodles.
Currently we're thinking of a cross-platform release, possible starting with desktop, or maybe simultaneously, or maybe mobile first (we're a little unsure, you might be able to tell). Our not-too-distant plans include posting it to Greenlight, and assuming it gets through, we'd definitely also release it on Steam. if we can't manage a simultaneous release, it seems like going desktop first and then mobile would be better than vice versa.
Firstly, I've mostly heard of other devs going simultaneous or desktop then mobile. My impression is that this goes down better with "gamers" and it's generally easier to write for desktop, cause mobile can need a bit of optimization (for CPU and UX). I'm also under the impression that generally you'll make more on Steam than mobile, but when I asked Alan Hazelden (creator of A Good Snowman Is Hard To Build), he had some different experience so YMMV.
I also created a spreadsheet that tries to analyse a bunch of similar games. I looked at games on both desktop and mobile, and used SteamSpy or other stats to estimate sales. I included a factor to try account for sales, and where I was skeptical or unsure, I estimated lower. For each game, we then tried to evaluate it, based on a few factors, and try work those into a prediction of sales. I then used a similar process to try estimate potential sales for Streamline (so estimating lower gives more pessimistic estimates). I'm very weary of the numbers tho, they seem too optimistic, but it's at least something. I think the most valuable part of the process was analysing similar games in a structured manner and looking for trends and such. If anyone is interested, you can have a look at the spreadsheet, but it's kinda opaque and badly documented. If I look at the spreadsheet, it seems kinda random whether a game did better on desktop or mobile.
I also did a bit of analysis of typical sales numbers on Steam for badly-performing similar games (again, trying to be pessimistic), and compared this a bit with some of the numbers I've seen on mobile. My impression is that Steam is a much safer bet and we'd be more likely to hit our break-even point. It's also worth noting that desktop price will likely be a bit higher than mobile, so it seems more natural to launch with a higher price and then have lower-priced options a bit later.
Having said all of that, the game is already running well on mobile, so I think the chance we'll try a simultaneous release is quite good, probably much better than the average, and especially now that we've sorted out selling on Android. Also, we don't have to make the call yet, and we'll almost definitely do cross-platform eventually, so the implications on scope and timeline are also not that much.
It's been a long time since we've shown much progress on this, and that's mostly due to other projects keeping us busy, but things haven't been dead! Since the last update here, we tried implementing that noodle art aesthetic, but unfortunately we found that it didn't really work so well. Fortunately, we've settled on a new and improved aesthetic, along with a new name: Jetstream. I'm working full steam on this project now, so there are likely to be a couple updates in the near future. For now, we have a small landing page, including an HTML5 demo build of the game. In the next couple days/weeks when I have more time I'll try post some updates here.
Play the game here: http://jetstreamgame.com/
Some screenshots: http://imgur.com/a/0mzFC
Note: there are some issues with running this on mobile devices at the moment (input is sometimes ignored?) - sorry, we're aware of this and I'll be looking at this soon!
The current dev plan is to roll out the new aesthetic to the rest of the mechanics in the game, and add buckets of juice and polish. We're looking for any feedback you folks have on the landing page or the game itself; especially the game. Anything broken? Any suggestions?
[-] Kind of feel that there should be a score of some kind as it's possible to finish the levels in multiple ways.
[-] Also feels like it would be nice if the playing area was a bit bigger.
[-] It's polished and well presented.
[-] Site is nicely simplistic, could benefit from a screenshot or video.
Good point. Smaller levels are easier, but the levels certainly get larger as the game progresses and the difficulty ramps up. This is already in the original prototype, Streamline (look at the "scale" levels), and will be coming to Jetstream soon, although probably not in the demo.
I've given this some thought before, but I can't think of any good score measure. The only scores I can think of are the number of moves and a timer. The number of moves would either almost always be the same (if you don't count undos), or punish the player for making any mistakes, giving the game a very different feel. I want players to be able to play a few moves to see how the game state changes - I don't want them to have to plan everything out in their heads.
As for timers: I vehemently dislike them in puzzle games, for a few reasons. I could probably write an essay on this, but my quick thoughts: having a timer immediately puts pressure on the player to play quickly and generally makes them feel bad when they spend even a moment considering a move, so they tend to only play with their gut and this means they can't really think about what they're doing and form strategies and theories, at least not at the pace you can get with a more relaxed un-timed game. So similarly with number of moves, this leads to a very different kind of game.
Anything else for a score you had in mind? Something I haven't thought of?
On the other hand, why should there be a score? What would it actually accomplish? The best puzzle games I can think of don't have scores you need to beat, they have easier and more difficult puzzles.
Yip! A video that shows more of the gameplay, especially after the demo, is on the cards. However, it's costly to get a really good video made, so we want to wait till the game is a lot more fleshed out before we do that. Some screenshots would be really simple tho - I'll look at getting that done sooner :)
However, I'm still not sold on the idea of a score mechanism in the first place, I feel like it conflicts with other parts of the design and it doesn't really gain much, especially in this game. There aren't many reasons for replaying levels, and making levels you can actually replay is significantly more difficult, so it seems like rather just making extra levels would be a win-win from the dev/player perspectives.
For instance, there was a puzzle or two where I could have taken a short path or a long path, yet the decision of which is preferable wasn't part of the game, I wasn't nudged in the right direction. Also think it was the last puzzle in the demo where it was possible to finish the level without using one of the special tiles. Yet the decision of should I try and use all the special tiles or try to use the least of them was not supported.
BTW, I hope I'm not coming across as contrarian, I just think the direction where you have scores is generally a different kind of puzzle game. If you look at this article, I'm trying to make a combinatorial puzzle game, whereas I think procedural puzzle games are better suited to score mechanisms. If you're interested in combinatorial puzzle games, there's another great article on them with insights from Alan Hazelden.
However, I do think some sort of meta-feedback is super helpful. Alan does this quite well in his recent game Cosmic Express. You're always zooming out after you finish a level to see a new level(s) or world unlock, and then you get to choose again which level to try. This is great, because it continually gives you feedback on your progress through the game. I think Jetstream kinda lacks that right now? The individual puzzles are great and they flow really nicely into each other, but a sort of meta-progression would be great. You have the level select screen, but that's only really for when you come back to the game after leaving it, not for conveying progress. I could imagine a neat little overworld screen kinda like Broforce, where you're zooming around the earth itself? Some sort of meta-progress that's in your face would be effective, imho.
Also did you read the most recent RPS interview with Alan? What I found quite interesting is some of the puzzles he designed to have hidden harder, more obtuse solutions, that players would try come back for perhaps. This sort of thing is interesting, in terms of the feedback discussion on a level-to-level basis. That 'metric' or 'spectrum' of solutions that a score per level tries to convey could be more subtle and add another layer of gameplay for committed players (obviously most players won't engage with this content though).
The current plan is: after completing a level group (there's just the one in the demo right now), it zooms out, back to the collection of stamps for that level group, and then you can progress to the subsequent level groups by swiping to the side. I got this idea from the excellent little Zip Zap. Maybe it would be good if you zoomed out to this level selection after each level? I feel like that might break the flow of the game, but it's also really easy to try. Jetstream's puzzles are inherently a lot easier than most of Alan's puzzles, so I feel like the game is the best when you play through a few of them in a go. However, that is also just an assumption on my part, I should test it.
Another idea for meta progress I had was: the levels are laid out in a 2D grid, where completing one will unlocked the orthogonally-adjacent levels. Very much like in Snakebird. There would be a final level somewhere, perhaps in a corner and you wouldn't have to solve all the other levels to get there. Eventually, when you reach the final level you realise that every normal level is really just a tile in the bigger level, but it's a black trap cloud (the crosses in Streamline) until you solve them, at which point they become the real tile in the final level, and if you solve enough of the normal levels you can complete the final level. At the moment this idea has been mothballed because I figured it's a clever idea, but I'm not sure it does much more than sound cool. Also, having levels in such an open structure is much more difficult to design, cause players are likely to miss some important concept I tried to teach in an earlier easier level. However, it could be revisited again, even at a relatively late stage.
We could also do something like a world map with locations for levels, and then you expand the web of travel routes as you solve levels (similar to Cosmic Express), but that doesn't seem much better than the current plan, and not as cool as the 2D grid, although it would be a lot more work to design and communicate to the player.
This is an interesting topic. I would love to include something like that in the game, and if I start including some really obtuse puzzles I intend to make them optional. I also feel like the player should be able to "finish" the game without these, so they feel like they can walk away satisfied having "completed" the game, and then have a super ending for players that really engage with the tough obtuse stuff. That article is still on my reading list, together with this one, so I'll go read those and come report back :)
I also feel that the reward for me is solving the level and moving on to the next one. I'm not the type of person that will return to a puzzle to get a higher score, but the alternative "monolith" solution would definitely entice me (though I get that they are waaay harder to design).
Some of the concepts are not defined and so it's hard to judge the intended underlying approach. There is obviously 'distance', 'number of moves' and 'special' tiles as concepts present in the game. Now the game does not quantify (for the lack of a better word) those concepts. Sure you can leave them as undefined, but there is a good opportunity to define all of those and give the player an underlying goal.
Should distance be minimized, should moves be minimized, should use of special tiles be minimized, or should any of them be maximized? It doesn't need to be blunt and visible, like a score, but it would be useful to quantify those concepts to the player.
Why do I want to give the player multiple goals (a main goal and an underlying goal)? Why is just solving the puzzle not enough of a goal? If you're saying I'm throwing away potentially valuable information, you might be right, but I don't think most of these measures actually add anything to the play experience for the player, and possibly even detract from it.
What I'm saying is: these values are not relevant in this kind of game. The number of moves (and any of the other measures) should neither be minimized or maximized, it's not relevant to the goal of the game. The only goal that matters is: can you get the little plane to the destination pin? If one person does this in 5 moves, and another takes 25 moves, I don't want to differentiate their solutions. Or if one person takes 10 seconds and someone else takes 3 hours, they both get the exact same result.
Am I not understanding you? It seems like you feel like I'm missing something, whereas I feel like I understand, I just don't agree.
I already have a built-in level editor and I have some plans (might not get to them) to improve the analysis tools in the editor. Having them a button-press away from playing the level helps a lot with design. BTW, the LD jam version already had the editor, and you can still get the source code on the Ludum Dare website.
I currently use Monte-Carlo simulations in the procedural generator (only in Streamline right now) to avoid trivial levels and apply a few design heuristics. I was thinking of using a full tree search for level analysis, so I can see a bunch of things, not just the solutions, but also things like: are any of the tiles inaccessible? How many options did the player have to consider (at the start you generally can go either up or right, but in a corner there is typically only a single option)? If I overlay all the solutions, do they have something in common? At the very least, having a tool to show me all the solutions and see if I missed anything would be very useful. I spoke to a few people at GDC about design tools and I think this is something that'll be getting better in the next couple of years. It's certainly very interesting to me :)
I was surprised how fast the algorithm works, since it's basically splitting every possible move into 4 paths, the way the puzzle works really cuts down on valid moves. Unfortunately that's about all the time I have to spend on this, I do hope you find it useful, source is in your mailbox. :)
Play here: http://jetstreamgame.com/
EDIT: a wild GIF appeared:
How it works: at the start it shows both possible moves you can make, using little pictograms. Once you've made a move it tries to draw your attention to the destination pin by bouncing, and if you take a while it shows you the move you should make. On mobile this only shows the swiping gesture (no arrow keys).
The goal was to teach the input interface and basic goal in a language-agnostic way. From there on the game teaches through level design. Thoughts? Any suggestions?
Initially I was a bit jarred by the theme (plane stopping suddenly feels calamitous), but the design telegraphs super well now! Eg black clouds are super obvious. Compass works great. Other icons seemed good. Grats! (though granted I did play streamline)
I'm not bothered by the lack of scoring. If you really wanted to encourage users to find alternate solutions you could do the cosmic express thing and and have different end points unlocking different meta branches.
This is going to either seem really ironic coming from me, or jaded words of wisdom - but this feels super ready to go, ship it! I mean yes, add a meta layer - but beyond that you have something that feels real good and is easy to c-l-o-n-e. I realised today that even as serious puzzle game player I hardly ever finish any puzzle games - for this reason I would be extra weary of iterating until your inner designer is totally satisfied. Feel like being first to market in this case is worth way more :)
Either way I'm super excited for it!
It comes across well, and I think we're on the same page here. We won't make it "official" yet, but we have a pretty hard 3 month deadline (till end of July) to finish production. We anyway wanted to limit the scope quite aggressively, but the deadline gives a bit of a "time budget" that I can work with. The plan is basically to make the best game we can within that time, and my feeling is that we can make something pretty cool. In broad strokes, we're looking at adding a few mechanics, spending some time making and designing the levels, and then oodles of polish and juice. If we get done sooner that'll be great, but that last 10% is prone to eat up any time we might have.
I've just pushed an update (v0.1.2) live: http://jetstreamgame.com/
This is a pretty small update, but it includes:
* The new tutorial
* Better trap/storm clouds (see the lightning!)
* More land (no gameplay effect at this point, but a future mechanic will change that...)
* Some other minor improvements and bug fixes
The next update should include a few small things, one of which is a performance improvement that is already taking the game from <10 FPS to 60+ FPS in some scenarios (I just need to roll it out to the rest of the game). I'm also looking at a feature to make super tiny custom builds of the game that include one or a few levels, so we can demo new mechanics and other stuff in isolation - just run a special build command and it plops out an HTML5 build I can upload and share.
Also, first time I played with sound - sounds were instantly annoying. ;)
In this first mock up, items A - D experiment with conveying waves in an abstract way, unobtrusive way while trying to keep to our overall aesthetic. E & F are concepts of deeper water and doodads or visually interesting elements that could appear randomly in a level. Note that for the purpose of the mockup these levels are exceptionally busy and only 1 or 2 items would appear per level.
In this subsequent mockup, we took the ideas we felt worked the most and refined them a little. We also chose one or two of our favourite doodads and polished them a little to give a better idea of how they might appear in the game.
Which do you think is the best way to convey waves without being too "visually busy"? Do you think the square deeper regions fit better with the game's grid-like world, or do the rounder ones provide a nice visual respite? Which doodads are the most appealing to you, or do you have ideas for things you'd like to see?
We're looking for some feedback to aid us in moving forward.
Personally I like A and B the most, they feel like postage stamp designs... although I don't like where they intersect with the waves from the islands... And expect that A and B are the most difficult designs to work with, they feel the most "swish" in an Apple iPhone kind of way, but the least friendly (so I guess it depends on the tone of the game that you intend striking, for instance the bouncing airplane motion feels closer to friendly than swish).
I also like C, whereas the representation of the waves in G,H and I feels like it comes from a different art style than the cloud borders (which are more cartoony/Nintendo than the geometric wave shapes in G,H and I). I feel wary about pictoral icons that don't have any gameplay function, having a variety of decorative illustrations on the map doesn't feel in line with the minimal airplane and red map marker designs... I'd expect the decorations to be something specific that occurs more often that is clearly non-gameplay but has some entertainment value rather than just decorative value (like flocks of ducks that are displaced by your flight path).
The mantra I'm trying to instill at work is "Everything in service to gameplay". Thinking on that the doodads in the ocean that have short lifespans could act as a hint.
Overall I think the values and colors of things in the gameplay layer should be distinctly different enough from the doodads which is going to clear up any confusion players might have of something affecting their path.
I really like the clean style.
drawing attention to something that should not be noticed. I like the idea of the odd doodad animating in for a brief cameo, as perhaps a touch of charm, but not to steal the show...
I'm happy to report that the search for someone to handle the audio went well. We got 30 applications that we had to carefully review and select from, which I found quite tough (I'd rather write code any day of the week, hah!). We're still finalising arrangements with that, but I should have something to report on in a week or two. I'm really excited to start getting some proper audio in the game!
We've also been chatting with someone that we will likely be partnering with to make sure we get Jetstream in front of the people that would love it and (hopefully) make it a real success. I don't have anything more I can publicly share on this, but I think it's great news for Jetstream and I'm excited about telling everyone more in the coming weeks or so.
Then we haven't been slacking around the past few weeks on the development/production front either. I just uploaded a new version (0.2.0), which has a whole host of changes:
- New gfx system. This was a big change that took some time, but should help a lot in the long run. The game gfx are all batched now (they weren't in the past) and there are some other tweaks, which means performance is a lot better. We can add some extra features to the system, but I think this should carry us into release :)
- Micro builds. This is a new feature for Jetstream that allows me to really quickly and easily make and share a tiny custom HTML5 build of a game with a subset of mechanics or other things. Expect to see a couple of these tiny builds popping up soon.
- New mechanics.. We've added 3 new mechanics (that weren't in Streamline). Unfortunately you can't play with them in the demo, but very soon I plan to put out little micro builds that showcase these mechanics and let you try them out.
- Level icon previews. We've revamped the look of the menu icons. Performance isn't great, but we'll fix that in a later update.
- Better cloud bumping. Bump more of the cloud. More bumpiness. More cloud.
- Some improvements to the editor and other internal process tools.
- Improved basics/demo level design. I've removed a few levels near the start, and added a few more near the end. The difficulty curve should be a bit more pronounced near the start (but hopefully still quite smooth) and peak a bit at the end, hopefully to pique people's interest :)
- Some plane highlighting and better movement. The plane is more snazzy.
- New reset icon. We've replaced the white abstract icon with a red/orange jerry can. Check it out!
- Many small tweaks and bug fixes
You can play the new demo build here: http://jetstreamgame.com/I'm probably also gonna start sending out some close beta testing builds in the coming weeks. If you're interested in being part of that and seeing the latest stuff we're working on, please sign up for the mailing list.
Phew that was a lot! :D
Just pushed a new build (v0.2.1). Most of the changes are behind the scenes or not present in the demo, but here's some highlight from the changelog:
- Basic gfx for all mechanic. We've now ported all the mechanics from Streamline and drastically improved their look!
- Some improved backend services and tools, including a new audio middleware layer.
- Fixed some iOS issues and re-enabled the demo on iOS. Sorry if you've missed it!
As always, you can play the new demo build here: http://jetstreamgame.com/Closing for now, here's a small GIF of a new mechanic:
The mechanic that's probably most tied-in with the theme is internally referred to as "different travel modes." The idea is that you can land on the land regions and drive around there. You still leave a line you can't cross, but the difference is that you're restricted to land and you can move a single tile at a time (not move till you hit something). We've just implemented the first mechanical version of this and we'll be testing it to see if it results in interesting puzzles :)
Some of the changelog:
- New pushable block mechanic
- New travel mode mechanic
- New tweening system, now with 100% less memory leaks
- Better cloud bumping
- Improved menu performance and look
Play the new demo build here: http://jetstreamgame.com/I'm pretty excited about seeing everything come together with the game. The list of things we need to do is diminishing at a rapid pace, thanks to the hard work of the team :)
Here's a GIF for the interface, including splash screen, a few levels, and new menu:
If you wanted to match it up with the art style, I'd try losing the stroke and wrapping the light grey shadow around the key (thin top, medium sides, fat at the bottom) so it looks like the bevelled vibe most non-mac keyboard keys have, and then it also matches the perspective of the rest of the scene.
Either way, it's gorgeous!
@Wes_Matthews: thanks! Were you thinking this sort of look for the keys?
or maybe something like this, but with the sides of the keys a solid off-colour instead of the monochrome cut-out: