Clean-Up Crew

I've started on a thousand projects both on the NES and in C++ for the PC, but nothing got anywhere and I think it's because I'd never share anything when I worked on it, so I didn't have any kind of proof of progress, leading to no motivation.

This is probably going to be another project that I start and never finish, but this time, I'm making a thread on the off-chance that constantly posting about progress, no matter how minor, might help.

My new project is a 1P and 2P co-op arcade-style game called Clean-Up Crew. Sorry for another static-screen homebrew project, but not every game can be a multi-directional scrolling platformer.

You're given a building, and in the building is a bunch of stuff that needs to be cleaned up. For example, trash on the floor that you need to sweep up, garbage cans that spit out enemies (which you need to whack with your broom and then close the trash can with a lid). Some buildings can have different tasks, for example, windows that need wiping, floors that need mopping, some kind of gimmick that needs to be satisfied, some kind of gimmick way to clean up, etc.

The tone of the game is just hijinks, you're two doofus guys who are hired when there's literally no alternative, the game won't take itself seriously, you can hit each other with your tools (accidentally or on purpose), and there's no overarching storyline or anything, it's just hey here's a 2P game we can play alright cool.

Order of business #1 is some art I drew to visualize this idea, which is attached. Anything in this thread is fair game for constructive criticism, as well as feedback. I'm sometimes arrogant, but even if I think I know everything, I still want to improve at what I do.

I also finished walking animations for the character, I'll post those when I'm done poking at them. Pixel art, especially animations, is a lot of poking until stuff looks right.

Some names for the two player characters would be nice... I got this game idea while I was bored at work, and the original names I came up with were "Pipi" and "Pupu". Pipi & Pupu's Clean-Up Crew. Although I got a kick out of that, some different names would probably be better.

