Tile-based tutorials

[nevon]

If you are going to benefit the Love community, PLEASE PLEASE explain how to do this area transfer and area loading technique. It is NOT an easy thing to find, and I'd love you for it forever. I'd LOVE you for it forever.

That's because there's no single way to do it. It all depends on how your game is structured. If you need a tutorial to create multiple maps, you should probably be doing something simpler to become a better programmer and game developer first.

[kikito]

The problem with ALL video game programming tutorials on the web are that they ALL go over the same shit. Without trying hard, I can find another tile map tutorial on the web and have a character moving around it no problem.

Well, maybe just getting the character moving isn't enough. If you end up with a bunch of global and 2 big functions doing everything, it's difficult to build on top of that. I'll try to make it a bit better than that.

In some games, you get to a point on the right side of the map, and immediately after you are on the left side of a new map.

That is common practice and usual. For example, entering a door in Zelda moves you to a different map.
The only difficult step there is having everything well encapsulated, so you can discard all the information related with one map before loading a new one.

That should be easy to do - just unload one map, load the other, and you are done.

Sometimes they mask the loading times with a "fade to black" transition or something. That's the part I won't do.

You never actually warp to the other side of a new map, it just continues to load in new areas seamlessly.

Fiuu! That's another thing entirely. I don't think I'll be able to do that on this tutorial. (I'm not interesting on that, really - I favor smaller levels)

If you are going to benefit the Love community, PLEASE PLEASE explain how to do this area transfer and area loading technique. It is NOT an easy thing to find, and I'd love you for it forever. I'd LOVE you for it forever.

Well, I'll have to resign myself with only half of an eternity of your LOVE then. Don't worry, I'm not jealous

[ShadowProtocol]

In some games, you get to a point on the right side of the map, and immediately after you are on the left side of a new map.

That is common practice and usual. For example, entering a door in Zelda moves you to a different map.
The only difficult step there is having everything well encapsulated, so you can discard all the information related with one map before loading a new one.

That should be easy to do - just unload one map, load the other, and you are done.

Lol, thats exactly my point. It's easy to do, FOR YOU. Please include this map transition in your tutorial. Thanks Kikito!

[Robin]

Lol, thats exactly my point. It's easy to do, FOR YOU. Please include this map transition in your tutorial. Thanks Kikito!

And it could be for you too. It will flow naturally from your understanding* of programming and how a single map works.

That's the important thing. Understanding how it works, how it all fits together. At a certain points, tutorials can't help you further and you need to understand the code you're writing and the code you will write. A good tutorial will give you all the steps up to where you can do things on your own. A great tutorial does that, and helps you understand the how and why.

* I mean a deeper form of understanding here and throughout my reply, grok if you will.

[Ryne]

Lol, thats exactly my point. It's easy to do, FOR YOU. Please include this map transition in your tutorial. Thanks Kikito!

Map Transition could be as easy as setting a variable like "currentmap = map1" then just having multiple maps. Once the player completes a certain objective, walks on a certain tile, or opens a certain door you could just do "currentmap = map2". I think, that you think, it's harder than it really is.

That is a very good point.

I suspect I will face a trade-off situation sooner or later. I will have to decide between making it "easier to understand", or "easier to extend".

Perhaps the world would be happy with a good tile tutorial (without middleclass) for now, and a more advanced on later. I'm not certain, but I think it would be easier to create the tutorial without middleclass, then later use that same tutorial and expand on it using middleclass.. I don't know, just thinking out load.

[kikito]

I've done some progress on this front and I'd thought I'd share it.

I've decided to target Ryne as my intended audience for this tutorial. This means I'll spend some time explaining the basics, and will not use middleclass until absolutely necessary.

The tutorial will be (provisionally) divided in 3 main parts: Tiles, Entities and Scrolling. Each of these parts will have a number of subsections/steps/lessons.

I've finished coding the Tiles part, and have started writing the tutorial text itself. I'm putting everything (code + wiki text) on github, because it's easier to use than LÖVE wiki for me.

