0
\$\begingroup\$

I would like to make an adventure type game functioning similarly to machinarium or broken sword. The only way I can think of doing this is to draw an image as a background on a canvas and use some animated sprites that moves around and responds to touches on the screen.

But having a runnable that keeps re-drawing the canvas seems like a waste of memory to me, especially when it comes to larger images like the background.

I'm pretty new to game development and canvas animations and I was wondering if anyone could point me in the right direction? What would be good training for an adventure type game?

|improve this question
\$\endgroup\$
3
\$\begingroup\$

One of the most commonly used methods to render images involves double buffering. All of the data to be drawn to the screen is drawn to the "Back Buffer", and at the end of the draw routine, it swaps positions with the "Front Buffer" which is located on the screen. Your 2D screen has no understanding of the concept of layering, so if you don't redraw the background each frame (or use an algorithm to only redraw the exposed pixels) then you wont have a background. This is just one (though the main) approach to rendering to the screen, but there is no way to get around having to draw what you want to see on the screen.

Your initial idea is going in the right direction. Stay the course.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Well that's not entirely true, you actually can just draw the whole background once and invalidate the parts that over lap with sprite animation. While that would technically be a more efficient solution it is not exactly friendly to less experienced developers. I would definitely recommend you draw the background each time to simplify development but I just wanted to let you know there are more efficient (although hard to use) methods for rendering. \$\endgroup\$ – Benjamin Danger Johnson Jan 30 '13 at 17:55
  • \$\begingroup\$ If you track the movement of all objects over the background and only redraw the areas that have become exposed you could keep from redrawing the entire background. Though the overhead involved in tracking the movement for per-pixel redrawing might produce more performance problems than simply redrawing the entire texture to the screen. \$\endgroup\$ – Evan Jan 30 '13 at 18:35
  • \$\begingroup\$ very true, it really depends on the number of objects and complexity of the scene. While this is technically the optimal method for the GPU you are very right in that it can require a lot of CPU overhead depending how it is implemented. Either way my suggestion is not recommended for beginners (which is why I didn't post it as an answer), just kind of meant as a note about alternatives. \$\endgroup\$ – Benjamin Danger Johnson Jan 31 '13 at 0:10
  • \$\begingroup\$ Also, in practice, apps (and games) usually don't keep track of pixel-precise areas to redraw (like the original Mac's Regions or a mask of some other sort) and instead only track rectangular areas. Sometimes even just the smallest rectangle that encloses all changed areas in this frame. But that's only faster on the CPU. A GPU can redraw the whole screen on each frame and composite its different elements, so today people generally don't bother (though they do eliminate completely invisible objects). \$\endgroup\$ – uliwitness Oct 23 '16 at 22:32
1
\$\begingroup\$

My generic advice would be not to worry too much about performance when you're starting out. As mentioned in the other answers, it's possible to redraw only those portions that have changed, but you're already getting into a level of performance optimization that's premature when you're learning to create the basic architecture of your game. When you're ready to do optimization, it's worth analyzing the problem in terms of what are the ACTUAL bottlenecks of your game, not what seem like they ought to be.

In general, it's very common to have a main game loop that cycles through:

  1. Getting user input
  2. Updating Game Logic
  3. Drawing the scene

Where, in step 3, you're drawing the entire scene, even those parts that don't necessarily need to be redrawn. As far as a useful starting point, I recommend this blog post:

http://www.godpatterns.com/2010/08/how-to-make-adventure-game.html

In particular, you're going to want to learn about such things as navmeshes, which are pretty fundamental to that genre.

|improve this answer
\$\endgroup\$
-1
\$\begingroup\$

If you are starting to develop your adventure game, you probably have a great story, graphics, music... Sometimes it may be a good idea to try some free engines and editors just to get an idea how they work - and use them as an inspiration. Or use them for your project, of course. I mean for example something like GameStylus, which is a specialized on-line game editor and game engine for adventure games - and it is free.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Downvote because this user keeps hawking this adventure game engine (and that's all they ever post to SO), and this engine only, i.e. is rather spammy. There are many more, please make an effort to be impartial and disclose any affiliations. \$\endgroup\$ – uliwitness Oct 21 '16 at 14:00
  • \$\begingroup\$ But the general advice, to use one of the popular engines, like OpenSludge, Unity3D, AGS, AGE, Visionaire or Wintermute holds true. Unless the game is just a fun project you're using to find out how stuff like this works, or to teach yourself Java. \$\endgroup\$ – uliwitness Oct 21 '16 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.