Although if you were to copy a puzzle game, or use one as a bar, Donut Quest is a pretty good one to shoot for.

Kerm, you can put me down as a candidate for the asm contest (assuming that we do a puzzle game). I've come up with an idea for a puzzle game that I'll start working on, and hopefully I'll have a decent demo ready in time for the contest.

Superb, that will give us at least two definites for the ASM category, and depending on what TheStorm decides, it might be three.

BASIC:
:: jfabi82
:: RyanSimbalist
:: Zaphod Beeblebrox
:: KeithJohansen
:: foamy3
:: Sage Orator
:: TheStorm (?)

ASM:
:: TheStorm (?)
:: magicdanw
:: Calc84maniac

That's odd. The game I was going to make fits that exact description... Wouldn't it be weird if we ended up making the same game?

Calc84 and TheStorm: It would indeed be extremely weird. No more talking about your ideas though, it's fine if you end up making the same game.

Hey, did you forget about me? I'm participating in the BASIC section.

And also, can the puzzle have a storyline? I'm already quite advanced in it so it'll be a shame if I'll to remove the story...

I'm not the final word on it, but it is my impression that puzzles certainly can have storylines. It's what you're doing, not why you're doing it.

I don't see any reason why not, as long as it clearly is a puzzle game.

BASIC:
:: jfabi82
:: RyanSimbalist
:: Zaphod Beeblebrox
:: KeithJohansen
:: foamy3
:: Sage Orator
:: Zagor NBK
:: TheStorm (?)

ASM:
:: TheStorm (?)
:: magicdanw
:: Calc84maniac

Since this is my first real graphics-oriented assembly program, I'm wondering if anyone can recommend any resources for learning about displaying advanced graphics in assembly code. I can draw sprites in fixed locations, but as for more complex stuff, like animated/shifting graphics, grayscale, etc. I'm in the dark here. Thanks!

Edit: I hope asking a question like this in this thread isn't against contest rules. I figure everyone can benefit from the knowledge, and its availability might encourage some game-programming newbies like myself to try entering something.

Since you're not asking for help on a specific problem, it's acceptable. Have you looked at the stuff in ASM in 28 Days yet?

Yes, I have. I'm talking more advanced stuff. Right now I'm trying to code a text message box that can lower onto the screen (or maybe pop up, I'm not sure which I want yet) row by row. It's taken me a long while to get it as close as I have it, and it's still not complete. I feel like there's some theory here that I'm missing, and was wondering if there were any guides that explain the techniques behind displaying and manipulating sprites.

The way I figured it out was simply running through existing sprite routines as if I was the CPU and seeing what happened. You're welcome to use shell-specific routines, like Doors CS routines, as long as you're making your program for whatever shell, not just taking its routines.

Thanks. I don't think I'll be making it in DCS, sorry. All of the programs I've written so far are noshell, and if I ever wrote for a shell, it'd probably just be Ion-compatible. I'll see if I need to do that.

Also, I think that my main problem is I'm trying to do the advanced sprite manipulations while also using a grayscale library I didn't even write (graylib2) so combining the two is difficult for me. I'll just start making the game b&w, and maybe later I'll learn how to do grayscale effectively.

You can still use standard Ion LargeSprite routines, though.

Are you talking about my specific problem, or using routines in general?

If you're talking about my specific problem, I have three tiles for two upper rounded corners and one midsection. I'm using those three for the top of the box. Then I just manually draw lines extending downward to the bottom of the screen. So this is more size-efficient, but I need to use clipped 8*8 routines.

If you're talking about copying the ion routines into my program, I was wondering if I could do that? Or the routines from 28 days? I would of course give credit if I used either, and it would make me very happy to continue my nostub traditions

well Ion is open source so you could either make and Ion game or just adapt the routines to work for you game, when I was trying to port asteroids to the 86 instead or rewriting all of the routines I just ported the ION routines, which was a lot easier.

Edit: Also does anyone know where I can find a tut on how to make a tile-mapper?

No, don't copy the routines from Ion, that's not only against the rules but also against Ion's license Just make it Ion.

Ok. I started re-writing my routine using Ion and non-grayscale, and it's almost done! I love non-grayscale

Well I'm looking for a good tile mapper tut because I have no clue where to start so my project is on hold until then.

Can't you just think about it? You know the basic idea is that you need a set of tiles, uniquely identified in some way, a map that "maps" each of the areas of the screen to one of the unique tiles, and rendering routines that handle actually doing the drawing. You might also need a fourth component, something that governs how the map changes the behavior of things on that area of the map.