Don't break the chain

by midge 11. October 2014 02:10

A level a day continues!

I didn't feel like putting in too much work tonight, but I did manage to do one level "spottyCaverns". I just took the easySlopes level, and made it more difficult by having steeper slopes and some more randomness in it. I made it about twice as long as that level. Not my most inspired level, but pretty good for an early game level. I beat it on my 2nd try.

I'm still tempted to improve the level editor a little bit, I don't know if I will. I'm trying to be less precious with the levels I make and just make them. If I make too many levels and some of them are just not fun, I can just discard them.

The later levels will take longer to make because they require more play testing, and are either more challenging or just much larger in size.

So I've got 4 levels at the moment, their ordering still yet to be determined. 12 levels is the target for the initial release. If I keep them short, I may go with more than that... 16? 20? Who knows. I'd probably just launch with 12 and if the game has even modest success I could release some level pack add-ons.

A modest goal would be 2 levels each weekend day. A stretch goal would be 4 levels each weekend day. If I make 4 levels on both Sat and Sunday... that's my initial 12 levels right there. Not too shabby.





A level a day keeps the __________ away!

by midge 10. October 2014 00:30

I was thinking about doing 2 levels a day, but one level a weekday is fine. 2 levels on weekend days should be pretty easy to do.

I really like the name "a series of tubes" but this was pretty directly inspired by flappy birds so I called it "flappy copter".

The longest level I've made yet (although not by much). I nailed this one on the first try. It was still a little more difficult than I expected, but I was able to beat it after just a few tries. Pretty fun!

This one was easier to create because there is a whole lot of negative space. I'm not turning that many pixels on. Despite being the longest level, it was actually the smallest filesize, because there are a lot of 0's for empty columns.

I could be a whole bunch smarter about level compressing, or any compression at all, but it's just not worth it. The levels are pretty tiny as it is. I'm pretty sure when you submit to the store they compress your resource files for you anyways. Text compresses pretty well.

Screenshotty from the level editor:



Sup, reasonable bedtime.


I made one easy level and one difficult level.

by midge 9. October 2014 02:32

The easy level was easy to make. The difficult one was difficult to make because... my first several versions of it were actually impossible. I don' t mean that as "challenging" I mean actually physically impossible. The copter just could not climb or dive fast enough to navigate the level. It took several iterations to make the level playable.

I like the hard level. It's short, but rewarding. It was originally supposed to be level 2, but it's waayy to difficult. It might be like 6 or 7.


I switched to a descriptive naming scheme for the levels, for the files at least. Instead of level1.txt, level2.txt, etc... I switched to "easySlopes.txt" "diveClimbSqueeze.txt". This makes more sense because as I learned tonight, sometimes it's hard to predict how difficult a level will feel. I can make the levels and then put them in some order that makes sense later.

This was fun. More time consuming than I expected, but it pretty much always goes that way. I *may* still tweak diveClimbSqueeze to make it a little easier. I must say, leaving the level as difficult as it is, I sure felt a sense of achievement when I actually played through that bugger. That's a good thing.

Designing and then playtesting your own levels when you try to make something difficult is a funny thing. While you're making it you feel like "haha, take that you son of a a bitch!". And then 5 minutes later when you are play testing it "YOU SON OF A BITCH! This is impossible!"

And then it was 2:30 AM.

The End.


Edit - Punny idea for a level  "blocking bugs" and you have to dodge graphics that look like the space invaders bugs.


Ye Olde Level Design Doc - Analog edition

by midge 7. October 2014 01:04


I was feeling a little bit of frustration yesterday trying to design levels in the level editor. I was grumbling about my tools, but really I didn't know what I wanted to make. I decided to take a step back tonight and start designing with pen and paper.

This was really fun, even though I've only just gotten started. It gave me a lot of good ideas. I don't know why, but I feel a lot more creative with pen and paper than I did in front of my level editor.

Half of the fun was coming up with stupid names for the levels. "Slopes for dopes", "Sir Blocks a lot" and "A series of tubes" are all still in the running. I hadn't thought of any way to display level names, but I think I'm going to work it in, because coming up with fun level names is - ahem, fun. It makes them more memorable. Giving each level a unique feel seems like a really good idea too.

I also like the idea of having a little preview of the next level at the end of the current level.

I'm probably going to have to tweak the speed to make the game more challenging at the end. Gravity may have to be adjusted as well. Maybe I'll even tweek this blog entry...

There we go, much better.

Anways, I'm glad I put the programming aside for a night and just got back to game designing. Now that I've built up the engine and some tools, I know that I can do all this stuff, and that is pretty encouraging. I can dream up some cool stuff now, and then make it later without too much (additional) difficulty.