Relevant links:

• The code
• The wiki

I'd appreciate any feedback. Please feel free to log in to github and fix any typos / inmigrant Engrish that you may find.

Regards!

[Ryne]

Wow, That actually looks great. I may have spotted a little mistake.

"loss-ness" should be "loss-less"?

The tutorial itself is completely understandable so far. I'm especially eager to see how to efficiently draw a grid using quads (instead of 1 by 1) but it already looks cleaner than the current tile tutorial. I'm putting a hold on my game until this is finished (no rush to you though!).

I also like the exercises, just like in Jr. High-School, where you had work-sheets with repetitive exercises to get in burned into your skull.

Finally, I appreciate you thinking of me in your tutorial!, can't wait to start using it, I'll definitely put it to the test and ask as many noobie questions as possible. Rest-assured it will be a pretty polished tutorial.

Edit: I didn't notice you made part "b" of that tutorial, it looks great at first glance but I don't have time right this moment to read through it. I'll take some time tomorrow to scrutinize it

[tentus]

A couple of English corrections, since you asked for them (always glad to help out someone who asks for it!):

Part A
"at least what do Lua comments look like" -- rm do
"Function methods will allways begin with lowercase." -- always, one l
"probably they work on yours" -- move probably to after they
"they don’t work in all computers" -- probably want to change in to on, for consistency with the rest of the sentence
"Let’s tell about them to LÖVE." -- reword to "Let’s tell LÖVE about them."
"On this example we’ll be needing" -- Change on to in
"These will store the tileset complete height and width:" -- reword to "These will store the height and width of the complete tileset:"
"surrounded by 9 grass tiles" -- should be 8

Part B
"in positions 1,2,3 and 4." -- this is stupid, but you may want a serial comma here... "in positions 1,2,3, and 4."

Code: Select all

TileTable = {
  { 1,1,1 },
  { 1,2,1 },
  { 1,1,1 }
}

Please cover why there isn't a comma after the last subtable: I see new coders trip over this frequently!
"with some strings inside it on a variable called Messages." -- change on to in


Good tutorial, I will look for other improvements to help it!

[Ryne]

I just wanted to post to say that I read the second part of the guide and I completely understand loops now. Which is pretty much the biggest thing that I was stuck in the PIL book. This alone expands my programming skills greatly.

Just a question though, were you planning to expand into platformer's? I would personally love to see that, though I'm sure once you go into collision (which I also assume will describe the player interacting with grid coordinates) it would become very easy to progress it into a platformer. (I also wouldnt mind supplying some sprites for that, maybe even a custom "love-version" of the character in my avatar :p)

Another question I have is, would you be willing to go into map creation using a third part application like Tiled? Integration seems difficult.

Looking forward to part 3, both parts so far have my noob seal of approval.

[Robin]

"In LÖVE, it is not recommendable that your images have arbitrary sizes. Their dimensions have to be a power-of-two.": the first sentence looks awkward. Perhaps it would be better to change it into something like: "You'll want to stick to powers of two for the dimensions of your images".

"2,4,8,16,32,64,128,256,512,1024,…": more spacing between them would make them easier to read.

"countryside.png is actually a tileset containing 4 32×32 tiles.": this makes it seem like there is a fundamental difference between tile sets and other images. Maybe change it to: "We are going to use countryside.png as …"

"Now MyGlobalTable[1] is also a table": it actually isn't, it is just a name that points to a table.

"It precedes tables, just like the minus operator for making a negative number.": I'm not sure "precede" is the right word here, but my native tongue isn't English either.

You might want to consider using more descriptive variable names, especially as loop indices.

One thing I noted was that you seem to require Lua knowledge, but also explain very basic things. One especially is that you assume your readers know how local vs global variables works in Lua, which is quite a delicate topic, but also explain tables and loops, which is a good thing, but all together not very consistent. The loops are the "worst", in terms of that they seem to assume the reader isn't very experienced with programming in general.


BTW, I can edit these pages, would you like me/us to weed out typos and whatnots that way?