Scrolling tiles?

[Josh]

In the game that I am currently working on, we use tiles. That's all fine and dandy, but we also need it to scroll. So my question is: what is the best (easiest) way to scroll? The one idea that I thought of was to check the position of the player and then scroll accordingly. Would that work?

[swcrissman]

In general, yes, that's what you have to do. There are typcially two types of scroll I can think of:

The first kind keeps the player in the center of the screen, and just kind of moves the board beneath them. So if you hit left, in code, you move the player left, but visually, you keep the player in the same place and the board moves to the right. I hope thats clear. Really, I think that's most typical nowadays.

The second kind of scrolling is screen to screen. The best example of this is the original zelda, although I suppose we may be getting to the point where some people have never played the original zelda (oh, the injustice!). Anyway, in this kind of scrolling, you move the player around on the screen, and if they hit the edge of the screen moving out of it, then you change screens so that they are in the next 'room'. So if I hit left, my player visually moves left until he hits the edge of the screen, and then when I try to move left again, he shows up on the right side of the screen as though he just entered the next room over.

In either case, you'll update the screen based upon the players location. You check to see where they are in the game world, and what the offset is from them to the corner of your screen, and then draw the appropriate tiles in place based on that.

I know this has come up several times in the old forums, so you may want to search there. I know the macgamewiki (http://macgamewiki.crissman.net) has a link to the old forums on its FAQ page, in case you dont have one handy. Also, I know that gamedev.net has several articles related to tile based games, although I don't know whether any of them will be of assistance.

Spencer

[Carlos Camacho]

Spencer, good general explanation. In the case of the player being drawn in the middle, and scrolling the world, don't forget the case of when the player reaches the "edge" of the world. For example, in Warcraft the world simply won't scroll anymore as the player goes to the edge.

I haven't seen any Zelda "like" engines used in Mac games, so it would be nice if someone does one.

In fact, since this is an area which so many people come in contact with when making RPGs, it would be great for someone to whip up a nice scrolling framework, complete with multiple layers (like 3, floor, objects, high objects like trees). Make it flexible to handle various tile-sizes, etc...

On the subject of Zelda-like engines, a tutorial on this (Cocoa?) would also be really good. Any takers?

Cheers

[cloke]

I was working on a Zelda like game for a while (and have recently started working on it again). It consisted of a map editing tool and the game. Basically, all I have is a character that walks around on a map and when it reaches an edge it goes to another map. If some one is interested in looking at the code I could clean it up and post it.

[Josh]

Originally posted by cloke
I was working on a Zelda like game for a while (and have recently started working on it again). It consisted of a map editing tool and the game. Basically, all I have is a character that walks around on a map and when it reaches an edge it goes to another map. If some one is interested in looking at the code I could clean it up and post it. If you could that would be nice... Unfortunately, that type of scrolling wouldn't be good for the game that I am developing, since it is a racing game.

Originally posted by swcrissman
The best example of this is the original zelda, although I suppose we may be getting to the point where some people have never played the original zelda (oh, the injustice!).I am proud to say that I have played the original Zelda. :) Perhaps that should be a new requirment in school... playing the original zelda... of course, they would have to find working Nintendos...

[Unregistered]

A few things:

I'm working on a game of the former scrolling technique(keep the player still; move the map)- though even within that there are two animation modes, which I fondly call "The Dragon Warrior Approach" and "The Final Fantasy Approach." I spent a lot of time poring over these two carts to find out how animation worked in them... I'm porting, most copyright-infringingly, Final fantasy to Mac OS X, you see- the original game.
At any rate, final fantasy(ignoring the NPC sprites) works like this, in moving left:
move left 1/4 a tile.
switch to 'left2' frame.
move left 1/4 more tile.
pause.
move left 1/4 more tile.
switch to 'left1' frame.
move left 1/4 more tile.
end.