Here's the walking animations I mentioned. The side facing sprite, I'm happy with. The front and back facing sprites still look kinda weird (particularly the head, the body's fine), so I'll be poking at them in the future.

I think the main problem is the head wobbling.

The way it flips back and forth, or the way it just moves left and right? The idea is that he's comically chunky so he waddles, but maybe the body doesn't waddle enough to make the head movements make sense?

It's the way his head shifts horizontally. His body isn't even moving that much, just his head.

Looks like a fun little project. Looking forward to progress updates.

It's a step closer. The main thing I was unhappy about was the fact that the face didn't look like the side view. Still needs some work though.

This is so cool!


Will there be any rakes involved in this?
http://st.depositphotos.com/1014674/339 ... a-rake.jpg

I think it would be cool to have to pick up the cleaning supplies (broom, mop, dustpan). And walking automatically pushes whatever trash is on the floor. One player could grab the dustpan, or just leave it in the corner and sweep the trash over to it. Characters slide over puddles of water. Mopping water over the stairs creates a falling hazard.

This is probably complicating things, but have you considered adding a recycling component to this? For example, aluminum cans on the ground: you can throw them in the trash without penalty, but tossing them in the recycling bin awards bonus points.

I'd really like to see this project take off.

Thanks.

You do pick up the cleaning supplies, so you have to pick up the broom to sweep stuff off the floor, and you have to put the broom down and pick up a trash can lid if you want to lid the trash cans (one at a time). I was thinking of having all the supplies be in one or more broom closets placed throughout the stages.

The slippery water and the recycling are nice ideas, I'll hang onto them. Thank you.

I've been working on the character design and drawing/refining animations.


Guess what one of your objectives might be!

I think I settled on the player names too, Bruce for the blue guy, and Roy for the red guy. I've also been planning the control scheme; it'd be nice if this could run on a Famicom, but controller 2 doesn't have start and select buttons. This is important because this is a 1P or 2P game, where a second player can jump in whenever, and one of the players can gameover out, just like an arcade game. In 1P mode, the player can hold two items, and you toggle between them. In 2P mode, each player gets one item. 2P -> 1P mode, the leaving player's item goes to the remaining player, and in 1P -> 2P mode, the player's inactive item goes to the joining player.

The problem is that the select button was going to be how you toggle between your items in 1P mode, and that's not suitable for the second famicom controller.

The current draft for controls is that the A button is your "item" button, and the B button is a context-sensitive button for grabbing and pushing things, and other non-dpad interactions with the environment. When you're not standing in front of something that reacts to the B button, the B button will toggle between your items instead. This might end up feeling better than pressing the select button anyway.

In addition, the start button was going to be how you join, but the game can check for both start and A. The game can still check both controllers for a start button press in order to pause. I'm not as worried about P2 not being able to pause without using an expansion port controller.

Speaking of which, a common complaint I've heard is when games don't check for expansion port controllers on the Famicom. That's a simple OR between bits 0 and 1 when you read from either controller port, right? Total Famicom support is probably not that important, but the bonus points would be nice still.

The wiki has example code that takes care of that with an AND and CMP.

I'm happy to see more two-player games, and I like the 80s arcade feel and I think the NES/Famicom is a really good platform for those kinds of games, especially with the VS System existing.

As far as full Famicom support goes, I think it's worth trying to find a control scheme that works because at least within the nesdev community there seems to be a lot of people who prefer to play on Famicom.

Really? I'd like to be a little further than three feet from my TV.

Anyway finding controls for both is easy. On the famicom, you could make only 1st player able to pause the game and for select on the second controller, you blow into the microphone. Toggling items isn't exactly the most urgent thing ever, so it might work. I'm not sure how sensitive the mic is though.

Actually, it's 3 feet from your famicom; with long enough wires you can be more than 3 feet away of your TV, and your console is close to you. Not a bad design: you can reset and switch games and not move from your couch

Couch? How about kotatsu? It seems like the most obvious place to put a Famicom, if you ask me.

Ok, ok, I had a perspective closer of my reality, not the Japanese one, even though you're right, a Famicom's place is on a kotatsu.

Thanks! I had a feeling there was a simple way to trick the carry flag into doing it.

Also, TIL what a kotatsu is. We murricans just have couches and coffee tables, optionally with blankets draped over the back of the couch. As a kid, our NES was set up next to the TV, and we'd sit on the floor in front of the TV to play, even though there was a couch, so short controller cables weren't a problem for us, but even if they were, we could just as easily have set it up on the coffee table.

And yeah, I'm definitely going to be Famicom compatible. I didn't know they were particularly common in the nesdev community, I just knew that I'd heard the complaints before.

Well, I said any progress, no matter how minor:
The big empty space on the bottom is the status bar, and there won't be any ceiling-based objectives on the top floor because my TV cuts 16 pixels off the top (8 more than this screenshot), and if my TV does that, it must be the case for others too.

It's a rom now. I have some system code that I've reused in several of my abandoned projects, which includes controller handling (tweaked now to also support the Famicom expansion port), metasprite drawing, ppu pipelining, and several nice routines, so I didn't start from zero.

So far, that scene is generated using a script-type level format. It's something like this:
(starting from 0,0) Move down 24 tiles, draw wall (width: 32, height: 1), jump to (10,12), draw staircase(length: 6, right railing: 3, left railing: 1), etc etc etc, end

If you inserted conditionals into something like that, you could do some pretty nifty things for an adventure game.

Anyway, the code sucks, because it started with a plain rectangle drawing routine that just drew using the brick tile. Then that was generalized into drawing any tile, and then the staircase is a clusterfuck of calls to that rectangle drawing routine in order to make fancy staircases with togglable variable length railings. There are some improvements I can make to this to make it less clunky, and I still need to deal with the attribute table, but I've coded for 8 straight hours.

I like the railing that curves around. Does that mean you have characters that alternate between going behind and in front of the background, depending on where they are?

That's it exactly. There's a software priority map for the screen, and the metasprite drawing routine will check against it to determine what priority to give a sprite tile.

This looks really promising, kindly keep up the good work.

Thanks for all of the encouragement so far, past and present.

This doesn't look much different from the previous screenshot, but there's more stuff going on behind the scenes. In addition to generating the attribute table, the collision map and the priority map are also generated at this point. The collision map is stored bitpacked (8 horizontal tiles in one byte), planar, and 2 bits per 8x8 cell, expandable to 3 bits, shrinkable to 1 bit, depending on what the level needs. The priority map is also bitpacked, but uses 8x16 cells instead. Since the level data doesn't operate on metatiles, there's the possibility of attribute clash and priority clash (since the background priority is only simulated, the moment a sprite tile touches a high priority cell in the priority map, it switches to BG priority, which can look ugly if this transition doesn't occur overtop a blank tile), but this is easily solvable by leaving spaces where needed.

This is also the full size of the playfield, buildings aren't allowed to be any bigger than this, but they'll look a billion times nicer once they're actually shaped like buildings and once more objects are drawn. Now that the collision information is present, the sprite programming can start. I can work on cleaning up and optimizing the code later.

I finished up a routine that draws arbitrary things, rather than just simple rectangles. The scene looks a lot better when it's populated, but there's some attribute clash on the two left stairs, under the short railing. Maybe it's forgivable, but I'll explore ways of masking it.

I've also modified my build script so DASM tells me how much space I have left. There's still about 30kb left, but there's no game engine or music engine yet.

Finally got an up/down walking animation I'm happy with. The apron started with no back (seen in an earlier post), leaving the backview too blank. Then, it had a solid back, which looked ok but didn't make a lot of sense as an apron. Finally, this cross-backed apron looked the best.

Progress has been slow because I got lazy. :\ However, I did poke at the code recently; the code for loading a building was written quick and dirty, just to get something that worked. I went back through it and commented it correctly, and also performed a bunch of optimizations that improved loading time and footprint size. Loading time was pretty quick as it was, but now it's a flash, so I'm much happier with it.

There's also a simple routine that draws Bruce and you use the dpad to move him freely around the screen, to test the priority map portion of the code. It works pretty well, but I ran into some other fun gotchas with priority clash. The end effect will be worth working around the issues though. Basically, the moment a sprite tile touches a high priority BG tile, the sprite tile flips into low priority mode so it can slide behind the BG tile. The problem was that the up/down animations were made assuming the top portion of Bruce's head can just be moved back and forth physically as a tile optimization. However, that means his head will overlap the high-priority railings at the top of staircases, hiding half his head behind the stairs every other frame! There's a couple ways to fix it though, one is ignoring the priority map while going up/down stairs (but not other things, like stepladders, because his head needs to go behind ceiling lamps), which is a feature already coded. The other is changing the sprite so the head bobs are included in the graphics rather than having two tiles that bob back and forth physically.

And yeah, their names are Bruce and Roy. Some fun trivia can be that they were almost named Pipi and Pupu, as indicated in the OP.


In more personal news, I'm in the process of kickstarting a career change so I can finally leave retail and persue programming full-time, like I've worked so hard to prepare for. This game project has stayed in the back of my mind ever since starting it, and even if progress is miniscule and far between, I hope my drive to work on this doesn't die before it has a chance to be completed.

Did you consider using the fact that the priority bits aren't true Z-ordering, like SMB3 does? That is, when there's a sprite that's to be "behind", a sprite that's to be "in-front", and a non-BG-colored pixel in the tilemap...both sprites are put behind. (Not sure, does this only work if the "behind" sprite is nontransparent?)

This would use some extra sprite data and OAM space, though.

Yes, the "behind" sprite has to have a non-transparent pixel, and a higher priority (= lower sprite index) than the "in-front" sprite.

The trick SMB3 uses when Mario enters pipes? Yes, I considered that, but since most priority clash issues can be fixed by leaving a space of 1 blank tile between low priority and high priority BG objects, I figured I wouldn't need to go that far. Plus, I'd need mask sprites that are in the shape of the various BG objects, and would need to store extra data in RAM for which mask shape to use in each location. (There's no tilemap or metatile map in RAM, it's only a map of physical attributes, otherwise it'd be doable) It's not a bad idea though, and given more memory, I probably would've done it.

Having Bruce ignore the priority map while on stairs also makes sense because he wouldn't need to be behind anything until he's reached the top of the staircase, and also helps with animations like if he were shoved down the stairs, he'd have been shoved in front of anything, which is good because his sprite would likely be wider during the animation.

Nice to see progress (no matter how slow). But that back sprite looks slightly odd.

It looks like the front of a shirt vest. How about making the straps thinner, like this?
http://www.nicnacnoo.com.au/images/deta ... m-Back.jpg
But without the bow in the back.

That's the exact thing I was going for, actually. You're right though, the straps needed to be thinner:

Hopefully that looks less like the front of a shirt? A few weeks ago, the problem was it looking too much like a weird bikkini. Also, in a higher resolution, he'll have actual criss-cross straps on his back; there's just not enough resolution to reliably depict it here.

Love the lightbulb changing animation. A lot of character there.

Earlier you mentioned an inconsistency between the vertical walking and horizontal walking animations. That may be because in the vertical walk, the character rotates his head side-to-side, but in the horizontal walk, he bobs it front-and-back, implying that the character has a different walking style between the two directions. Not a big deal, though (especially if vertical walk is only used for stairs because people would walk differently on stairs than on flat footing.)

Anyway, looking forward to seeing more progress as it comes along.

Yeah, it did look kind of like a brassiere or tank-top.
I disagree that there isn't enough resolution (though, NTSC problems may spite me). Here's my attempt:

Well whaddaya know.
It took a lot of tweaking, but the criss-cross back looks fine. You guys were right, it's not impossible, just difficult.

If you're doing NROM this might be asking a bit much, but what if the walking up/down animations got just a few more tiles each to give him a symmetrical frame? Right now the hat jumps a little when it goes from one side of his head to the other. I think one more tile could be mirrored and give the hat a center location as it passes to and fro, and it would make the animation more smooth.

Then again if the animation is any more smooth then he won't quite have the comical waddle, so not sure. I'm not on my home computer so I can't tweak it myself right now.

There's no symmetrical view because, IMO, the head doesn't look as good when everything is symmetrical and perfectly straight-on to the camera. The slightly angled head (especially the hat with its turned-up brim) looked nicer, and since the angle isn't very significant (compared to a totally diagonal head), it looked ok for the head to flip back and forth like that, especially considering how the rest of his body was moving.

It just boils down to a stylistic choice; animations don't need to be ultra smooth as long as they can be read properly. He could easily have a straight-on head angle and it could be made to look good, but ehhhhh I did that originally and didn't like it as much.

I really like the head wobbling. Have you thought about bringing into the horizontal walk animation? This is a really messy edit I put together to show it.

I hadn't thought about it before, but it doesn't look bad. It reminds me of Mario's sprite in SML2. Once I have enough of the game engine together, I'll try that out and see if I prefer it to the current head bobbing on the sideview.

When I last touched this project, I was shedding my old food service job which had degenerated pretty badly in my last year there, starting with the absolute worst winter holiday season I had ever lived through, both at work and at home.

The entirety of June, I worked two jobs with zero days off (over 40 hours a week!) because I put my two-weeks notice in on a Sunday (so three weekends of work instead of two). Meanwhile, I started with a programming internship, and programming at this company felt 1000x more satisfying than anything I'd ever done at my old job, since it was actual programming, which was my life's hobby.

July 4th, my old job expired and I had my first day off in a month. During my internship, I had to learn a whole bunch of stuff very quickly (such as C#, asp .net, angularjs, plus some proprietary stuff), and had to make some lifestyle changes to accomodate waking up at 6 AM every morning (before, I'd be going to sleep around then!), and coming to terms with making a 1.5 hour commute there and back each day. I quit caffeine and had to start eating better since I went from being on my feet all day to sitting all day.

The internship turned into a fulltime position, and the first order of business is to take a handful of 5-hour roadtrips over the course of the next few months in order to take classes to get a programming certification for a major manufacturer of home/business automation equipment. Meanwhile, I'm coming off of juggling two programming projects with two teams to just the one project with the one team (since the interns left), said project probably being why they kept me around.

I basically disappeared around here and haven't touched Clean-Up Crew since this last post. However, at work, I learned about using Kanbans for keeping track of tasks and progress, which is a great help for seeing how far you've come and knowing exactly what else needs to be done before you can say you're finished and take a break before starting on the next wave of functionality. This is a huge help to any programming project (even just keeping a TODO list that you check off, while adding future TODOs to a second list you start afterwards, etc)

I don't know how to pick this project back up, and I don't know how to recover from my initial work burnout and get energy again, but once I do, I feel much better equipped for how to manage being a solo programming team on a NES homebrew.