Level editor possibly done?!!

by midge 24. September 2014 02:35

I worked for about 2 hours tonight and feel like I made more progress than I had in any other single night in recent memory.

I thought the file I/O was going to be pretty easy, and it pretty much was. So now you can create the file levels, save them, and then open them again later.

I do of course need to test that the ios app can read these files in correctly. I want to make sure that the level that I see in the editor is the same as the level I see in the game. I did have an issue with the level showing up backwards after saving and then reloading it. Hopefully that's not an issue reading the data from files in iOS. I'll know soon enough.

The "fill under" and "fill over" modes were really good ideas. That is going to make level creation much easier I think.

I'm still wondering if I'll end up going to 64 bit ints for more vertical resolution.

I'm also wondering if the helicopter animation is small enough to allow for enough movement and fun gameplay. If not... I'll have to scale it down, and I may have to adjust hitboxes in that case, which would not be fun. We'll see.

Have a look at the pretty much kinda finished level editor in action:



I'm going to level with you...

by midge 23. September 2014 02:22

And by that I mean I'm going to talk about my not quite yet done but getting ever closer to done level editor!

I was trying to show a friend the progress I had made on it, and immediately I noticed an annoying bug. So I fixed that. I was using the spacebar to toggle draw/edit mode but that was firing a button on the page that cause a dialog to pop up. Whoops, annoying... but easy fix.

Today I added the functionality of being able to add/remove length to the level. This went pretty well. You can adjust the level size, no big deal. I tried up to a couple thousand columns in length and it seemed to work fine. Because I'm only displaying 70 columns at a time in the editor, there's no real performance slowdown for editing large levels. This was all pretty straightforward, and I'm happy with that.

I decided to be a well rounded (less rounded?) individual and do some gym stuff tonight, so that shortened the amount of time I had to work on things. I was hoping to get to file stuff but I only barely just touched that.

I hardcoded writing a text file to a predetermined location. I might actually make a nice UI so that I don't accidentally save over the wrong level file while I'm working on them.

A few ideas:

Drawing while scrolling seems like a great idea. Getting mouse info while handling keyboard input isn't super intuitive so I may have a keyboard moveable cursor as well so you can draw while scrolling. Or I may just fix it the RIGHT way and figure out how to get mouse key state and location while scrolling the game window by pressing a keyboard key.

Some "fill under" and "fill over" options would make level creation much faster. Almost ever level will have a ceiling and floor, like in a cave. If I just want solid floors and ceilings I can use this option. But I can also draw stuff in that area.

I may have text written in the level with hints like "up up, down" written right in the level as arrows and then have a series of choices where they have to go up twice and then down or they'll hit a dead end.

I also think that ints on most ios devices now are 64 bit. If true, I'll modify my game level to have a vertical resolution of 64, which will look better on the ipad anyway. I should probably figure that out somewhat soon, before I invest massive amounts of time in level design.

I also need a "win" screen for when people beat levels, and then move them onto the next one. I need to think about that more.

So I worked worked on some stuff tonight, and apparently it was great.


And if you don't know, now you know, midgaaa

by midge 22. September 2014 02:15

I'll try to keep this update short. The level editor is in pretty good shape.

I had to go home for some family stuff this weekend, so I didn't get as much time as I wanted to work on all this stuff.

I fixed a mildly annoying bug where when you were drawing on the level editor, it would clear the last tile you set. So if you're dragging the mouse with the left button down, it would draw draw draw, and then when you finished it would quickly delete the last block.

I refactored a little bit and cleaned up some code. I updated some of the labels on the form also to show info about the level.

The biggest single thing I added today was the feature of scrolling around in the level to edit different parts. That was surprisingly easy. Worked like a charm.

I added controls for adjusting the length of the level when you're editing it, but didn't actually make it do anything yet. Making those actually work should be pretty easy.

So all that's really left for the level editor is allowing the user (me) to adjust the level size while editing. And then after that it's reading and writing the files of level data. That's it!

