There's a couple of options, really for the best collision handling, physics would be best - like 2 sprites, one for the cab and one for the trailer, then make a revolute joint to keep them together. That way everything can be physics, you'd be able to bash into cars and knock them out of the way for example.
Anyway, your questions...
1st question : is it good idea to make whole map at once?
Usually it is better to have the whole map, sprites should occlude themselves so performance shouldn't be a big issue. I would suggest making the map tiles as big as you can, means it would be quicker to make the map.
2nd question (coding...) : how to make logic for trailer to "stick" to the truck part and turning slower than truck. (just like real). ?
With the 2D physics, you'd set each part of the truck for the shape - polygonal would be fine, then position the parts where they should be, and add a revolute joint to the cab part, offset where the pivot point should be. Then the trailer will be attached to the cab, and it'll be dragged around - so you'd have to plan your route, as the trailer might try and cut corners otherwise, which might be a big part of the games challenge.
3rd question : how to start with tire marks on the road (let's say I can make graphics by myself, or at test part it would be just 2 black bold lines)?
You could make a straight skid mark image, then make a bank of sprites using this image, then you could position them under the wheels when skidding, rotate them to suit the movement - imagine it as when you have a Skalectrix or train set, and you lay down the track - that's kinda what you'd be doing, except using a set amount of track pieces. This would result in a trail of skid marks, they'd stay in place until they need to be used again.
4th question: what is best idea/code to make camera "follow" whole truck while traveling around the map?
You can set the 2D camera position, so if you use SetSpritePositionByOffset, then SetViewOffset, you can easily scroll around, zoom in/out even. You would set the camera to the trucks cab position, and it would follow it around the map.
As for types and arrays, well I'll try and make a little crash course...
Say you have a player sprite, and want to keep track of the X and Y position, and Angle. You could use standalone variables, globalised for example:
Global Player_x
Global Player_y
Global Player_Ang
And that's ok if you only ever have 1 player and no enemies. It inevitably leads to code that is increasingly cumbersome to use, because it takes more logic to deal with those variables.
Now, you know that you want the X Y and Angle variables in the player, but you also want them on bullets say, and other players, and enemies... so in this case we'd make a type that can be reused.
Type PlayerType
X
Y
Ang
Endtype
Global Player as PlayerType
So now, you have a typed global variable called Player, which has the components X Y and Ang... like Player.X, Player.Y, Player.Ang - and you'd treat these just the same as with the individual variables. A type can be applied to a variable or an array, it might be more likely that you'd use a global Camera variable with that type, and have Camera.X etc. It's much like designing a database, decide what fields you need, and consider how you can re-use the types to make your code more standard.
If you have lots of enemies, then using the same type for an array of enemies is possible - at this point you might consider adding a sprite reference to the type, like...
Type PlayerType
X
Y
Ang
Spr
Endtype
Then you can store the sprite number in the type, and any variables or arrays that use it.
You'd then dimension an array to use that type, lets say you want 32 cars...
Dim Car[32] as PlayerType
Then, to affect car 0, you would use Car[0].X etc
A dimensioned array is just a stack of variables in a convenient chunk, referenced by their index number in square brackets. Typically you'd cycle through the array, updating sprites, checking collision etc, with a for...next loop.
Arrays are really quite straightforward, I suggest experimenting with them and understanding them fully - they are like rocket fuel for a programmer once they're figured out, opens up a whole lot of possibilities and makes it easy to keep your code neat - it's the definition of working smarter, not harder - you will wonder how you managed without them!
The code is dark and full of errors
