In our discussion with Laz today (Friday week 4) we managed to suss out some key issues with our current documenting progress. Laz liked the physical production that we were progressing through but wanted entirely for us to stop moving forward and instead to define, design and document what we want each step to do and to look like (as a group). Although we have a lot information spread across a lot of different filings for the group documents, we lack any form of formal design brief/document. It shouldn't be too hard to collaborate our current ideas into the document and our current status in terms of certain game mechanics, visual manners etc.
After the desk-crit, we formed a meeting outside the Fishbowl to organise our tasks again and to understand the stages we were to complete by next week or the week after AND how we are going to document it in the brief.
Connor, Keiko and I discussed the method of a resource-loader to be programmed early on in the development stage, that way any future testing can be undertaken without the need to load individual textures, models, etc. as we go. I'll be attempting to complete this over the next work cycle, or at least get the data structures figured out and how I am to construct the physical storage of the data. At the moment we're looking towards using a text file that allows reading in of filenames (with conventions being used across each member of the group because asset names have to be manually added). Once the filenames have been read in they are then added to a map that consists of the filename and an empty Object (can't do pointers in Javascript sadly, would have been more efficient). As each asset is required in the scene then it can then be loaded from the bundle using the name if and only if it's place in the map is currently a null value. (i.e. it hasn't been read in yet)
There's not much else to report on other than we discussed the max card amount for the virtual game as it has to be mentioned sometime because in the physical world a person can hold an infinite amount of cards cause the physical space is easily arranged albeit manually... We're still conceptualising the constraints on card limits but we assume we should be using a limit on active cards to be around 8.