One annoying thing when I was trying to wrap up tonight... I got the scrolling and all that other stuff working, then I went to add the adjust level length stuff and BOOM, the scrolling stops working. That perplexed me briefly because I didn't think I was doing anything that would affect the scrolling.

It turned out some of the new controls I added were intercepting the events that were intended to be handled by the form. "Oh Imma just intercept these events and then do nothing with them.. deal with it". Jerk move, controls. Fortunately, stack overflow was helpful and the fix was pretty simple. I could just set a property on the parent form that would force the main form to get the keypress events.

Here's a pig in boots.


Ohhh yeaahhh! Level editor progress

by midge 20. September 2014 00:49

It was a good idea to ditch the buttons as blocks approach.

After the buttons, I was all like:


But then I got my groove back (stella had it), and then I was all like:

Kool aid man added for emphasis.

So basically I've made a very simple paint program that will double as a level editor that can export the levels in any format that I like. I got the drawing/erasing part down. There is still non-trivial work left, but it's not a ridiculous amount. I usually underestimate remaining work by an order of magnitude, so it's probably safe to assume that there is a small shit-ton of work. But only a small  shit ton.

What's left on the level editor: It won't support scrollbars, so I'm just using keypresses and maybe buttons to move around in the level. I also have to support being able to add or remove length to a level.

Then of course, there's the whole save as file format, and opening files to edit them to make this thing useful. I'm very excited about this... the level design is going to be fun.

I've realized that there are much smarter ways to store/compress level data than what I originally came up with... but I don't care about that, it's just not important.



Milk was a bad choice

by midge 19. September 2014 02:22

Choosing to use a bunch of buttons for the level editor may also have been a bad choice. It's funny sometimes what seems like a great time-saver in the moment ends up just being a pain in the ass.

I thought using buttons would make the event handling much easier. I spent a lot of time today trying to figure out why the buttons couldn't tell when the mouse was down. Apparently passing states amongst controls is obnoxious in older versions of .net.

There are newer, much simpler ways to do it, but I don't feel like installing a new version of visual studio at the moment.

So what I'm probably going to do... Just have one big drawing space right on the top of the control. Ditch the buttons. This might be fast enough that I can bring back the scrollbar and render more screens at once.

We'll see. I just have to try it out.

So tonight was a little frustrating again. I just found a bunch of stuff that didn't work that I assumed would *just work*. I did a lot of windows forms development in college and shortly after, but honestly I hadn't touched this stuff in a while. Most of the .NET development I've been doing is web lately.


Ghetto level editor, all up in this midge

by midge 18. September 2014 02:15


So I'm trying to use a whole bunch of buttons as a level editor. Stupid and slow? probably and YES, thanks for asking.


I really don't want to spend too much time on making throw away tools that I'll only use for this game.

I was going to just render ALLLL the buttons and scroll through the level, but rending the buttons is painfully slow, so I'll probably just do a single screen at a time with some prev/next buttons.


This still, obviously has some work left. I haven't finalized the level file format, or done anything with reading from or writing the files.

I have to do something to make the editing faster or I'll get RSI from clicking all these buttons. Probably just mousing over while the mouse button is down, like a paint program.



Level editor research

by midge 16. September 2014 01:22

So I'm either going to write my own very simple level editor or try to find a suitable tool. Most of the ones I've found seem to be overkill for what I'm trying to do. Maybe I'm just saying that because I'm too lazy to learn a new tool... I'd rather just write my own. Sometimes programmers are weird kinds of lazy. 

So tonight was just research and a little coding for a level editor prototype. I'm doing this part on windows in C# because that's my stronger language/platform. This won't actually be part of the game, just something to help build up the level data.

To be continued...


I've been up all night, tryna get that rich / I've been work work work work workin' on my shit.

by midge 15. September 2014 01:57

So I put in a decent amount of time today. I probably worked on the game for about 4 hours.