all movements in final fantasy go in four steps: in battle, for instance, the character slides forward, switches to 'battle walking' stance, slides forward, slides forward, switches to 'battle standing' stance, then performs the next action. 'attack 1' 'attack 2' 'attack 1' 'attack 2'. then, slides back in reverse of the former process. it's kind of cool, really...

the dragon warrior school hsa two frames constantly swapping, and movement only occurs at certain times. everyone who needs to move moves at that time, just slides forward while in the second frame.

incidentally, each movement on the map in final fantasy takes place in 50 millisecond-increments. so, 5 tiles per second.

what i'm planning on doing(haven't tested for speed) is using an NSTimer to fire off every 20 seconds and call a method that sets certain variables like orientation, background position, and frame to draw based on a modulo operation... if you're curious, I could post the code.

-(NS)joie

PS: I just beat the original Zelda last weekend. Also the original Final Fantasy. Also the original Dragon Warrior. Yes, I am a God, by the way. ^_^

[Carlos Camacho]

cloke, we always need example code. So please do clean it u0p, stuff-it and email it to me..

cheers

editor@idevgames.com

[Unregistered]

Yatta! Folks, it worked out fine. Well, mostly fine. Two caveats:

For some reason, any arrow key input is received as "NSLeftArrowFunctionKey". I don't know why. It makes me sad.

Also, moving left and right is a LOT slower than moving up and down... about half as fast, maybe slower than that. Shall I chalk that up to the slowness of NSImage? I'm using a big one. And then a bunch of small ones. Yes, that's probably it. ^^;;

Quite frankly, CopyBits() and gWorlds creep me out, so I'll just wait until the end of summer to judge about sideways speeds... ^_^;; Or maybe I'll read up on some Carbon...

Anyway, hurray! I've got a good, sound, 2-d animation sprite engine groove goin'. It's a little laggy, but it'll pick up. and it only took me a day- hey wait, it DID only take a day, didn't it?? @_@ Wow... I love this platform! ^___^