I realized that my personal ios dev account had expired. I was about to renew that tonight, but I recognized that for what it really was - procrastination. I didn't know wtf I was going to do next for levels and I wanted something semi straightforward again. I'm not going to let myself renew that thing until I have all of the levels made. That will sort of be a reward. Once I get it on devices I will show people I know IRL, that will be a good incentive. Although I remember the ios provisioning profiles, key chain, and whatever else you need to do to load the apps on physical hardware to be a bit of a pain in the ass. I've done it before, I can do it again.


Time to design the fun

by midge 6. October 2014 01:54

I actually got a significant amount of work done today. Specifically around what I had decided to call "read only level meta data". Basically it helps me load up real level data on demand. I made a class for that and it seems to be working. The level meta data is in a plist file. This tells the game what actual level data file to load, and what colors to use for blocks. That's all working fine. I didn't program it to read in the background color yet, but the data is there for when I want to use it.


I also made a prototype of a first level. I didn't spend too much time on it, but this will be one of the tougher non-programming parts of making the game. Making levels that have a good balance of challenge and fun.

The target for right now is 12 levels.

My level editor is kind of a pain to use. I think I may just suffer through using it for this game. I just gave myself pause there (reminder, make a pause button) - I was just going to say at least it's better than making the levels by hand in a text editor... that might not actually be true. I hate to admit it, but one thing that a text editor would have is I could cut and paste large parts of repeatable data. I might actually use some version of both.

I just want a look of consistency to the game... or at least to each level. Each level can look unique, but must be internally consistent. It looks too amateur to have a grab-bag of different styles all over the place. And we're just talking about colored blocks here, people.

So I've still got a lot of levels to work on. There's some straight forward functionality to add here and there and a good amount of polish for the whole thing.


One of the ideas I had today, (which I actually posted about as a reminder) was the idea of checkpoints for in app purchase. The idea being that for really tough levels, you get to a certain point... you can restart from there when you die. This would be useful for people who want to beat the game but are struggling.

Before I get anyone who wants to buy this thing... I first need to make it fun and solid. If it's not fun... nobody will care about checkpoints.

Definitely before checkpoints, I want to write some classes for saving the players progress. How far they've gotten on each level, and how many times they've beaten each level. This data would to to plists, but unlike the metadata, it would be read/write. Nothing too scary for that part.

If I design a bunch of levels and it isn't that fun... I'll either have to keep thinking and trying, or just say screw-it, time to release it for free.

I have been thinking of some other possible gameplay elements... Memory for example. These could be generated on the fly (look at me, having pun over here). Basically the game would show you a series of up or down arrows, then you'd have to remember (or just guess) which way to go, up or down. The incorrect choice would lead to a dead end. Instead of distance, this one could be scored in number of correct recalls (or guesses) you had. And because this would be random,  you couldn't just write down all of them from the last time you died.

yup yup.


idea for IAP

by midge 5. October 2014 22:04

Checkpoints for the harder levels.


Button me up

by midge 2. October 2014 02:32

I was pretty lazy today, and I procrastinated waaay too much tonight.

But, at least I did something. Just busywork and then  a little bit of thinking. I added a bunch of buttons to the level select screen.


Then I did some code reading to figure out what I wanted to do. I think I'm going to end up storing level data in a plist. I've used them before for other projects and they're pretty easy to work with. There's an editor for them right in xcode.

I've decided the levels are going to have a strict ordering, with the exception of an infinity level, which i'll probably refer to internally as 999 or something. It would use an infinity symbol, but this would not be first release. Above is my uninspiring current level select screen with text buttons only.

I'm going to replace these with a screenshot of the level with a number superimposed on that graphic. I'll eventually want to support more than one screen of levels, but I'll cross that bridge if and when I get to it.

I mentioned using plists earlier... one nice thing about that is they can be read globally... so I don't have to pass around level meta data from the level select view controller to the game view controller.

plists will probably be a good place to put player high scores and stuff. I haven't thought much about game center integration. I wasn't originally planning on doing it, but I may revisit it once I get closer to completion.

That's it for today!



All I do is win

by midge 1. October 2014 01:55

And by that I mean I've been working on the game over - Win State. What happens when you beat a level.

Picture unrelated.

I just found this one today and it cracked me up. Has your chuckling died down? Good, let us proceed with business then.

Confession time: I worked on the game a little yesterday. I like to post almost every time I work on the game. Even if I'm just doing code reading/planning or working on assets or whatever. Why was yesterday an exception?

Basically I didn't accomplish much and I got pissed off. Actually I accomplished some things but I ended up getting stuck on a stupid/perplexing bug that ended up being my own damn fault. Concluding the evening with frustration meant I didn't really want to write about it. More on that later. I had added to the "Win" screen which if you remember correctly was just a re-purposed "ya dead" screen. Nicer colors and different options like the "next level" button. I started working on the game over Win condition, which meant I had to abandon my earlier hardcoded constants for level length and use the length from the file length.