Most of that time was trying to figure out what the hell was going on with the Game Over state getting messed up. I ended up using the protocol/delegate I mentioned last time, but it still had issues. It turned out there were some problems maintaining game state, that were just my logic errors. I has a flag for "IsTouching" to detect when the user is touching the screen (helicopter goes up). This wouldn't get reset when you died, and it got stuck on TRUE, which you could not undo. So that means when the level restarts the helicopter hits the roof and you die. Once I figured that out and fixed it, it worked fine.

I should really go through and clean up a lot of the code because I'm sure there's some crap in there from all the things I tried that didn't work. I'm not sure if I care that much anymore. I'm not making a beautiful piece of art, I'm just shipping my first shitty game. Ship it!

So I'll probably clean it up more if the cruft seems like it's getting in the way of finishing up, but beyond that, meh.

After getting that working, I wanted to Add something so I'd feel a little more accomplished. I added a back button to the level select screen, because I realized there was no way to get back to the main menu from there without playing the game.

Then I worked on making the level select buttons actually import level data. I'm not reading in level data yet, but I did test having the level select buttons draw different color levels. That worked pretty much on the first time.

The level data will probably consist of:

  • block color
  • background color
  • all of the level tile data
  • scrolling speed.

I haven't worried at all about the menu art yet, that will probably be one of the last things I do.  Making the actual level data... uh you know, the game. Will be fun. That's just design and coming up with something fun and testing the hell out of it.

Good progress.



Sometimes you just find a bunch of ways that don't work.

by midge 14. September 2014 04:13

That's basically what happened tonight.

I'm working on resetting the game state when they player dies and they want to start over. Sounds easy, right? I had it working from the storyboard buttons, but I was getting exceptions when trying to do it in the code (how it will actually happen in the game).

After trying a few things that didn't work, I did some googling. basically I need to user objective-c protocols and delegates. I think they're like C# interfaces.

I'm using a navigation controller stack to display the different screens. You can push different views onto the stack, and then pop views off to go back. Sending data to one of the views you're about to push on is old news for me, I do that all the time. That would be passing data forward. Apparently, passing data backwards is something I don't do too much. So this would be when you are about to POP your current view controller off the stack and set something in the view controller you are transitioning to.

I don't think it's that hard to do, but I'm just tired. I'll read up on it and get it out of the way quickly tomorrow, hopefully.

burnin' dat midnight 4am oil.



Try this tomorrow... it might be easier than the protocol stuff if it works. I tried calling the buttons target method directly from code already (first thing I tried) but for whatever reason that didn't work.


specifically "[someButton sendActionsForControlEvents:UIControlEventTouchUpInside];"


You had one job!

by midge 11. September 2014 02:13

And that job was to reset the gamestate of the level after the player dies and clicks chooses to Retry.

And just as I started typing this I realized a slightly better way to do that. After they die... I should reset the gamestate, but not draw the level again, then go to the "game over... retry screen".

Currently we just leave the gamestate where it is and go to the game over menu... that's when we reset the gamestate. The downside of this is ever so briefly you see a flicker of the last place you died before your new game starts. Not a big deal, maybe a subliminal way to remind the player of their impending doom, but probably not an ideal experience.

So I may improve this a little next time, or I'll just move on and come back IF it annoys me later in the process. Damn the torpedoes.

So yes, this blog post is a little mundane, but this is the majority of the stuff game development is made up of. Lots of moments like these. This is why there are probably so many unfinished games. I think  a lot of people have the idea that making games is just as fun as playing them. #ItsNot. But it is definitely more rewarding, a more meaningful kind of rewarding than playing games, I think.

But it can be kind of tough switching from early on in a game's develpment cycle... where you go from NOTHING to, "Wow, look at that! I made some of the cool stuff show up and it looks pretty good!" and then back down to a more tedious yet deliberate pace. The last part isn't nearly as exciting, and I think that's where the test of work ethic/character is.

Any questions? requests? comments?

Ah, yes, from the man in the parked car. It looks like you may have a request.


He's asking for two. He seems to think I'm called Utah.

Oh well, I'll see what I can do...






I feel like we're done here.


About the author

Hi, I'm Midge.

Month List

Page List