Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Dalton

Oldschool point-and-click adventure game development

This topic is 5726 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''ve been programming Computer games using DirectDraw for about a year and a half. I''ve finished two tile-based platform games, and now I''d like to do something with a bit more depth. What I''d really like to do is an oldschool point-and-click adventure game, in the same vein as the King''s Quest series or Kyrandia series. I realize that going from a tile-based graphics engine to the kind of graphics engine this type of game will demand is a huge step. This post is a plea for guidance; I have a numerous questions regarding how these games work. How is the game screen drawn? In seems as if each screen is composed of a giant background image, then a few other giant images layered on top of it. In my experiences, using DirectDraw to blit giant bitmaps has been very slow, so naturally I''m confused as to how to draw the game screen. How do I suddenly change aspects of the game screen? If the background really IS just one giant blit, then if I want to suddenly, for instance, snap a branch off of a certain tree, will I need two giant background images - one with an undamaged tree and one with a damaged tree? That''s all I think I''ll ask for now, but feel free to add any pointers. A simple outline of the aspects of the game engine would be greatly appreciated as well.

Share this post


Link to post
Share on other sites
Advertisement
Just quick answer (haven''t read all the post yet) with regards to "changing" the background, just use sprites for anything that might change. For example tree branch, then draw it differently or not at all.

Try to think of ways of preserving memory, anything that won''t change draw it just once don''t repeat it in other pictures.

Share this post


Link to post
Share on other sites
I''m actually sitting on my couch writing a design document for such a game as I''m typing this. mjdalways has it right - if something is going to change then keep that as a separate sprite. In your case have a tree sprite which is either whole or broken.

As for what I''m doing, I''m going to have one huge background and blit that. Then the sprites are going to be blit in order from top to bottom (based on position). This gives it a layered "3D" effect (for example a character can stand behind of or in front of a table). To achieve this I will have some data structure (probably a list, vector or array) containing all the sprite objects, which will be sorted every frame (probably using an insertion sort since it will be "almost sorted" each frame anyway).

Good luck!

Share this post


Link to post
Share on other sites
Sounds like a great plan, but my main concern is that blitting the background as one huge bitmap will be slow...

Share this post


Link to post
Share on other sites
quote:
Original post by Dalton
my main concern is that blitting the background as one huge bitmap will be slow...



I don't think you should have to worry about this too much. A full screen blit really wouldn't be too much of a performance hog, and you don't have to worry about anything else really slowing the game down.

If you do find that a full screen blit each frame slows the game down too much, just modify your code to only draw the parts of the screen that change. Lots of applications and games do that.

However, you may find that storing lots and lots of background images may use too much memory. A 1024x768 32-bit image takes over three megs to store. So you will probably want to shoot for a lower resolution and/or bit depth. Unless, of course, you don't mind distributing your game on CD or making it in 3D (which may not be what you want, just yet ).

-Mike

[edited by - doctorsixstring on February 8, 2003 12:40:11 AM]

Share this post


Link to post
Share on other sites
Storing and blitting big bitmaps is slow, just as you suspected. But what is a big bitmap exactly?
In 256 colours, anything above 1024x768 probobly. In any higher colours mode, anything above 320x240 tends to be big and bloated. (note: these numbers are from my head, and my experience, not heavily researched. But the idea still stands)

Old school adventure games were never much higher res then 640x480 @ 256 colours though, so full screen images in that sceneration arent _that_ big (especially for most systems nowadays)

A common tecnique was to just redraw what changed, using something like dirty rectangles. However, once again on modern systems the performance gain seems to be next to nill.

Just use the lowest colour mode possible for your game (if you use 256 colours, you can play with the pallete!)
Stick to a small screen size (800x600 tops)
Create anything that will change, or move as a seperate object as a small and seperate sprite. Also think about seperating the bits of something that change into seperate sprites. (the frames of rotating tires on a car for example)

Anyway, hope that helps.

- Jacob

Share this post


Link to post
Share on other sites
well, it might be a performance hit, but look at what were talking about here
a modern system running it (as your talking about directx programming)
if you were on legacy hardware you might want to worry, but trust me (speaking from experience) when i say your game will run just fine blitting a fullscreen bitmap

Share this post


Link to post
Share on other sites
I had a graphics engine that was coded in "C+" (used classes but was procedural and very C like) and I used it to blit an 800x600x16 image, as well as two smaller ones (one that was animated) and some text (this was all part of a test) and on my laptop it ran at around 60 fps, on my pc - 145 fps. On my friends 6 year old laptop (might be older even) I was getting over 30 fps. You don''t need to worry about performance.

Share this post


Link to post
Share on other sites
It''ll be a bit tougher with 32-bit graphics (which I suspect we all want nowadays), but implementing dirty-rectangles is dead-easy and will boost performance like hell. Except when scrolling the whole screen. Anyways I suggest you do what''s recommended in the above posts, and optimise it later.

2DNow - Specializing in yesterday''s technology today!

Share this post


Link to post
Share on other sites
32 bit graphics will probably give you fast blits than with 16 or 8 since modern processor and graphics cards are built on 32 bit architecture, although you then have to worry about memory (though again most graphics cards have at least 16 mb of ram which should be enough).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!