Quaintbrush

Jesse

  • Posts: 102
Yes, I'm using Game Maker because this is for the Ludum Dare competition -- as part of the rules I have to release the source code of my submission. Because I can't release the source code for a Stencyl project, I had to use GM.

I designed the levels using a Stencyl-compatible grid style, instead of Dimension Shift's original smooth terrain. This way, it'll be easy to port everything over later on.


Code: [Select]
Checklist
- Make a boss
- Menu stuff, and pause screen stuff: end game / skip level
- sound effects, background music

edit:
http://www.mediafire.com/?xjv4vyzpcta17k1

ALL levels are now complete. Some of the later ones can become very frustrating. Let me know if I should tweak something.

« Last Edit: May 01, 2011, 04:57:00 pm by Jesse »

Jesse

  • Posts: 102
Whoaa. After an exhausting 48 hours, Quaintbrush is finally complete. I'm really glad with how it turned out given the limited time. The whole experience was really intense.

You can check it out here (Windows only):
http://www.yoyogames.com/games/173430-quaintbrush

This should make developing the Stencyl version enormously easier.

Let me know what you think of it! :)

« Last Edit: May 03, 2011, 07:43:53 pm by Jesse »

Jesse

  • Posts: 102
(taken from my post on ludumdare.com)


Wow. This weekend was a really exhausting one. This was my first Ludum Dare competition, and I’m really glad with how it turned out. The game I designed was Quaintbrush, a puzzle-platformer where you can change the world around you using different brush colors.

I programmed everything in Game Maker 8.1. I bought GM 8.1 Pro just hours before the competition hoping to take advantage of its new features – it turned out that it was really buggy. I lost around an hour and a half of work because my game file was randomly corrupted. A lot of times when coding, I'd get random 'unexpected errors' when my code clearly made sense. This didn't happen in the earlier GM version, and it kinda scared me, so I made sure to back up often.

I started the competition right off using Paint and drawing a stick figure animation. I’m no spriter, to be honest. To achieve the stick figure’s running, I used Super Metroid’s Samus sprite as a reference for the arm and leg positions. Even though both characters look totally different, I think the end result for my animation ended up looking decent. This was the only sprite that I actually drew pixel-for-pixel, aside from the paintbrush cursor.

For the rest of the graphics, I used Photoshop. I had a broken tablet that had been sitting on my desk for a few months – the HP tx2500z. These tablets are awesome to use, for like, a year and a half – then like half of them are wrecked beyond repair due to a crappy manufacturing job that melts the GPU. I decided to give the thing a shot, and to my surprise, the tablet actually turned on.

I was first hesitant with using it to draw backgrounds because if it crashed in the middle of the process, everything would be over. I had to sketch all twenty background in one go and race against the clock – not only in terms of the competition, but also in terms of my crappy tablet. It was really intense. In the end, I think it really paid off. The little doodles on the walls were one of the highlights of the game, according to most feedback I got.

The doodles served two purposes: first, they were a really neat way to guide the user. A lot of things were tough to explain without actually pointing out a location on the screen – so this sort of solved that nicely. The doodles also added some more character into the game and provided some humor. I think without it, the game wouldn’t have felt as complete.


In terms of level design, I designed the first ten levels with a pencil and paper in around an hour, and the last ten in around an hour and a half. I really had a lot of fun working and exploring the new concepts I developed. There was a lot of room for extra mechanics – I’m definitely sure I could’ve expanded the levels to around 40 or so if I had the extra time. The two biggest mechanics that didn’t make the cut were an erase feature and the gray brush.

The erase feature was pretty clever. It revolves around the idea that you drew something with your paint, and got one step towards completing the level. However, now that same paint you drew is actually hindering your progress. If you take a look at level 11, that was one of the first levels that was supposed to use the erase feature. The switch on the left wouldn’t appear until after you crossed the bridge with the yellow paint. Once you hit the switch on the right, a switch would fall from the sky and fall into the yellow paint. Because its timer would then be sped up, you’d need to erase the yellow off of it.

The second feature that got cut was the gray brush. This is a really, really, neat brush in my opinion, but I didn’t have enough time to expand on it. The gray brush acts as a sort of ‘Stealth Fog’: once you draw on it, nothing in its area makes a single sound. Furthermore, enemies are oblivious to your position if you hide in the fog. If you cover an enemy in the fog, they become disoriented. This would also make for some really neat sound-based puzzles. For example, a certain door could only be opened if it hears a sound – but you have to use the gray brush to cover the object to get somewhere in the first place. You would then need to erase that fog, and then activate the sound to open the door.

Although I’m generally pleased with how the game turned out, I have two disappointments. Firstly, I didn’t have enough time to compose any music. I’ve never composed before at all, so when the clock was ticking and there was only an hour or two left, I made the decision to leave out music because it wouldn’t be worth it trying to learn how to compose / experiment in those crucial last hours. Secondly, the boss was really rushed. Really. I made him spontaneously in around twenty minutes. I’m a little proud of myself for that, but I’m still not too happy with it because there’s so much I *could’ve* done with the boss. One idea I had was a four part boss battle, each one using a separate brush color. The last part used the purple brush, and that was when you would finally defeat the boss.

