Rendering NPCs

[Penguin-Benjamin]

https://gyazo.com/6f133517450d94d2ca70107ccfc8a87c

[jasonmash]

Just noticed the clues array has BigFeet as a clue, but in the responses array, it's called BigShoe. I think that's my fault from an example I posted on another issue, but that does need changing as the clues should correspond to responses.

You're going along the right lines I think, although we'll need to add more of the clues from the spreadsheet on Google Drive.

[Brookke]

Yep looking good, not sure you need the var Colin = bit though. but otherwise it is looking good :)

[Brookke]

@Penguin-Benjamin I think there is a dialogue speadsheet in the drive that @beno11224 wrote, that could help if you are struggling for responses

[joeShuff]

So is the JSON stuff being used for just the conversation responses for the NPC, or as the entire data structure for the NPC?

[Brookke]

@jasonmash was planning on using it for the NPC data structure I believe, but I am not certain on the plans of this. As doing it all in there could cause some issues

[joeShuff]

Seems bad to use it just for the NPCs and not every other data structure that we have... I think we should just have it define the conversation for that character and link them with their name. new NPC("Colin") links to {name:"Colin"}. But it's up to @jasonmash

[jasonmash]

That's a good point @joeShuff, we should probably be consistent about the way we provide game data. I'd argue JSON is a better way of storing it than having a tonne of Java declarations in a file, but it's not worth changing what we've done already over to it. I don't mind which approach we take at all, just as long as we've got something working. Regarding the NPC structure, my logic was we were storing dialogue in JSON, so why not stick a couple of extra NPC properties in the same file while we're at it.

What do you think about saying future data storage is all JSON based, and leave the stuff we've done as it is unless we get time to convert it over?

[joeShuff]

Well I think you're the only one who has any experience with using JSON, and I think that you are one of few in the year who have done it. The amount of time we have left should go to adding new features, not changing existing ones.

[Brookke]

Just a note, I've done lots of JSON before. And @Penguin-Benjamin has learnt it too. It's very simple to pick up so shouldn't be a thing we avoid because of it seeming that not many people know it. Agreed we shouldn't change some of the existing things over however I am not apposed to having The NPC partly/completely constructed from JSON

[joeShuff]

I'm not against it either. Other than the fact we haven't done it for other data structures. I can understand doing it for conversations because they are very complex and will need some easy to read data structure. But some classes have been designed so that their declaration is easily understood. We've got Rooms, Player, Clues and all of which are defined within code.

[Penguin-Benjamin]

So what is next for NPC's?

[Brookke]

We need to parse the JSON file, decide on what assets we are using for each one

[Penguin-Benjamin]

Okay am a bit busy today but I can look at choosing assets tomorrow if that's helpful or even make some if that's better.

[joeShuff]

@Brookke sent an email to Richard and Fiona. If we can't use the costumed characters from the site. We can use the other designs they have on there.

Don't know if the link was pasted into here checks It wasn't. But I got it...

http://untamed.wild-refuge.net/rmxpresources.php?characters

These are the assets we will use. I am still not sure whether we have decided to use JSON to generate the NPC or in code. Considering the JSON will tell us about their clues and their responses, there are little attributes that need defining to I think they should be defined in code.

Then we need to work on the AI for them. Simply just taking a step in a random direction every now and then. Then rendering them onto the screen using the OrtogonalTiledMapRendererWithSprite class.

[Penguin-Benjamin]

Okay thanks Joe