I thought this would make a good discussion, so I decided to create a new thread.

Quote from Zman's reply to the "Trouble accessing my 2D images" thread:

We certainly need to do some thinking around what happens when people provide their own content. The original thoughts were always that people learning would use the assets we provided.

The only recognition we provide for your own assets is when you build a stanalone exe - we ask what your assets are.

Seems like what we really need is a way to group your program with your assets.

How about in a future version the .phrogram (yes we will change it next time) file is NOT a text file but actually a renamed ZIP.

Inside the ZIP is your source code text file and a folder with all of your assets. You would add the assets into Phrogram through the IDE. We would know where to look and also people could actually email all their source around in a single file.

This does mean you couldn't open your source up with notepad though

 

What does this mean to all of use who are used to .KPL files? Will the actual source file be a .KPL, for backwards-compatibility, or will it be something else?

How will this affect the way we package our assets? Will Phrogram have an extended "Create Package" feature that zips it all up for us( that's on the 'list of nice things we would like but are not really necessary' )?

What about filesize limitations? If you have hundreds and hundreds of images for, say, an RPG-style game then you couldn't have them all in one .phrogram file or people wouldn't be able to download it for the size. Instead, would there be a "Images_people.phrogram" for the people sprites and "Images_UI.phrogram" for the UI sprites? 

.KPL files would still work. Just that new fies would be stored as .phrogram - makes more sense since the product has been renamed for quite some time now. However you would be limited to 'features' of that file format what ever it is that we would choose to add. Inside the .phrogram 'zip' we would have a source code file (or maybe more than one - its a feature people have been asking for!) AND the assets that phrogram needs.

Packaging is about making an installer without source code so that process won't change much. But whereas right now you have to manually select all the assets that you need (and if you miss any risk an error) if we require you to add assets at compile time (well ones not in the phrogram library) then we can make sure they are all there for package.

The kind of file I am talking about is really for developers where you can give a .Phrogram file - how often in the forums do people post the source and then spend 5 posts giving people all the assets.

Not sure what you mean about file size problems - if people need all your graphics and sound to play the came does it matter if they get 1 3Mb file or 6 half Mb files. Either way you look at it they need everything. Its surely much better for beginners to get a single file with everything they need.

Bear in mind I'm just brainstorming now - getting feedback. None of this is even close to being implemented. So rip away and add whatever you think. But remember our focus is making things simple for beginners... hard to do now a lot of you are no longer beginners... its certainly one of the hardest things I have to do on the Phrogram team.

Oh and see this thread too for some otehr ideas I had about changes to the file formats.

http://phrogram.com/forums/thread/5222.aspx

Team Phrogram,

I must admit I am not too smart in this area - as I have always simply (and I mean simple - as the Phrogram IDE and runtime environment is indeed lovingly simple) done my programming in the IDE/runtime environment that is dynamically and automatically created for me with little need to understand what is going on.  That, IMHO, is a tremendous strength.  Please do not lose that.

What is around the corner for me is the ability to package my Boo! program "for sale".  Now I have packaging concerns and usability concerns.  See the original thread (http://phrogram.com/forums/thread/6618.aspx) for what I am trying to do.

My point is that I think it is easy to mix the two needs and end up getting confused.  I *think* that there should be one set of requirements for the Phrogram IDE/runtime environment to keep it simple.  And, a second set of requirements for package distribution (and distributed packages - such as the ability to access a subdirect relative to the parent directory that my Boo.exe happens to be running in today.

So, I suggest that we be very clear about what we are requesting.  If it be for the IDE/runtime, package distribution, or both.

Regards,

Zman,

So, my suggestion, given your suggestion of a 'zip' .phrogram file that will hold all the assets for a program is as follows:

1) For the IDE/runtime environment you allow me to build the subdirectories as needed to support my program.  I can see and edit directly the files.  As this is a development time, I can edit/view files directly be they graphics or text configuration files.  Enough information is know by the IDE to know where things are placed to find them for compiling into the runtime environment for debugging and testing on this one system.  Keep it simple is the mantra.  Maybe, a simple Phrogram would keep all assets in a "standard" subdirectory where Phrogram always looks.  For more complex... you allow us to specify our own subdirectories and define them in the IDE or the Program source.  Unless I do not understand the zipped business... I would suggest that this IDE/runtime environment does not include zipped packaging.  While I am developing I am viewing and changing my asset files all the time.

2) If I want to package the executable with all the assets needed - then I select File -> Create Package.  If you need additional information for packaging you can ask at that time.  Yes, here, for sure, I would expect everything that is needed by the program to be packaged up into one file.

Now, that the executable program is sitting on somebody else's computer on the other side of the world this can get "tricky".  I might expect that there would be some assets that could and *should* remain zipped to protect them from change and user error (deleting a graphic file asset by accident in a subdirectory, for example).  But, my program Boo! expects that the users will be generating and adding 100s of text files (it is a play by e-mail game).  These should not be part of a single zipped file due to the complexity of a human to work with them.

So, and I am just thinking out loud here, maybe a separate "package source" and a "package executable" pull downs from the File menu.  One to package the .phrogram file for sharing in the IDE/runtime environment.  The second for compiling and packaging for sale and distribution.

Regards,

The mention of a ZIP file was just how we would implement it and to show that advanced users who wanted to 'fiddle' could rename to .zip and poke around inside.

For you as an end user you would not need to know or care.

In the IDE you would create 'mygame.phrogram' jsut as you do today. You would see the text editor but in addition you would see a folder (dont worry about where or how) called 'mygame assets'. You would drag and drop into that just as you are doing today with your bin directory in explorer. Where and how its stored would be something for us to worry about.

Now all the assets you need are connected to the phrogram. We can give you intellisense maybe when you need to load one. We know what is needed when you do come to pacakge the final product too.

When you want to send source code to the forums or a friend you just take the .phrogram file and everything goes with it. When they open it they will see the same source code and the same assets folder.

We may store it in a zip but you will never have to worry about that. The IDE will give you the view you need if and when you need to change anything.

I'm trying to avoid 'package source'. The source will jsut be one file (forget I ever said ZIP) that contains everything the user needs.

Package EXE will be similar today that it shold make a .msi installer with all the prerequisites that are needed such as .Net, DIrectX and the Phrogram runtimes. It should install to Program Files and behave like a proper windows program.

The issue you have with your user datafiles is a totally different thing and I'm goig to move it to a new thread becuase its really just a programming issue not an asset or packaging issue and I want to keep this thread on track. See http://phrogram.com/forums/thread/6647.aspx

christmaswhistler:

I must admit I am not too smart in this area - as I have always simply (and I mean simple - as the Phrogram IDE and runtime environment is indeed lovingly simple) done my programming in the IDE/runtime environment that is dynamically and automatically created for me with little need to understand what is going on.  That, IMHO, is a tremendous strength.  Please do not lose that.

Absolutely not.... if you EVER think we have lost simplicity this is a huge problem for us. I see this packaging of everything in one place as a way to improve the simplicity. For source code sharing (not packaging that is a separate issue) I think that 'here is everything' and 'it just works' improves the simplicity. If you use assets from our library then nothing changes. If you use your own assets then instead of physically copying them to the bin directory you just 'add' them to your phrogram and we will keep track of them for you.

What is around the corner for me is the ability to package my Boo! program "for sale".  Now I have packaging concerns and usability concerns.  See the original thread (http://phrogram.com/forums/thread/6618.aspx) for what I am trying to do.

The packaging in current Phrogram is very minimal and certainly not designed to produce something of production quality. When you get to this stage drop me an email so we can make sure you get all the help you need as this is an area we need to look at too. However having the source code aware of the assets needed makes the packaging less error prone.

My point is that I think it is easy to mix the two needs and end up getting confused.  I *think* that there should be one set of requirements for the Phrogram IDE/runtime environment to keep it simple.  And, a second set of requirements for package distribution (and distributed packages - such as the ability to access a subdirect relative to the parent directory that my Boo.exe happens to be running in today.

I see them as 2 separate areas - source code sharing and final product sharing.

I would rather people don't even worry about directories... myphrog.program just just know that it needs ball.jpg, wall.jpg and floor.jpg. When we package them up your app just finds them becuase they are a part of that application. Under the covers we may make directries for the assets but the name of the game with Phrogram is to reduce the things you should worry about.

ZMan:

The kind of file I am talking about is really for developers where you can give a .Phrogram file - how often in the forums do people post the source and then spend 5 posts giving people all the assets.

I'd be inclined to suggest you add a third section to the Create Package dialog above the Package Location section.  Something called Package Type that contains two options: A: An installer package for stand alone execution on another computer.  B: A source code package for transfering all the code and media files to another computer. 

I also am of the mind that while under devlopment, artwork and media files might be changed often and the 'possibility' of not knowing which files are being used (the ones I see in Explorer, or the ones stored in a package somewhere) could very easily be cause for confusion. Leaving the source files alone until requested to package them makes the most sense to me. 

 It would also be nice if you could add the means to automatically populate the Media and Support list, as you seem to suggest your .phrogram scenareo would.  One (possibly easy to implement) method would be to assume that all code and media source files are in one directory and use that directory to populate the list.  Then the 'easy' explaination for beginners would be to always create a new folder for each project to hold all the source files. Any artwork or media they need (that isn't already provided in the Media Files folder) would be added to that folder so the package creator can find them.  You may or may not want to search sub folders, or that could be a checkbox option in the new Package Type section.

What would also be helpful (if possible) is a sort of debugging aid that would pop up a (nag) message when (while running in the IDE) any file is loaded that does not reside in the designated source file folder.  Something to the effect:  "The file  <path>\<name> is being loaded from a location other than the designated source files folder."  With buttons to Continue, or Stop at the offending line, so that all they need do to remove that nag dialog is move the file into the folder and change the code to point to the new location.    

LFS:

What would also be helpful (if possible) is a sort of debugging aid that would pop up a (nag) message when (while running in the IDE) any file is loaded that does not reside in the designated source file folder.  Something to the effect:  "The file  <path>\<name> is being loaded from a location other than the designated source files folder."  With buttons to Continue, or Stop at the offending line, so that all they need do to remove that nag dialog is move the file into the folder and change the code to point to the new location.    

Even better, add a third Repair button to move the file and alter the source code to point to the new location!  <g>

From experience (not with Phrogram), there is a large downside to storing all software assets (source, media, etc) in one file. That is source control.

For source control, you want each file to be stored separately, so that changes between each committed version can be tracked, allowing

- retrieval of an earlier version

- merging of changes from multiple developers or from "maintenance" branches with "feature" branches 

This is impossible if files are bundled together, and especially if they are stored in a binary file.  

While source control may be rarely used at present, if we are going to encourage software "best practices", it should become more common in the future.  

This is not an argument against bundling files into an installer, or a "community-sharing file format". I am merely arguing to keep the format that is used for everyday development. And it is essential that the source code stays in text format.

All good feedback. Thanks

By keeping source 'prepackaged' I'm trying to avoid adding new commands and things for people to think about. I want then to just think of mygame.phrogram as everything they need. Worrying about folders to search an instructing people to make an asset folder doesn't really follow with the keep-it-simple philosophy.

However I do see your point about duplicates. If you add ball.jpg to your game then you need to know there are 2 copies. The one you edited and he one now attached to your game. Though your second example of making a folder seems to imply making copies too - just them doing it manually. I need to think some more about this scenario and see if its something we can make obvious or if its something people would understand.

I see the 'container' in the IDE looking just like an explorer folder with full drag and drop BTW so it wouldn't be a new thing for people to learn. It could support sub folders and searching if we deem that something that beginners could ignore.

As for 'add a third button'.... once we start adding more and more buttons we start getting into the realms of needing more and more documentation and less and less ease of use for a beginner. Its a common problem in applications that as they grow and add more features they need more 'options' to make things work in slightly different ways. You end up with dialog like MS Word than have 12 tabs and each tab has buttons that go to sub dialogs. All of us here are pretty solid developers - stuff like that doesn't faze us. But I've seen usability videos for windows and Visual Studio at Microsoft and in general options just confuse. They en up there because developers say 'well some people want A and some people want B'. Nobody can decide which is best (or don't want to decide) so they take the easy way out and make it configurable. This isn't something acceptable to Phrogram. I would even like to get rid of 'advanced mode' in the menus on day but I've not even started to think about that yet.

As for the nag message... I've thought about something like that to jsut track usage and possible just give warnings in the output windows.

"Warning: This application may not work on other computers becuase not all the art is registerd or in the Phrogram library"...  trying to fix as an app runs might be more confusng to people...

I wish I had lots of money for usability testing...

ZMan:

For you as an end user you would not need to know or care.

In the IDE you would create 'mygame.phrogram' jsut as you do today. You would see the text editor but in addition you would see a folder (dont worry about where or how) called 'mygame assets'. You would drag and drop into that just as you are doing today with your bin directory in explorer. Where and how its stored would be something for us to worry about.

The "assets" 'virtual folder' that is only accessible from within the IDE would (IMHO) add confusion to the process rather than remove it.  While it may help the IDE maintain a list of assets, it does virtually nothing to help the end user organize the source files.  Consider what would happen if I drop File A into the assets for project AA and drop file A into the assets for project BB.  Now if BB needs a different color scheme, what file should I edit?  And, when I edit the file for BB, what happens to the file for AA, etc...

Keeping the IDE's Files list in sync with the system's folders is a better approach in my opinion because the user gets the same view from the IDE and from Explorer. Having things look the same is going to be easier for the younger mind to comprehend.  The (right click) Open folder method in the IDE gives them instant access to an identical list via Explorer.  Adding Copy and Paste to the IDE's contect menu might be something to consider so that media files from other projects/locations can be copied to the current project folder.

Lastly, there is that issue of having a new folder for each project. (previous post)  That could be enforced by the IDE (so the kids can't make a mistake) to say that each new project must be saved to a folder by the same name.  The first line of the program is "Program XYZ" and that could be used to name the project folder.  When they go to save a file, notify them if there is already a KPL file of a different name there, or create the folder if it isn't already present, and put the files there, then refresh the Files list to include the new folder. You could track that one line (like you do the filename for the tabs) and (when saving) offer to rename the folder if they changed that "Program XYZ" line from the previously saved name.

Just an observation about keeping it simple.  If you're adding complexity to Phrogram, you're adding complexity to Phrogram.  (profound, no? <g>) A simple desgin should really be simple to implement.  (There are of course exceptions, but on the whole...) 

Source code control is a fine point... I have another 'feature' to track about if there is a way we can 'Phrogramify' some kind of simple version/history becuase people do lose things and we would like them to have a best practise to lern as early as possibly (and asking people to grok SVN or something else is too much). So yes a binary file does kind of mess with that.

The 'actual source' would still be a text file even in my proposed solution... just would be inside the file. I wouldn't want anyone diffing a binary source.

ZMan:

As for the nag message... I've thought about something like that to jsut track usage and possible just give warnings in the output windows.

"Warning: This application may not work on other computers becuase not all the art is registerd or in the Phrogram library"...  trying to fix as an app runs might be more confusng to people...

I wish I had lots of money for usability testing...

Well, you have a willing community here...  :)

Just a comment on all of those debug windows, I would suggest you consider them as features for the advanced users.  I wonder how many acutally ever look at them.  There are too many, and about the only time I use them is for Trace commands which means I have to go hunt for the right window where those Trace commands appear.  Having those windows pop in and out (up or down, or whatever) is more of an annoyance than the few times I might want to use them. (Why would I use a Notes window when comments are supported?) The IDE's squiggles show when something is wrong.  I may be biased having used just one debug window for everything for so long....

LFS:

Well, you have a willing community here...  :)

We certainly will be using everyone here but, and don't take this the wrong way, most of us on here are more advanced and older than they people we want to sell in bulk to (schools!). We do have some local schools using it who maybe able to help.

Not sure if any of you have ever done an official usability test where you bring people in and video/watch them use your app unassited. Its one of the most humbling things you can ever do becuase half your assumptions get blown out of the window in the first 10 seconds. Even if we went to talk to school teachers they would probably be better than us but even they project their abilities onto the kids. There was a great talk at GDC this year about usability testing kids games which just backed up everything I knew. Basically adults don't, in general, have a clue what kids like. 

Just a comment on all of those debug windows, I would suggest you consider them as features for the advanced users.  I wonder how many acutally ever look at them.  There are too many, and about the only time I use them is for Trace commands which means I have to go hunt for the right window where those Trace commands appear.  Having those windows pop in and out (up or down, or whatever) is more of an annoyance than the few times I might want to use them. (Why would I use a Notes window when comments are supported?) The IDE's squiggles show when something is wrong.  I may be biased having used just one debug window for everything for so long....

I agree... I've not decided what to do with those... taking features out it much harder than putting them in!

But all the feedback here is good and has me rethinking several of my ideas... I'm busy on other projects right now so I can't say when any of this would be implemented but since the subject came up I though it would be a good talking point.