One of the magical experiences that I felt the game had been discovering some hidden uses of brush colors. A lot of them aren’t really explicitly stated at all. The red brush actually helps heal you faster – again, it “prolongs” things, so it would make sense for it to prolong your life. The red brush also makes turrets shoot and aim slower, and it also decreases their accuracy. The yellow brush’s effects on painted objects are the exact opposite of the red brush. Furthermore, the yellow brush sets drones off course – -this was something the gray brush was originally supposed to do, as a matter of fact. The blue brush I think had the least ‘hidden effects’ – however each of them were really awesome. On level 19, try using a blue brush instead of a purple brush on the spawning drones. It’s amazing to see them all falling up one by one.

Overall, I think this experience really changed the way I make games. I’ve learned so much this past weekend, and regardless of the competition results, this game really was my “prize”. I almost can’t believe that I made something like this. I want to thank Ludum Dare for making this happen.

« Last Edit: May 03, 2011, 07:48:53 pm by Jesse »

Jon

  • *
  • Posts: 17526
Ver nice writeup. It's writeups like these that we can analyze a bit and see if we can tweak and refine the workflow for Stencyl to match the needs of game developer better. Granted, optimizing for a 48 hour contest isn't exactly what we want, there's still a lot of takeaways here that apply to game creation as a whole.

If anything, the takeaway is the experiences you acquire by having taking something from start to finish and that there are still quite a few among us who haven't seen that whole process through. Whether you are an artist or not, it's something you have to go through to understand and appreciate.

Jesse

  • Posts: 102
I started off a port of this by grabbing the Jump and Run kit and resizing it. 
http://www.stencyl.com/v10/game/play/2144

Already, with almost the absolute bare minimum - four walls, a player and two platforms, the game runs ridiculously slow. I'm hitting around 33 fps. Throw in a paint actor or two with the left click button, and that easily drops down to under 20.

Is that the average FPS of the Jump and Run kit? o.o

Epic428

  • Posts: 1118
I tested the Jump and Run Kit, and I experienced absolutely no slowdown with it.  Unfortunately, I am unsure of why you would be encountering this. If you would like, since it is in a very basic form, I can take a look at it and see what might be causing this.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Jesse

  • Posts: 102
Thank you, the game has been uploaded on Forge.

Epic428

  • Posts: 1118
I see why it is slowing down. I highly recommend setting a timer in the "Draw Paint" behavior. The game at first runs at a great 60fps, however, that behavior creates an actor every frame the mouse is held down.

A simple circle that I drew printed out 200-300 actors being created and added. This causes the tremendous slowdown.

Adding a timer would create an actor at a set interval resulting in far less on screen, but most likely enough to still at some point cause some serious slowdown. In addition, the timer could possibly result in the paint not looking like it would if you were drawing with a regular paintbrush in Paint.


In the end, your best bet is to figure out an alternative to how the paint is drawn on screen so that it looks good, but doesn't affect performance.

Edit: if you will give me the weekend to work on it, I will make an attempt to try and integrate the library, Jon directed you toward in another thread, into SW via code behaviors. If I can get it working properly, then I can share it with everyone, and possibly at some point it can be integrated into the engine itself.

« Last Edit: May 05, 2011, 07:37:07 pm by Epic428 »
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Jesse

  • Posts: 102
That sounds great, thank you! :)

However, even without drawing anything, I'm still getting the 35-40 FPS for some reason, instead of starting off at 60 FPS.

Epic428

  • Posts: 1118
Interesting, I'm wondering if it has anything to do with your computers specs?

Also, integrating this set of classes is going to be A LOT harder than I expected. The primary reason is that it is using classes from WCK, which I don't know that Stencyl is using them, and if so, what I would need to use to import them. I may have to end up looking into rewriting them so that they are compatible, but then that would take a lot longer than I'd hope for. ( I may have to rewrite some things either way)
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Jesse

  • Posts: 102
I'm getting a solid 60 FPS on the original Jump and Run kit. Aside from adding the one simple drawing behavior, the only changes I made were in the screen / tile size. I'll further examine the cause of the slowdown on the engine -- if it's working fine for you, it might just be something on my end.

Code: [Select]
Dell Dimension 9100
Processor Intel(R) Pentium(R) D CPU 3.00GHz, 2992 Mhz, 2 Core(s), 2 Logical Processor(s)
Installed Physical Memory (RAM) 2.00 GB


Again, thank you for helping to look into this.

Epic428

  • Posts: 1118
Your specs seem fine, so unfortunately, I don't know that they would be causing the issue. A possibility could be that you have 2GB of RAM, but that is unlikely.

I'll take another look to see if there is anything else I can spot, but until the actual drawing takes place, I don't see any any loss in frame rate.

Edit : press ~ to see if you have any errors in the console?
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Jesse

  • Posts: 102
None. I'm still getting 24-31 FPS. :/


EDIT: Neat, QB just got featured on jayisgames.com:
http://jayisgames.com/archives/2011/05/weekend_download_184.php

« Last Edit: May 07, 2011, 01:18:40 pm by Jesse »

Epic428

  • Posts: 1118
EDIT: Neat, QB just got featured on jayisgames.com:
http://jayisgames.com/archives/2011/05/weekend_download_184.php

Congrats Jesse!  Are you still having issues with the FPS? What have you tried to isolate the problem?

Also, I have been thinking about how to go about the drawing (to increase performance), I have to sit down and play with it quite bit, but if, and when, I figure something out I will let you know.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Jesse

  • Posts: 102
Found it.

As soon as I resize the game from 640x480 to 960x640 (iPhone resolution) the game drops a good 20 FPS.