... anybody know how I can get a cheesy MIDI to play? ^^;; (In the app, of course! Not in some evil embed tag. ^_^;;;

-joie

[NecrosaJoe]

well. It seems that by using the [image lockFocus]; [image unlockFocus]; combo... the speeds increased astronomically. ^^;; Yay Apple! Now if only this happened automagically... but what's the magic behind it?

-joie

<edit>
by the way... a few posts up, I said I was going to fire an NSTimer every 20 seconds, this is patently false. 20 milliseconds. It was late last night. I'm sorry. ^^;
I got keyboard input to work by poking around these forums. ^_^ Now I can't get a MIDI to play in the background, but that isn't a huge deal... time to go work on collision detection and pushing the "A" button. ^_^
</edit>

[NecrosaJoe]

another update, if anyone cares. ^_^

Now there's collision detection. Other sprites. The ability to inspect one's surroundings. Support for locked doors. Support for LOTS OF TREASURE... also, support for boss monsters, conversations, teleporters, stairs, and washing your hands. ^_^ It's coming right along. All I need to do is find someplace to teleport to, and refactor the view subclass. fun fun! ^^;;

-joie

[NecrosaJoe]

hwarhngnsngns.

"Build failed(see build log for details)"

"/usr/bin/ld: multiple definitions of symbol _mBoxBordRect
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ZoneView.o definition of _mBoxBordRect in section (__DATA,__common)
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ConeriaCastleFloorOneView.o definition of _mBoxBordRect in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol _mBoxOrig
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ZoneView.o definition of _mBoxOrig in section (__DATA,__common)
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ConeriaCastleFloorOneView.o definition of _mBoxOrig in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol _resetMBoxRects
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ZoneView.o definition of _resetMBoxRects in section (__TEXT,__text)
/Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ppc/ConeriaCastleFloorOneView.o definition of _resetMBoxRects in section (__TEXT,__text)
...failed MasterObjectFile.Combine /Users/osword/Desktop/Funk You/build/Funk You.build/Funk You.build/Objects-normal/ProjectBuilderMasterObjectFile.o ..."

the relevant lines are, I believe:


NSPoint mBoxOrig;
NSRect mBoxBordRect;

void resetMBoxRects(void)
{
mBoxOrig = NSMakePoint(96, 416);
mBoxBordRect = NSMakeRect(0, 144, 448, 32);
}

@interface ZoneView : NSView


Sigh, this is the pain that comes with refactoring... any insight would be appreciated as to why I cannot compile. I've already scrapped my build directory, twice. myarg. ^_^;; can I get a hand?

-joie

[NecrosaJoe]

hooray for ugly and inelegant solutions! :P I turned the function into a method which only self invokes. Ugh. My function was working before I moved things around... but then it wouldn't work at all, anywhere. oh well.. now it compiles.


-joie

[OneSadCookie]

Sounds like the standard declaration vs definition problem that new C coders always run into in their first large-ish project.

The solution is to declare the variables/functions extern in the header, and define them (ie no extern) in a single source file.

It's been covered before, I think on this forum. A search should turn up the discussion.

The real solution, of course, is not to have global variables :P

[NecrosaJoe]

hm.. thanks. ^_^ But what you said about global variables is absolutely right. Why should it matter to the 2nd floor of the castle if the message box is open in the Temple of Fiends? thanks for the help. ^_^


-joie

[WFleming]

You might want to check out SpriteWorld (a Mac C Sprite Animation Library) for your game. It makes tiling and scrolling easy (as well as scrolling without tiling). It also makes handling your sprites very easy.

Best part about it is that it is an open source project, so completely free to use.

Check it out at www.spriteworld.org

Best example of a game using SpriteWorld is Ambrosia Software's lastest Escape Velocity game (Nova I think) which uses parts of spriteworld.

The only downside is that the current version (2.3.1) only supports Classic mac programming (compatible with systems 7 - 9.x (and OS X in classic mode)). The good news is that a new version (3.0) is coming closer to release. You can currently download an alpha version (fully functional, no known bugs) which supports Carbon development and Hardware Acceleration (OpenGl as well as QD3D RAVE), among other things.

I've been using SpriteWorld to make game similiar to Metroid, and it has made life much easier.

[NecrosaJoe]

I love Metroid so much. ^_^ I beat it a couple of weekends ago. That felt gooood. (Want some more, Mother Brain!?)

I haven't used SpriteWorld, but... is it even necessary with Cocoa? We've got such easy methods like NSImage's "compositeToPoint:" and things like that.. I had a purely graphical 2-d tile-based RPG up and running in a couple of days- my first project of the sort, even.

So... It's easy to do complex things. ^_^ And, though i'm not advocating reinventing the wheel, it's good to know how to do them. It's a fun exercise. And one's components will be reusable if done properly. Yay!

-joie

[WFleming]

Sadly I can't speak for Cocoa (living on a college student's budget, so i't'll be at least another couple months before I'll finally be able to afford something I'd be comfortable running OS X on). So i'm stuck with Carbon for the time being (do have limited access to an OS X box for testing purposes at least). But I digress.

There are also a few other useful things in SpriteWorld, like collision detection and quite a few blitters, and ability to easily do things like translucency effects. SpriteWorld also has a really elegant interface.

However, I forgot to mention that you can't really do anything besides 2D games. Which is fine, if like in my case, that is all you need. It would also be really useful to the programming novice.


While i'm on the subject of spritekits there is a Cocoa Sprite Kit available (haven't personally checked it out but thought i'd add a link in case anyone was interested)

http://www.sugarcubesoftware.com/csk/

[NecrosaJoe]

I looked at CSK about a month ago- I ended up deciding that rather than learn the as-then-unfinished(is it done yet...?) CSK API, I'd rather just make my own. That way, I'd be more familiar with it, &c. I also found a dearth of CSK documentation... the project is promising, but not usable yet(at least, not by me). Besides... doing things like collision detection and drawing code is fun. ^_^

