Basic side scroller code

Okay here’s something from left field.

I’m getting the sprites up and working, and just for the heck of it I made a version where, every frame, every single sprite randomly changes to any other sprite.

It’s nuts, but kind of fun, and oddly I’m much better at the game in this mode!

I think I did it!

The graphics look 95% as good as the original, I’d say.

This was way too much work, and I really got obsessed with it. I have responsibilities, man! Now my wife is starving, and my children are crying, but who cares? _ I got this Codea project under 2 MB!_ My legacy is secure.

@West, you’ll notice it’s not perfect, there was some scaling and positioning stuff I couldn’t get just right, but I think I got close.

If anyone is interested, and I guess even if no one is, here’s how I did it.

  • First I counted how many art assets were in the original.
  • Then I tried to find the right dimensions for a PNG that would compress well enough to keep the project under the target size. 1200x1200 seemed to work.
  • For my first pass, I took every single asset, no matter how large, and shrunk it down to fit in 120 x 120 pixels.
  • Many of the insects are composed of several overlapping parts, so it took some fiddling to devise a system that would keep the separate parts aligned correctly inside their own little squares. This took a while.
  • Once I shrank and positioned everything, I put the spritesheet asset in the project folder, to see if the project still compressed acceptably, and to my moderate delight, it did.
  • Having no idea how to actually code a spritesheet, I found a project in the forums that showed a super easy way to do sprite sheets, and I moved that code into the foggy bummer project, and got it loading all the sprites.
  • I discovered a weird thing about importing art, in that if you don’t un-check “retina” when you import a photo it will be imported at half its original size, which is oddly counter-intuitive. I kept getting crashes because I had written my sprite-loading code to go off of a 1200x1200 file, and if I forgot to uncheck “retina” the actual file was 600x600. I think what’s going on under the hood here is that actually two copies of the imported art get made, one at half size and one at full size, to follow Apple’s convention for image resources in iOS. For some reason Codea only exposes the half-size one to us in the asset browser. And the odd situation that results is that it looks like you have a smaller image file, but because it’s actually two files it makes your compressed zip larger than it is otherwise. Yes, the smaller file makes your zip larger.
  • Now I wanted to see how the sprites looked. Since it would take a long time to go through the code and put the new sprites in all the right places, I wrote a single line that drew a random one of the new sprites, and I pasted that line everywhere in the code that anything was drawn. Effectively I made every sprite into every other sprite. This is the ‘Chaosgeddon” project above. It’s absolute madness but it’s also kind of fun.
  • Seeing the sprites was a mixed bag. On the plus side, almost all the sprites looked perfectly good at 120x120. But on the minus side, the ones that looked bad looked really bad, specifically the larger ones like the tree and the snail and the hedges.
  • So I had to figure out a way to get larger sprites into my nice little 1200x1200 pixel file. But almost every square was already taken up. I noticed that there were a bunch of images that even at full size were already much smaller than 120x120, such as all the bullets, and the bonus icons, and the little explosion animations, etc.I realized I could subdivide each of my 120x120 squares into four 60x60 squares. I started collecting all the small little pieces into grids of 60x60, which eventually let me get 160 sprites into just 40 squares. Now I had an extra 120 squares to fit larger sprites into.
  • After a lot more fiddling and adjusting and jigsaw-puzzling, I wrangled most of the large sprites into the spritesheet at something close to their original size.
  • Now I had to get these into the code. The easy part was writing a routine to import the 60x60 grids, because I just adapted existing the code for the 120x120 grid. The hard part was those larger sprites. I had about 11 irregularly-sized large images, and I had to hand-code all the coordinates for importing them, manually counting out the x, y, width, and height values for each. I made several mistakes here that were real headaches to track down later.
  • Now I was at the final stage. I’d chopped up and arranged and rearranged and shrunk and enlarged and imported all those sprites, and now I had to put them at the right places in the code. This was exactly the situation the 80/20 rule applies to. 80% of the spritesheet sprites just easily replaced the existing ones, like butter, but 20% were so wrong it hurt, and the majority of the rest of the time was spent fiddling with that 20%. Specifically the freaking dragonflies and freaking butterflies and freaking hedges were a huuuuge pain to get right.
  • But happily, using the larger sprites totally worked. They look great, to me. They are slightly scaled down and then up, so they’re not perfect, but they’re darn close.
  • In the end there were some things I just couldn’t get right, and had to settle for good enough. The dragonfly wings are still kind of weird. I actually don’t know if the cat works at all because I couldn’t play that far in the game! And I don’t think all the sprite sizes are exactly the same as they are in the original, but they’re close, and I’m satisfied with it.

i wish we had a way to give a post thumbs up or a like, so here’s my kudos to you for putting so much work and troubleshooting into this @UberGoober

@UberGoober great job. You have a lot more patience than me on this!

For coding the spritesheet - there was a simple example included within the code itself - the explosion was a sprite sheet in the original.

Set self.invincible to 20000 in the Bee class to give you invulnerability for a longer period of time - that way you can cruise to the cat end of level boss. Unfortunately the sprite for the cat isn’t ported correctly.

