Oh no worries, it’s not goin anywhere plus I keep myself busy messing around with other things in the meantime.
And that definitely helps clarify, thanks! I knew what the modulo operator was/did, just wasn’t sure if it was really being used how it seemed (as in the remainder being somewhat literal as far as the tile goes). Thanks again!
I’ve updated the code to make the names a bit more descriptive.
I’m going to redo the diagram using the new variable names becuase I’ve just realised the way I was doing it before probably doesn’t make as much sense in context.
One of the reasons you might be struggling to understand it is because I’m cheating a bit.
Normally you’d use the actual tile indices to index a map and draw the tile in the map,
but because the background is going to be all one tile and it’s going to be drawn infinitely,
but instead I’m drawing tiles from 0 (or -1) to the number of tiles on each axis.
Sorry for the delay in this but these last few days have been quite busy for me.
Oh no worries on the wait, sorry it’s been taking me as long to grasp it, but I’ve been intermittently working on other stuff to keep busy in the meantime… I can just see the camera system being more beneficial too, so I’m also holding off on working on anything too major til I get it (so I can use it for other applications as well). I’ll get back to it tonight though and try to get it worked out. Thanks again!
Actually, now that you mention it, ive started another game and im now at a point where using the tile indices should make more sense to me (and i would need to adapt the camera for it, too) but im still have a hard time, for a few reasons…
Mainly, im trying to figure out how to change what i have so i wouldnt have to rewrite it entirely (because so much of it is dependent on how its written now)… also since i would be using it in different ways between the games ive started I dont mean to bounce around, thats just sort of why ive been having a problem…
As for this game, since i want to repeat the actual map coordinates im confused as to how id do that now too… even if i just hold off on changing the flight part for now (due to the parallax) and only try to modify the exploration part (which is simpler and also repeats the same sized tiles).
And then additionally, i have another game i just started. Just noticed the lack of RTSes on here… i know these are due to limitations but i thought why not make a simplified/one-bit RTS and started on that (which is what the rectangle question was for)… nothing too crazy considering the limitations, just something little/portable. At the moment its the just the cursor/rectangle bit, a randomly populated 2 dimensional array (filled with 16x16 rectangles for trees, rocks, or empty space, but i can maybe work this into better patterns), and a camera object (which is currently set up to scroll like this one, but i am hoping to change to an actual camera using what you have here). Since this uses the tile indices i may have better luck giving it another look over with that in mind too, though.
You’d have to loop the coordinates of objects in the world when they move past the ‘edges’ of the world.
@Botisaurus was working on a turn-based strategy, but he ran out of memory,
so he’s been reworking it when he gets time spare.
(I’ve been assisting him from time to time.)
I think one of the reasons Arduboy doesn’t have many RTS games is because usually RTS games are heavily reliant on hotkeys.
I think at the very least you’d have to be able to pause combat to go through the menus,
otherwise you’d struggle to keep up with the action.
What exactly would the difference be?
One of my other drawings might help with that one:
Awesome, thank you! I’ll look back over that tonight. May try to start back from the ground up this way also, just because it would probably be easier for me (not that the entire thing would be scrapped, I could just start over restructuring it and pick the old one apart)
Yeah, I would think that and the size… small screen, but also data wise would be difficult to program all the necessary mechanics and enemy ai… but I was thinking even something as minimal as populous (the ps1 version, not the original)… was a simplified RTS but still made for some solid gameplay.
I’m still kicking around ideas for that because it doesn’t always need to be as traditional as PvP either, if size is too much a limitation I could always try to make it something like building up a small settlement and survival, resource management, occasional animal attacks, etc.
But since I’m not tiling that I suppose the camera system I have should work just as well. I just got most of the stuff fixed in that one, just have one more thing then I’ll shift back over to this and rewrite a bit. Thanks again!
At the moment I have trees and rocks in their own arrays like I have my people set up, except the resource arrays are populated randomly (as far as location). I was thinking to add them to another array to track state (0 for harvested, 1 for populated) and have them change states back to populated after a specified time. But they need to be overhauled to reflect a similar structure as my people, that saved me a 3% of ram (sorry, wasnt paying attention to bytes) just changing my people to how you showed above so im sure itll save some there as well.
Im sure memory limitations will be a big factor in how things work out, thats why i didnt set on any one idea initially, but im sure i can work it into something playable, hopefully.
So Im starting from scratch here and figure i should break it into parts for the flight and on foot (like i did initially)… started with the on foot part (due to lack of parallax) and ran into the first issue…
It seems that my playerSprite coordinates line up with the camera in a way Im not sure how to use them.
If I do:
then my player sprite seems inverse to world coordinates (moving the camera moves the sprite, but inverse).
I would think that i shouldnt be adding or subtracting it to the camera coordinates at all because the sprite is meant to be stationary in the center of the screen, but the object coordinates dont actually correspond to the camera coordinates (the camera 0, 0 is offset to the right of the sprite coordinates 32, 64). I would imagine this is due to the camera offset being used in the camera code, but im not sure how to account for this when placing my player sprite.
Not just because of the possibility of WIDTH and HEIGHT not always being 128 and 64,
but also because it shows that the 64 and 32 aren’t arbitrary numbers - they have a specific meaning.
Secondly, is position supposed to be the centre or the top left corner?
If it’s supposed to be the top left corner then to have the sprite drawn truly in the centre of the screen you’ll need to subtract half the width and height of the sprite:
Oh, alright, thanks! I wanted the position to be center, but wanted it to share the same coordinate system as the camera (so even though the camera is at 0, 0, if the sprite is in the center of the screen its at 32, 64 like it should be globally), but giving it a more direct relationship like that definitely makes more sense so Ill change that for sure. Thanks!