[community project] RPG

[Sorunome]

Also, added to the demo for tilemap loading now dynamic flashing of sound data off of the sd card (damn, that is so fast, it's done in the blink of the eye)

Are you using the sd card that came with your Gamebuino? Or are you using a larger size, faster one?

I did indeed use a different one, after removing a minor glitch in my sd library I tested one that shipped with the gamebuino (IDK where my second one is, i just noticed o.O) and I didn't notice a speed difference, so yay!

As for the black/white idea, it's not original [https://games.yahoo.com/game/shift-flash.html] but it's been floating around in my head for a while. I was inspired by the fact that black and white are the only colors available anyway, why not make a game utilizing that concept? Also, give me your honest opinion of the storyline. I can always start with a blank slate, new original ideas, but I thought I would start with a rather generic RPG story.

Well, I am un-innovative with story anyways, so yeah.... I think it's good ^.^ But, what do the others think?

As for black/white, fortunatly I just happened to read up documentary on the screen the gamebuino used recently and it has a negative mode which will be able to turn the entire screen negative without any effort!

Can you upload your code ? Or we should maybe make a repo.

I thought of maybe a private repo and not release the source until the game is done? What do you think? For a private repo I'd use bitbucket as it allows private repos for free, unlike github

_____________________________

We'd also need to think about data structures. For tilemaps my current demo code uses a simple 12x8 tilemap, 8x8 sprites.
I thought another way to save PROGMEM would be to maybe have a 256-byte buffer (8 * 32) in RAM which can hold 32 sprites, so that along with each tilemap the sprites are stored, so that on the SD card you will have [<tilemap-data><sprite-data>]. While this would allow for many unique sprites it would make the tilemap datafile on the sd card large rather quickly.
Also, how to store what is walkable? Should that use the same 8x8 pixel grid or something finder, like 4x4? What about enemies / interactable objects?

[deeph]

I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.

Concerning the repo, I don't think it needs to be private.

I thought another way to save PROGMEM would be to maybe have a 256-byte buffer (8 * 32) in RAM which can hold 32 sprites, so that along with each tilemap the sprites are stored, so that on the SD card you will have [<tilemap-data><sprite-data>]. While this would allow for many unique sprites it would make the tilemap datafile on the sd card large rather quickly.

Yes we could put multiple tilesets on the SD card, separatly from maps data, and load them on the SRAM when needed. We just have to attribuate an ID to the tileset that will be indicated with maps data.

Also, how to store what is walkable? Should that use the same 8x8 pixel grid or something finder, like 4x4?

The easiest solution is to sort the walkable tiles from the non-walkable ones, like I did with this tilemapper. That way all we have to do is to check which tile is under the player's sprite, and if its number is above a certain one, then it is either walkable or not.

What about enemies / interactable objects?

I think that we need to separate enemies handling from every other "events" handling : those which triggers when the player walks on certain coordinates (warps, "cinematics"), and those that are "interactive" (triggered by the player, typically facing something and pushing the A key).

It shouldn't be too hard to code, that's what I do with my current project. I'll show you the code when I got time to clean it up a little bit.

[Sorunome]

I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.

Concerning the repo, I don't think it needs to be private.

Alright, github then?

I thought another way to save PROGMEM would be to maybe have a 256-byte buffer (8 * 32) in RAM which can hold 32 sprites, so that along with each tilemap the sprites are stored, so that on the SD card you will have [<tilemap-data><sprite-data>]. While this would allow for many unique sprites it would make the tilemap datafile on the sd card large rather quickly.

Yes we could put multiple tilesets on the SD card, separatly from maps data, and load them on the SRAM when needed. We just have to attribuate an ID to the tileset that will be indicated with maps data.

I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads. Did anyone benchmark the read speed already? If not I can do it ^.^

Also, how to store what is walkable? Should that use the same 8x8 pixel grid or something finder, like 4x4?

The easiest solution is to sort the walkable tiles from the non-walkable ones, like I did with this tilemapper. That way all we have to do is to check which tile is under the player's sprite, and if its number is above a certain one, then it is either walkable or not.

Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or something

What about enemies / interactable objects?

I think that we need to separate enemies handling from every other "events" handling : those which triggers when the player walks on certain coordinates (warps, "cinematics"), and those that are "interactive" (triggered by the player, typically facing something and pushing the A key).

It shouldn't be too hard to code, that's what I do with my current project. I'll show you the code when I got time to clean it up a little bit.

So what kind of different objects would we need? I can think of:

• enemies
• NPCs
• droppable/collectable items, switches

Also, just so you know, I already have some RPG programming experience (only turn-based, though) in z80 ASM with tilemap compression and stuff, which is obviously not needed here.

[deeph]

Ok for github (I don't remember if I have an account yet, though).

I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads.

Mmh why not but it seems to be a little too complicated, to me multiple tilesets of 32 tiles are enough to make maps with different environments (indoor/outdoor etc..). We should start making so mock up first. If anyone else has 8*8 monochrome sprites that we could use for an A-RPG, feel free to share

Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or something

Yes but again I don't think we need too complicated things like one-way tiles for a such a "basic" game.

So what kind of different objects would we need? I can think of:
enemies
NPCs
droppable/collectable items, switches

Enemies are not technically objects, because we'll have to handle their AI appart from the player. I think that all the other things are triggered by the player (even the objects that falls after an enemy death), and so are part of one of the two categories of events I cited.

[Sorunome]

Ok for github (I don't remember if I have an account yet, though).

Made a repo here!

I also thought about dynamically creating the current tileset needed, but that might result in quite a few SD card reads.

Mmh why not but it seems to be a little too complicated, to me multiple tilesets of 32 tiles are enough to make maps with different environments (indoor/outdoor etc..). We should start making so mock up first. If anyone else has 8*8 monochrome sprites that we could use for an A-RPG, feel free to share

It would allow for way more flexibility, with only set 32-sprites-maps using unique sprites is next to impossible while dynamic loading still works well.

Yeah, that is also what I did for an engine once, that only allows for a tile to be fully or not at all walkable, though, not like "only lower half is walkable" or something

Yes but again I don't think we need too complicated things like one-way tiles for a such a "basic" game.

I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.
Actually, I just got an idea!
If we use 32-sprites spritesheets that will only be 5 bit, leaving the upper three bit for additional data for the tile, maybe have those upper three bits encode how the tile can be walked on? Or maybe use those upper three bits for some other flags, such as if something is supposed to happen when you step on it etc. and have a 32-bye buffer for the sprite walk-data elsewhere?

So what kind of different objects would we need? I can think of:
enemies
NPCs
droppable/collectable items, switches

Enemies are not technically objects, because we'll have to handle their AI appart from the player. I think that all the other things are triggered by the player (even the objects that falls after an enemy death), and so are part of one of the two categories of events I cited.

Oh, sorry, I meant programaticall objects, objects when talking about OOP (Object-oriented programming) In that sense enemies are clearly objects

[deeph]

Can you add me as a contributor ? I've created a new account : https://github.com/deeph-z80

I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.
Actually, I just got an idea!
If we use 32-sprites spritesheets that will only be 5 bit, leaving the upper three bit for additional data for the tile, maybe have those upper three bits encode how the tile can be walked on? Or maybe use those upper three bits for some other flags, such as if something is supposed to happen when you step on it etc. and have a 32-bye buffer for the sprite walk-data elsewhere?

Well we could do that too, it's just a little more complicated.

Oh, sorry, I meant programaticall objects, objects when talking about OOP (Object-oriented programming) In that sense enemies are clearly objects

My bad, I'm just not really used of OOP

I generally prefer using arrays for that kind of stuff, which I think is a concept more close to what the processor understand (so translated more optimally ?).

[superfreaky]

I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.

I'm thinking I should put the background story in the .INF file to save space (I haven't written it out yet but I know it's gonna be kind of big) and then just put little details at trigger points in the world. (This is a warp portal. Walk through it to access a parallel world!( said when you approach the first one)). Also, some brief text when major plot events happen, like when the sword gets found.

[Sorunome]

Can you add me as a contributor ? I've created a new account : https://github.com/deeph-z80

Done!

I thought we wanted to push the gamebuino to it's limits and beyond Plus, it would allow for some way cooler setups IMO. But yeah, we'd need to think of a memory-efficient way of storing that.
Actually, I just got an idea!
If we use 32-sprites spritesheets that will only be 5 bit, leaving the upper three bit for additional data for the tile, maybe have those upper three bits encode how the tile can be walked on? Or maybe use those upper three bits for some other flags, such as if something is supposed to happen when you step on it etc. and have a 32-bye buffer for the sprite walk-data elsewhere?

Well we could do that too, it's just a little more complicated.

I think it would allow for quite more awesome map design

Oh, sorry, I meant programaticall objects, objects when talking about OOP (Object-oriented programming) In that sense enemies are clearly objects

My bad, I'm just not really used of OOP

I generally prefer using arrays for that kind of stuff, which I think is a concept more close to what the processor understand (so translated more optimally ?).

Well, it's basically the same, i'd make an object array pointer thingy, and in that you have pointers to objects. The only thing that requires ram are the variables that go along with the object, the shared methods are in PROGMEM anyways.

I'm ok with the story, as far as it's not too complicated to explain to the player with small texts/npc dialogs.

I'm thinking I should put the background story in the .INF file to save space (I haven't written it out yet but I know it's gonna be kind of big) and then just put little details at trigger points in the world. (This is a warp portal. Walk through it to access a parallel world!( said when you approach the first one)). Also, some brief text when major plot events happen, like when the sword gets found.

What's the point of that if all the data is read from the sd card anyways, that wouldn't add any overhead?


Also, after benchmarking the read speed it seems like we can safely assume at least 140 KB/s which is more than enough for loading data on every screen transition. More detailed benchmarks here.

[deeph]

Thanks !

I need to find time to look at everything more in details now

Also we really need to get graphics

[superfreaky]

What's the point of that if all the data is read from the sd card anyways, that wouldn't add any overhead?


Also, after benchmarking the read speed it seems like we can safely assume at least 140 KB/s which is more than enough for loading data on every screen transition. More detailed benchmarks here.

Ok cool. Interesting that the 2gb sd card was actually slower. What class sd card is it?

I wasn't thinking about how it's all streamed from the sd card, but that allows for much more than a basic text intro. Something like a cutscene complete with music and transitioning images augmenting the text.