Another thing, the order of the power up icons is wrong - the power awarded is still ok, but the symbols are presented in the wrong order.

Now this has moved from being a personal project only on my iPad, there may be issues around attributions of the assets. All the original images were generated by me, sometimes from photos I’d taken, but sometimes curated from the web. (My process was to load into Inkpad, draw round and set a mask) Not sure of the correct attribution for this, but if you see one of your images being used and its an issue let me know (I think it’ll be OK but credit where credit is due).

The explosions were derived from some excellent tutorials here: https://blog.studiominiboss.com/pixelart

@West @UberGoober Amazing work both of you!

I just thought I’d let you know that I’ve added @UberGoober’s latest ‘Foggy From Sprites’ project to the new community repo app I’ve been working on. With zero modifications to the zip it downloads automatically and runs perfectly! As far as I can tell at least…

I’m hoping to have a large assortment of demo projects, programs and games on there in the future but If you do have an issue with it do please let me know and I’ll take it down. Just wanted to make you aware.

Oh and @West I’ve also added your recent ‘Fish’ demo too :smile:

@Steppers - just a note of caution, uploading exclusively to the community repo could mean some forum members may not be able to download.

Also, as we have seen over the years, updates in Codea can frequently result in incompatible projects. For old timers that’s not an issue but for recent or inexperienced forum members that could, later, be an issue (unless author’s are willing to update and re-upload).

@West thanks for the invulnerability tip. And the cat tip. I fixed the cat.

I wonder if you could help me fix a couple other things.

  • The dragonflies are invulnerable, is that how they’re supposed to be?
  • I couldn’t get the legs on the flying ladybugs positioned right.
  • When creatures that use wasp wings are flying to the right, their wings are positioned wrong and don’t even touch their bodies.
  • The dragonfly wings are wrong too, but I think they move fast enough that it’s not noticeable.
  • There are some sprites that don’t seem to be used, like the bullet with the little crackles on it, the blades of grass, the wasp body that’s all one sprite, two of the daisies, and the honeycomb. Are those used somewhere and I’m missing it?

There’s also a gameplay bug where once in a while the sprites seem to jump slightly from one place to another. I don’t know why changing art assets should affect that, so I must have accidentally busted something.

Is it possible to get some help on these things?

@Bri_G I get that, I wouldn’t want it to be the only place to find a project but it could help newer users find interesting examples from the community easily without trawling through ancient forum threads. I think some sort of automated test framework could be useful in the long run to spot projects with potential issues after an update to Codea but that’s a job for another day.

For the time being, I’m already doing some automatic substitutions for the old ‘Project:’ asset paths to convert them to the newer ‘asset.’ system. At the same time, the projects this downloads are available exactly the same as any other on Codea so if something is broken it can be edited & fixed.

@Steppers - just playing devil’s advocate, anticipating problems. Could be quite a burden as the library grows. I hope it takes off and does well. Thanks for listening.

@UberGoober The dragonflies aren’t invincible. They have 50 “hit points” which are set by self.hp in the Enemy class. Each bullet that hits an enemy removes 1 hp. The third power up along gives duel, triple, etc bullets for each time it is selected. The “super bullet” by holding on to the bee to build it up, then releasing will take a lot more hit points off.

The wing & leg positioning is down to the way I originally designed the assets. Purposefully these images were bigger than they needed to be but were aligned so that they could use a common x and y position. When you have ported them into a single sprite sheet you have lost this implicit relative position information. You will probably now need to add it explicitly back in by adding the appropriate offsets to each image. The attached small program allows you to explore the offsetting for the wasp and its wings. The legs will be similar.

For the butterflies and dragonflies, the wing movement is faked by squashing and expanding the image along one axis to give the impression of the wing coming out of the screen.

Having said that the original code is HORRIBLE! It worked to allow me to the rapid prototyping and exploring, but I never originally intended it to be shared. If investing any time in it, I would be looking at refactoring it first, and if I were doing it, I would go back to my original, non-sprite sheet version. The only reason for putting it into a spritesheet was to share on the forums, and specifically to fit within the 2MB limit. Chasing down bad code seems to be counterproductive, and you have the original up and running and don’t think there is the wider demand.

However, if you are learning stuff and it gives you a springboard - fill your boots and I’m happy to help.

Lastly, yes there are probably a few additional sprites which were never used. I remember the honeycomb being some crazy idea I had for a maze tunnel bonus section.

@Steppers - no problem sharing it on the repo - is there a size constraint like to forum, or could I post larger projects to it? I’ve not had the time to look at it, but will hopefully get time over the weekend

@West It should have less strict size constraints than on the forum. The limit GitHub itself will apply will be 100MB per file, so technically you can probably even go above that if the project isn’t zipped and you have no single file above 100MB.

Oops accidentally double-posted.

@West I know all about the placement of the sprites relative to each other, or most if not all, and I think I made mention of it in my description of how I made the spritesheet. That’s why almost all the creatures are put together correctly—I followed your placement pattern. Once I figured out a system to preserve your placement that was very helpful.