I hope you get into Cocoa. ^_^ Objective-C is easy to learn. 'Cocoa Programming' isn't. You have to familiarize yourself with a large API, and go about things in an OOP-ier way, and(I know from experience! Do it! DO IT!!) follow the Model-View-Controller paradigm nigh-religiously. It makes things easy and fast. Custom IT database solutions? No problem. Port of Final Fantasy? Easy. Do it once, do it right. ^_^ Reusable objects are good things. I'm going to keep spewing these cocoaisms if I don't stop myself.

-joie

[Bachus]

The problem with Cocoa is that it is *sloooooooow*. A game made entirely in Cocoa will be unplayable on slower OS X machines (unless it's very non-demanding like Hooptie, and even Hooptie becomes unplayable when too many enemies are on the screen). As a simple comparison, on a G4 OS X machine I get around 80fps with a Cocoa sprite demo. With SpriteWorld 3 alpha, I get over 1000fps (numbers may be a little off as I ran these tests a few weeks ago). On a beige G3 OS X machine the Cocoa demo runs at an anemic 6-7fps. And that's only if you turn off all the pretty effects like rotation and translucency. And this is just a small demo with few sprites, no AI, no scrolling, etc.

Jaguar may improve things, as would using OpenGL. But requiring a high-power 3D card to run a fairly standard 2D game that the SNES could run with 1/10 the processing power seems a tad wrong.

[NecrosaJoe]

That's true. Cocoa is really, really slow. ^^;; but it's pretty! And it has a very pleasant drawing API. ^_^ But everyone wishes it were faster... Anyway, it still doesn't negate the benefits of doing things like collision detection and simple animation and scrolling by oneself at least once. ^^

-joie

[Feanor]

Originally posted by Bachus
But requiring a high-power 3D card to run a fairly standard 2D game that the SNES could run with 1/10 the processing power seems a tad wrong.

Yes Quartz (not just Cocoa) is in need of serious optimizations and other things. There's some info on drawing straight to the screen with GoreGraphics on Apple's web sites to speed things up, I believe. If you're using pure Cocoa AppKit to do a game, though, yeah, it's gonna be slow. It's not designed for FPS. Apple has announced that with X 10.1.5 they have added 2D acceleration for Rage Pro graphics -- that will definitely improve the results you are seeing on beige G3s with the stock Rage chip.

But saying that OpenGL is overkill, I don't know. The problem is really that Apple doesn't accelerate OpenGL on ... Rage Pro and earlier. Mostly it's because it gives people false hope. But 2D with OpenGL is easy and very nice looking -- it also runs very smoothly and avoids the need for custom blitters and the like. Apple has a cool 2D demo called RedRocket. You get many extra features like zooming with little extra investment.

I think it's going to be commonplace, though, for people doing shareware 2D games to use Cocoa as their interface and then do CoreGraphics drawing into their drawable. I don't know any Core Graphics but it is better to use it than QuickDraw, for sure. What does the OS X version of SpriteWorld use?

Necrosa, are you Joie from CocoaDev?

FÎanor

[NecrosaJoe]

Funny you mention it, Feanor- I am that joie. ^_^ I haven't been around CocoaDev for a while, though. I decided I should actually find out what I'm talking about before I go pedantifying. I've spent the last three days poring over the Portland Pattern Repository, learning about Smalltalk, studying, working, designing. I'm rewriting the game I mentioned earlier in this thread in a completely good and m-v-c way. (Did you know that 'Controller' in Smalltalk means something different than 'Controller' in Obj-C? In Obj-C, it's a mediator of sorts... and in Smalltalk I can't remember what it meant. But it's different. ^^;;)

Sometime I'll go back to cocoadev, and maybe write up a tutorial on scrolling/tile-based games if there isn't one already. Maybe on animation theory? I know some of that.

I haven't used CoreGraphics either, but for me, Quartz is fine- I don't need a lot of speed. If I were doing the Dragon Warrior animation style, I'd need even less.

Hey. it can only get faster, right? ^_^ And users need not recompile to gain speed, right? If that's not nice, I don't know what is.

-joie