Confused about Maps and Tiles..., and some questions on how you learned!
Blitz3D Forums/Blitz3D Beginners Area/Confused about Maps and Tiles..., and some questions on how you learned!
| ||
| Hello! I've got a couple questions for the community: ------------------ I recently got Blitz3d, worked my way through the tutorials that come with it, and am now slowly working my way through the 2d tutorials on blitzcoder.com I've been able to keep up with the code, but maps and tiles are really confusing me. :( Could anyone give me a really general overview of the philosophy behind tile maps? I know that it is taking an image split into tiles and then drawing the map with those tiles. The comments on the code I'm looking at are very helpful, but I'm having trouble looking at "the big picture" so to speak. That is, I can understand what each line of code does, but I'm having trouble piecing it together. If someone could maybe describe the general idea behind coding a tile engine (i.e. "First you must create a function to blahblahblah, then array blahblahblah. This allows the engine to blahblahblah"), I would really appreciate it. :) I ordered the "How to Program 2d Games in Blitz" (sorry if I got the title wrong), and am anxiously awaiting it. Does the book contain a very good description of tile mapping? Even if it does, I would really appreciate some commentary on tile maps, as several viewpoints may help me to understand the concept better. ------------------ My other question: I was curious how other people started learning Blitz. I pretty much have no programming experience whatsoever, so it's actually pretty difficult for me. :( There are times going through the tutorials where I get stuck, and then think about it some, come back, and it all makes perfect sense! Those times are great. :) Then there are times where I get through a tutorial, and I feel that I just barely understand the concepts introduced. Those times aren't great. :( There are time when I get disappointed with myself and want to give up, and feel like I won't ever learn anything! :O I usually take a break for a day or two, and when I come back, I can usually find the problem. Anyway, I was just wondering how other people are learning/have learnt Blitz. Did you have experience before? Did you just jump into programming your own stuff? Did you go over all the tutorials? Did you go through the "Programming 2d games..." book? Also, how quickly did you learn? I've been learning for 2-3 weeks now and feel really behind. :( How long before you made your own simple game? Thanks, and I really appreciate any responses! Al |
| ||
| Hi kyouki and welcome, first, I (try to) answer to your 2nd question. In my case, I come from a programming background; I started with a sinclair spectrum, and delighted with basic commands and later with some assembler. The time taken to learn a new language is very subjective. I think you can learn faster if you try to realize some game/application that you really need or want to build up by your own. I started, for example, with re-doing space invaders. It was a very good programming lesson indeed, and the experience gave me lots of fun too. So my advice is to start small, and learn the concepts that you need to make what you really like to do. This is the strongest 'spring' you can use. Now the first question. A tiled map; I suggest you to do by hand what you want to achieve first. I mean, suppose a tiled map that scrolls only left and right. Just prepare and paint some squared frame (the tiles !) made of paper, and scroll it manually left and right. You can already notice what you should do with these tiles in terms of programming... The concept is to draw each tile at the right position, and wrap the tiles that goes out the screen. So, basically each tile has its x,y coordinates; the x changes when you want to scroll the map to the left or to the right. You will probably end with an array of images, or an array of types. First, try the first one. The second one is better, but you have to get the grasp with types first. Experiment... ;-) Sergio. |
| ||
| Thank you very much, Sergio. :) As for your first comment, I have some ideas on games I would like to attempt. I'm a big fan (design-wise) of simple games like Pac-Man, Donkey Kong, Dig Dug, Mr. Do, etc. By simple, I mean "single screen, no scrolling, simple layout, few rules." For my first project I would like to attempt something like this, but with my own design (I see that mnay people start with creating their own versions of other games, but I think I would have more fun designing some rules and then figuring out how to implement them). As for 3d programming, I very much like games such as Tail of the Sun and Aquanaut's Holiday for PSX. These are 3d games that have either very simplistic interaction with the world... they are mostly about exploring HUGE 3d worlds, and finding interesting artifacts, ruins, etc. I'd love to do a game like this, but I think I should learn to program 2d first. ------------ As for the second comment, I think I understand what you are saying. I actually understand "types" pretty well; I find them to be very logical. Luckily, the tutorial I read on map tiling came with some source code, so I was able to visualize what was going on. I still have some problems with understanding the concepts... I can't think of anything specific. Your explanation does help though...(how the tile must move, and how the engine decides which tiles are visible and their position). Thanks again! :) |
| ||
| for the thing bout learning the language, i would just keep plowing ahead with the examples and dont worry the first language you learn is always the hardest, once you learn one you can learn the rest quickly |
| ||
| >Could anyone give me a really general overview of the >philosophy behind tile maps? Programmingwise its basically clearing the screen get input from user act on input/do some housekeeping drawing the tiles one after another flip As for how to learn programming... When I started back on the Commodore 64, I used the programming examples from the users guide... -First you need to understand what the program does and how it workd -then you start playing around with the example, changing the way the progeamme works. -then you start expanding the programme by adding more functionality... You will find that at some point you have rewritten the entire programme and expanded the way it works to a point where nothing is left of the original. Then you just start over with some more challenging programmes. Andy |
| ||
| The philosphy behind tile-mapping is actually quite simple. It's a way of storing a huge game map using the least amount of video RAM possible. Or, breaking your game map into a series of simple 'building blocks' known as 'tiles'. The easiest way of explaining these is to image a brick wall. Say you want a brick wall that is 640 x 480 pixels. You could draw a wall of that size, but it would consume 640 x 480 x 16 (the last figure being the bit depth of your screen) 600K. However, if you use a tile of 32x32 that represents a brick wall that you then just draw as many times as necessary to cover the screen, you end up with video RAM consumption of just 32 x 32 x 16 = 2K! That's a saving of 598K!!! The technique is something that has been around for ages and was always something of a necessity on old 8 bit computers of years gone by. In terms of your second question, the points have already been raised. I.e, mess with examples that you have and figure out how they work and start small when it comes to your own projects. A lot of the satisfaction comes from solving the problems you run into. I've often been lying awake in bed working out how to resolve a particular problem only for it to hit me at 2am! The scary thing is it was nearly always far too obvious! |
| ||
| best way to think of arrays and tile maps is like this, imho: your array is a piece of squared paper, x squares wide, and y squares tall. in blitz this is created by: dim myarray(width,height) your squared paper is numbered along the bottom (the X axis) the numbers 1 to width, and up the side (the Y axis) the numbers 1 to height. this is how you access a particular spot in your array. then imagine that in every square on your piece of squared paper, you have scribbled a number. this is like saying: myarray(x,y) = 1 or myarray(x,y) = 423 your drawing function then cycles through every slot in your array and does something with this number. for extreme basics, it could just use the text command to show you what number is in that slot. alternatively, it could be used as the frame parameter in drawimage to show what tile to draw. getting more advanced, you could even use the numbers 1-20 to represent grass where your units move normal speed. 21-25 is water... only boats go there. 26-28 is fire! instant death! etc... hope i didnt just confuse you more... ;) get in touch somehow if you like... il help as much as possible :) |
| ||
| I don't know if this will help but I did do a Creating A simple Tile Map tutorial on www.BlitzCoder.com in the articles sections Thing is though at present Blitz Coder is off line at the moment whilst they upgrade to a new server Also I helped some one else out recently with the similar topic in the beginner area "using gif animations" (something like that) Hope this is of some use to you, Happy Coding - Mikey F |
| ||
| Wellcome Kyouki, to the amazing world of coding. I started a long time ago on the wonderful Speccy, in those days the common way to learn was to spend hours on end typing in code you copied from some magazine or book. Coding is a frustration-reward game (rather like giving orders to an idiot) actualy an idiot is better because at least he does stuff slowly, but then when you get something to work you feel so happy, you need to run around hopping up and down. My main advice is divide a big complex task into smaller simple ones. Also I advice against trying to code a full game at first, this will usualy lead into frustration. I would try at first to code simple things (save all these little programs, great for future reference) because if you start making a long program, things will start getting complicated soon, and code will begin to look like a nightmare (full of patches here and there). So if you have coded before hand all the routines you need for your project, coding a big program becomes easier as you know what you need and how to go about it. Nothing worse that have a game almost complete, you add a new feature and you realize that the "already written" code has to be extensively modified to permit this new feature. Hmm this post is becoming longer than I expected, well if you want to use tiles this is what I would do. a)Borrow some tiles b)Try putting a single tile onto the screen, experiment pasting it on different positions, then paste it repeatedly to cover the whole screen, use 2 tiles, make patterns etc. c)Now put your tiles on an empty image, and then put the image onto the screen, try different methods, try putting only part of this image onto the screen... d)By now you may want to scroll, at first just scroll a simple screen...etc. e)Blah, blah, blah I hope this helps. PS. It's also quite useful to play around with other's code and try to work out how it works, also don't be shy of changing bits to see what happens. |
| ||
| Hey guys, Thanks everyone for the help! I've been busy at work so I haven't been able to try working on the tile engine again, but I have read your helpful posts and think I have a better understanding! :) I also received my copy of "Learn to Program 2d Games in Blitz Basic" AWESOME book! |
| ||
| Programming, of course, is telling a computer step-by-step how to get a job done. Game programming is best done by coming up with an idea of what kind of game you would like to play, first. Then, step-by-step, write out on paper what you want to accomplish. For instance... Space Invaders. Have rows of buggy things go slowly back and forth on screen, while allowing player to shoot at them. If player hits one, it is destroyed (ie, removed from the ones moving back and forth). When a certain number/percentage of invaders are destroyed, begin to pick up the pace of their back and forth motion. As invaders (going back and forth) reach a side, they move down a bit closer toward the player (hey, they're invading, you know!). Continue moving them back and forth, coming closer and faster, until they are either all destroyed, or until they reach the bottom and then the game is over. In the above example, by writing out what you want to do, you can then begin to read up on the commands and see how they can help you accomplish your goal. In other words, commands are there to help you get the job done. You won't know what commands to use if you don't know what it is that you want to accomplish. Writing it out helps clarify what you want to do, and sets you on the path to programming it out. Once you have the general overview done, you can begin to break the game down into smaller, more manageable pieces, such as: Initialization (where you set up the names of the variables you are going to use, assign starting values, etc). Introduction: the first thing that the player sees as your game is started; it may include a menu (to give a player an idea of what the goal of the game is), or perhaps allow the player to set up his playing piece on the game screen (select a car for a racing game; or select a scenario or map; choose what weapons/armor/statistics to use, etc) Start the game. Mainloop: In the main loop, this is where all the action goes on. It is designed to repeat again and again, until certain conditions are met. In the Space Invaders example, it goes over and over until you have destroyed all the invaders, or until they have destroyed you (or maybe until you have to use the restroom). Endloop Conclusion: Give the player choice to play again, or just exit the game, whatever. Clean-up. Free up system resources that were grabbed for graphics, sound, etc. The above is of course an extremely simplified overview of how to program. The beauty of BlitzBasic is that it makes creating a game so darn easy! |
   |