So this is where I got stuck. The level lengths were wrong and I had no idea why. They seemed to be about double on the test levels I had created and about +200 columns on the ones I read in by file. I had a lot of debug statements and the file seemed to be reading in correctly, and had the correct length there, but reading it a little later and it was longer. I assumed it was some stupid datatype conversion thing, or an objective-C print formatting thing. I found out what the real issue was with the debugger... I just had a block of code that ran at the very end of the function that tacked on part of a programmatically generated test level at the end =[. I had just completely forgotten I was doing this and didn't notice it before.

This was very early test code that I hadn't revisited in a long time. I think I would have found this much faster in .NET, just because I'm in that environment all day at work and I know the tools better. I shy away from the ios debugger because it's a little more of a pain in the ass to work with. I was relieved when I found the error, the program behavior made sense again.

After that, everything went pretty smoothly. Now when you get to the end of the level and you haven't crashed, you get the win screen. One slightly surprising thing is that I'll need to tack on the end of the level. In my test level, the hardest part is right near the end, swooping up a narrow cavern. Because there's no extra space at the end, the level ends before you even finish the hard part! This wasn't happening before because I had the (unintentional) programmatically generated test data tacked on at the end.

The project is actually at a really nice spot right now. The path to finishing this thing is pretty clear. I know there's more work, but here's what I think is left, off the top of my head.


  • Creating a class for level data not already covered to make it easier to pass level data around.
  • Make placeholders and buttons for all of the initial levels on the level select screen.... maybe 9 or so? Make sure they all can load their unique level data.
  • Decide how to store high scores and make them persist.
  • record high scores and display on the high score label while playing the level
  • Make the "Next level" button work.
  • Make any button I've forgotten about work, including preferences stuff. Remove unnecessary UI elements.
  • Add pause button.
  • Create/test levels (this is the doozy) iterate through until a good balance of challenge and fun. Get friends to test it.
  • Get app on physical test devices and solicit feedback.
  • possibly facelift textures/menus
  • make icons
  • ad-support
  • port to iPad version (decent amount of work around menus and core game display)
  • IAP to remove ads or maybe some unlockable levels
  • Think of level unlocking scheme
  • Publish
  • Roll in the riches, bitches.



Quick post

by midge 29. September 2014 01:16


I worked on the Level Over Win condition a little bit today.

That just means when you beat the level, a different screen shows up with some options which include going to the next level. You're supposed to feel good as opposed to the death screen, which will probably make you feel bad.

I Just tweaked the game over screen to show some slightly different text and changed the background color of the whole View to make it look "Nicer" when you win. I'll probably have something like a checkmark or a trophy at the end as well.

There's a "Next Level" button up top which doesn't do anything yet.

I'll probably have that go to the next uncompleted level... Or just the next level in the level list, whether completed or not. I  don't know if I'm going to enforce a strict level ordering yet.

The game still doesn't even detect when the level is properly over yet (Win). None of this stuff is too hard, it's just not terribly exciting either.

I felt tired today so I didn't put in too much effort tonight. As always, I think it's much better to put in a tiny little bit of time and get the game back on my mind even a little bit than to not do any work at all.

A lot of days of a tiny little progress do eventually add up.


The game can now read in level data from the level editor

by midge 25. September 2014 02:25


So I spent a little time making a test level in the editor before switching back to iOS to work on some code for reading in the actual level data.

One observation about the level editor, and I think this applies broadly to a lot of things in work/life... if you're making a tool for someone or some other task, don't actually think it's awesome until you spend some time trying to use it. Listen to the people who use the things.

Trying to make a real-ish level with the editor exposed all the nuisances of the unintuitive UI and gave me a number of ways of how to make it better. I'm weighing the trade-offs of making the tool better vs just hunkering down and working through the annoyances. I guess it depends how much time I plan on spending in the level editor. That said, making even a quick sub-500 block length level was pretty time consuming.

Getting back to iOS... I had to write code to read in the level data, which is just a single column of hex strings, each hexadecimal number is one column of blocks in the game. So one row in the text file is one column in the game. A pretty simple format.

I'm rusty on iOS file I/O but stack-overflow definitely came to the rescue here. I was able to find plenty of samples trying to do some variation of everything I needed to do, so that wasn't too tough.

I must say, it's pretty exciting to see the first "real" level data load up.

I have to make the starting levels very easy, you can die VERY fast in this game. I may make a lot of shorter levels to start off with. Currently, the logic only detects a death if you hit a block. If you hit the top or bottom of the screen with no block, you don't die. I kind of like that, even if it doesn't make much sense. It can be a way to add easier parts to levels.

I still need to decide what to do for the "win" screen and have to detect the winning condition. I had hardcoded LEVEL_LENGTH in a lot of places earlier, I need to make sure the win condition is updated based on the real file level length.

Yayyy. Good progress.


About the author

Hi, I'm Midge.

Month List

Page List