Now that this has been out for a week has anyone got anything more to say about it?
Have you found it useful, not useful (and if so why)?
I’m currently working on a major revision which should hopefully include Dropbox integration (and other improvements), this will allow you to directly update or initially publish your WIP game(s) straight from the IDE. You’ll also be able to sync your IDE settings and preferences with Dropbox, so they’ll be automatically applied when you log in.
That said, there are two ways I can approach the integration, which I would love some opinions on:
#1 I can have the app (when authorized) set up its own internal folder in your Dropbox, it will then be able to read, write and do whatever to anything inside that folder and that folder alone.
#2 I can have the app (when authorized) able to access your entire Dropbox, but only certain file types (so that will probably be just .txt files).
The actual functionality shouldn’t be affected either way, it’s just whether or not people would prefer to be able to set up their Dropbox exactly how they want to and still be able to use the IDE, or whether or not you’d rather have more peace-of-mind (accidental deletion etc) but be required to move any published game WIPs etc into the IDE folder (note that it does act just like the public folder, so they’ll still be playable).
Any and all opinions on that or any aspect of the IDE are much appreciated!
I just really dont use it due i got my gestion manager auto sync with dropbox and when you are depending of public wifi out of house the fact than auto in the bus or train when you are doing other thing game files sync alone. if you make your file i could use auto sync features i just kiss you and only use your system. But the way already is amazing for my android.
I think i preferred it like a public due the auto synchronization
I totally have a man-crush on you! The IDE is awesome. You deserve all the accolades you can carry. Can’t wait to see where you’re going to take this.
Regarding dropbox, option 1 would suit me more. Anything that gives me further control over what I want to allow it do with my dropbox account is a bonus. Would it just be the single folder or could you set it up to make folder1, folder2, folder3 e.t.c?
Also, I might be blind so feel to bash me over the head if I am but is it possible to put a list of all choicescript code on the sidebar or even a tab on top for a pop-out? (set, create e.t.c) Would prevent needing to look it up on the wiki if I forget something which means I can just focus totally on developing within the IDE. If it’s already in there, I apologise!
@CJW Im not sure either why OS has any role for androids. Still I got those statistics by experimenting. Also last to add Jelly Bean – version 4.3 has a new update that makes androids unable to recognize IDE for some unknown reason, if your using a phone android it won’t work but a tablet android still works for IDE not sure why thou.
@Aquos_Boost Glad to hear it!
Is there anything specific that makes it easier, or anything that you think perhaps could make it even easier to use in the future?
@MaraJade I’m still undecided on the exact form the Dropbox Integration will take but I definitely intend to make it so that saving a dropbox sourced file in the IDE will update the Dropbox file itself.
@Marius
Thank you! That’s the kind of response I’m after
Much appreciated, I’m dying for opinions on the DB integration.
You could (I think) make sub folders inside the app folder, but you can’t have multiple app folders.
So it’d be like…
Your Dropbox → Apps → CSIDE → Anything under here can be opened with the IDE.
In regards to the command reference it was (and still is) a definite possibility - but no it’s not currently in there.
I’m a little concious about ‘bloating’ the application, for both performance and usability reasons. In the working revision I’ve actually been changing the UI up a little bit, so I’m not sure where I’d put something like that at this precise moment in time, but it is in mind.
I’ve got rid of the revolving toolbars (there’s only one now) and moved the scene management to its own permanent pane on the left:
Save/Load and adjacent functions will now be managed on its own panel page (like the settings and var tracker) going under the current name of “Projects”.
Command auto(word) completion is also a possibility.
EDIT: @Aera
That IS strange… Thanks for that.
I’ll have to try on my phone once I get 4.3 … Still on 4.1 at the moment.
I second Option 1. It makes more sense as I use my Dropbox for other stuff as well.
Not that I’d care if it could access other stuff, but the clear separation from other stuff is good for compartmentalizing and whatnot.
I do have one question: I know mygame.js is optional now, and it’s obviously different in nature to the .txt scenes, but do you plan on integrating anything that will support it or something similar, or are do you prefer to advocate using startup.txt and *create? For testing purposes, I think it’d be easier to quicker to make a list of variables and values in a mygame-esque list somewhere then to *create/*temp however many times. NBD if that’s the case, mygame.js is just a personal preference of mine.
@Caddmuss
Thank you for your input, I think I’ll be going for option 1 then.
Someone was asking about the presence of a mygame.js-esque way of defining variables.
Though it probably won’t be in the standard format. What’s the desired benefit, just the lack of need for writing *create all the time?
@CJW I would just like to (finally) say a very, very big thank you for this terrific implementation of a truly brilliant idea. I’ve used it solidly most days for the past couple of weeks without any problems at all, and I would highly recommend it to both newcomers and experienced game devs alike.
@Caddmuss Having only recently returned to the CS scene, I was also a little apprehensive about the changeover from mygame.js, but honestly, it took only minutes to switch to using startup.txt (and Vendetta has over 500 variables) and thereafter there’s no real difference. If anything, I would say that startup is even easier to use / edit accordingly. It would IMO be a waste of @CJW’s time to build support for the (outdated) mygame.js into the IDE, especially when there are so many other possible improvements far more deserving of his time / more beneficial to all devs.
BAH. I must’ve hit Save Draft and not Post Comment.
@CJW, there was no super, major benefit - but like the differences between the DropBox integration, to me the .js is an easy way to organize between the global, behind-the-scenes stuff and actual plot altering content. BUT, like I said, mygame.js is now an optional file, a personal preference and it really was more question than request.
@Vendetta - WELCOME BACK! I felt a bit of sadness as I watched Vendetta sink farther and farther back until I came to believe that it had followed many other WIPs into the grave. I’m already fairly adjusted to using startup.txt and the compounded *create/*set commands, and had even toyed with something far-and-away, vaguely similar before the update even happened, but I found myself liking mygame.js more for variables because it was a separate, organizable file, as well as writing things like have_keys: false being more habitual and familiar than writing *create have_keys false. Of course, it would be useless for CJW to code if he was trying to steer authors into using the startup.txt and if he or any others have any actually useful improvements they might suggest aloud.
I do see what you mean where mygame.js is concerned as Vendetta’s startup.txt contains just the scene list and global variables, nothing else (it doesn’t even need a *finish, for instance), so I guess I’m using it in exactly the same way as I used to use mygame.js… minus the extra care needed for the different format.
Moreover, I do feel that the changeover is a significant improvement for newcomers to CS who are also non-programmers (in truth, I struggled to grasp mygame.js when I first started!) and for that reason alone I do feel it’s high time that it finally goes the way of the dodo.
I hope it never goes away, while they have made is far simpler for a new user to work in. I learned with mygame.js and still use it as I tend to like to keep it there for tracking, plus it make the startup page feel so cluttered to me. Silly I know, but I am comfortable working this way. Plus it is simple for me to convert it over to a *create list for quick dump into the IDE tool. So best of both worlds for me.
@Vendetta
I’m really, really glad you like it! Thank you.
Some good arguments there.
Now…
mygame.js … It’s a tough one for me.
I write Javascript code a lot, so using mygame.js for me is not in the slightest bit alien or confusing, it’s quite comfortable really and - thus far - it’s what I’ve been using for my global variable declarations.
However, having said that. I really can’t think of any benefits to using it for choicescript games, not now you can set values on the same line as the declaration, that was the biggest mygame.js advantage.
There are plenty of cons for noobs though, the CS syntax is a lot more intuitive, and at the end of the day I think that it’s best for the cs community and language as a whole if we try to convene to some loose standards with coding.
So for that reason I’m tempted to push the use of startup.txt.
As Vendetta points out, you can actually (and probably should) use startup.txt for declaring variables and the scene list and nothing else - then it becomes exactly as you both describe, a separate file for background stuff that keeps your story scenes less cluttered.
So for the time being at least, I think I’m leaning towards prioritizing other improvements. Thank you for your input guys!
Guys, I’ve been thinking about the dropbox integration proposal, and the more I think about it the more I feel we may actually be limiting the longer term potential if the IDE does indeed head down the “Option 1” route and restricts its access to just a single folder (and sub-folders) under e.g. Dropbox–>Apps–>CSIDE.
Certainly this could / should be the default folder it uses, as that would reduce any confusion and you need never use the IDE to access any other folders if you choose not / don’t need to do so.
Moreover, the IDE should certainly be limited to just accessing .txt files by default, since nothing else is (now) strictly needed for ChoiceScript game development.
However, by denying the IDE access to all of the user’s .txt files anywhere on dropbox, we would also essentially be limiting future potential in at least two important ways I can think of:
We publish our WIPs to a shared public folder, but unless the IDE has direct access to that folder (which “Option #1” would seem to deny), it cannot allow us to make ‘quick fixes’ to a live version file, nor indeed to publish all the latest version files over the current live version. We would instead still have to do this sort of thing outside of the IDE itself, when it would make far more sense to allow this within the IDE, since that’s where we’re actually working on the files, developing, testing & tweaking. Ideally, we should also be able to simply publish those fixes / updates with just a click or two.
Perhaps of less importance to most, “Option 1” would also deny access to privately-shared folders (i.e. those we share with, say, just one or two other people). However, granting access to those folders would actually enable the IDE to one day directly support collaborative projects between writers and coders, or even small teams.
Have you considered adding in the ability to actually see how a choice changes a stat (i.e strength +5 popping up when you click a choice) or something to let the player/tester know whether they pass/fail a stat check?
@Vendetta
After the discovery that Option #1 will prevent you from editing files in shared folders I’m definitely swinging towards Option #2.
I can write my own code to create and prioritise a default directory for the app, so in terms of organisation we’re losing nothing. Literally the only downside is people will have to trust the app with their base Dropbox directory, or at least all .txt files in it.
@Nocturnal_Stillness
I’d considered implementing a console that would list any choicescript operations.
It’d be a panel, box or popup page that would list any actions (like the setting or creating of variables). Either that or an edit to the var tracker so it highlights/flashes and moves to the top any variables that are changed.
However I don’t think it’s something I could code *around* choicescript, I think I’d have to actually write my own code for watching and logging the events, if that is the case it’ could take a good while to implement. I’ll have to have a poke around.
It’s a very good idea, and I’ll definitely look into it after I’ve finished up the Dropbox integration (which in itself is a mammoth of a task!).
I know nothing of coding, but is it possible for the preview window to be live? Like as soon as you complete a line of code that makes sense in CS, the preview automatically updates with the change? Or would that be something that would require a lot of work?
@fantom
More than anything it’d just be extra processing overhead, you’d need to be constantly refreshing the screen (or on key press in the editor).
It would be difficult as well though, for as soon as you start changing the code the line numbers of all your commands are going to change, so it’s going to be nigh on impossible to make it ‘refresh’ to the exact same point.
What you can already do though is make changes before you load a scene.
For e.g. any changes to choicescript_stats will take effect next time you enter the stats screen (or *goto_scene with any other), even if you’ve not pressed run, if that’s of any use to you?
I have to thank you ever so much CJW. I’ve been lurking around, reading up on the coding in the wiki and on the main website but I’m the kind of person who needs to see what’s happening (other than letters appearing on the screen) to actually get how it works. I have no idea how many CS projects I’ve started and just scrapped because I didn’t manage to get my head around the commands. With this, I finally could. Huzzah!