That’s why the issues I asked about are the ones that seem be special cases that purposefully break those patterns. The flying ladybugs, for instance, re-use the sprites for the wasp legs, but at least from looking at the original game it looks like the ladybugs have those legs placed differently. In theory it should still just work, but it doesn’t, which is why I wondered if you could help.

The same goes for the wings. When the insects are flying to the left, all the wings line up correctly, and again that’s because I followed your pattern. So again, in theory, since they line up when the bugs face one direction, they should also line up when they face the other, but they don’t.

There seem to be places in the code where you make special accommodations for wing speed and rotation and flying direction, and I figured the problem must be something I need to address in there, but since I don’t really understand what that part of the code is doing, I wondered if you could help.

I totally get having no particular interest in going back and picking apart code that you wrote long ago, and barely remember, and don’t think much of from the perspective of all you’ve learned since then. That makes total sense.

But I have to admit, at the same time, I’m surprised to hear you say the code is so horrible. At the beginning of this whole post, you put the original Foggy Bummer forward as a helpful template for anyone who wanted to make a side-scroller of their own. In all honesty, part of why I was interested in doing this is because that seemed like a great idea to me. And if people were gonna do a forum search for such a thing, and find this thread, I thought it would be good to have the most up-to-date version of that template available right here.

@UberGoober horrible is perhaps extreme, but in the very first version (posted several years ago) I took care to try to explain what each part was doing by adding in comments and putting it out there as what I thought would be helpful. IMHO the spaghetti code of the most recent code wasn’t up to the same standard (in terms of cleaning it up and making it understandable) for the purposes of putting it out there for wider consumption as helpful. Looking back on it there are bits that make me wince. For example, the code to draw the four different butterflies - the same code block four times, but with the name of one asset (the wings) changed! I don’t regret it - it was part of my learning journey - but wouldn’t presume it would be helpful to others. Case in point is the issue you are encountering - it’s poorly documented/constructed thus leading to confusion!

Hope this makes sense?

To address some of your other specific questions:

The ladybird legs - no idea why I’ve reused the wasp ones - my best guess is that I copy and pasted the wasp code and forgot to delete them (or didn’t have appropriate ones). In hindsight they add nothing and probably could be deleted. I do note in your updated version you are pointing to the wrong sprite in the table for the wings - line 333 you are using [27] and should be using [26] so you get an extra thorax instead of wings under the ladybird carapace

The glitching and offset wings is something to do with the the butterflies - if you stick on invincibility and let it run, you will see the been jump when the first butterfly wave comes along (and any butterfly wave). I strongly suspect this offset is also causing the wings to offset for the reverse waves. It’s getting late here but I’ll try to investigate further tomorrow.

OK - think I’ve sourced the problem - in my original I switch to spritemode(corner) then back to spritemode(center) at various points, but it looks like you’ve removed a bunch of the spritemode(center) commands leaving it in corner mode. This will result in offsets appearing

For interest, here is a stripped out butterfly wing example. You can see here a baked in problem with my original - the position of the wing sprites is slightly different for each one which makes some of them a bit wonky! Going back to the code, I can see the same issue is present there, but they are so small and fast its not so noticeable.

@UberGoober some minor tidying up:

Line 412 in main - the correct order of the bonus images should be:
local bonusIndexes = {74,84,75,76,85,86,87,77}

There is something up with the rainbow sprite [84] used for the invulnerability glow - it’s a lot smaller now and looks more like a ring.

In the butterfly drawing code I had:
Rotate(60)
Rotate(-60)
Ugh!

@West yes I had particular trouble getting the butterflies to look right. I just could not grok getting the placements adjusted properly with one sprite going off the corner and the other one going off the center. I had to get them both on the same orientation to make any sense of it.

Fwiw I did notice the wing positions were misaligned when I did the spritesheet and I tried to correct it as much as I could.

There might be nothing wrong with the rainbow sprite, it might not be reduced in size at all; I think for some reason the bee sprite is enlarged, actually. I didn’t try to fix it because I was afraid I would mess everything up.

Here’s a cleaned-up version incorporating the changes @West suggested. Gone are all extraneous comments and print statements made by me, West, or Codea itself.

West, you really should give yourself a lot of credit for this imho. Everybody here posts so much great code but it’s rare something so finished gets done. Sure it’s not a full game, but it’s got nice animation, nice art, varied enemies, power-ups that unlock different abilities, parallaxing, enemies that attack in different formations, and fast-paced and well-balanced gameplay that ably delivers the panic and exhilaration of a good bullet-hell shooter.

Even the fact that the code could be better (I did notice the redundancy of the butterfly definitions now that you mention it :smile: ) is a good demonstration of the value of being productive over being perfect.

In the real world, it’s not how good your code is, it’s how good what you ship is, and this is good.

Updated on Codea Community Repo.

I agree with you there UberGoober, this is a fantastic piece of work. It’s not always about how you get there but what West has here is a fine example of a game. There’s a reason it’s currently my goto when testing this WebRepo stuff :smiley: