One of the "features" of ChromeBook is that an organization can
"manage" it, that is block all kinds of activity deemed harmful (or mostly
everything not approved, whether it is harmful or not), which typically
includes installing apps like BlueJ. I looked at numerous on-line development
environments that you can operate from a browser, and most of them were
too limited to run our GameEngine. REPLit actually works, but it's rather
flakey (you might soon or already know my high opinion of Unix, see "Unix
vs Mac" and others) and not nearly as easy
to use as BlueJ, but good enough.
The good* news is you don't need to install anything. You do need access to a couple domains, which if your school has blocked, that needs to be fixed at your school's IT department. Just click on this link:
https://repl.co/If your school blocks it, there will probably be some message saying so. Otherwise, if it puts up a robot icon, back out and click this link (both must be unblocked) to proceed:
https://replit.com/@NWAPW/#StartHerewhich prompts you to create an account and then you choose to "Fork" a cloned version of my StartHere folder to work with. It should open you in the workspace for the "StartHere" project. This is a copy of my original, so you can make changes and they are all yours. If you already have a Replit account, you can email your account name to <submit@NWAPW.org> or paste it into a private chat to a Mentor on Zoom, and you will be invited to join our "team".
Where my main text mentions "yellow rectangles" you get to look for little blue coffee cups (Java files). Next to the menu there is a panel with the source code of whatever line in the menu is highlighted. Next to that is a black Linux Console panel, where your text input and output appear. The gear (Settings) menu brings up an option to switch from "side-by-side" to "stacked" which I found helpful (then reselect the top menu "Files" to get back to your source code).
Where my main text mentions "save" or "compile," you do nothing at all, it happens automatically. If you have compile errors, they will be reported in the black Console panel. You need to look for the first (of two) word "error" and just to the left is a file name and line number; open that file and scroll to that line number to fix it.
Instead of right-clicking the yellow rectangle (as in the text) you click the green Run button above the panel area. It's easier than finding that "main()" line buried somewhere in a possibly very tall popup menu, but every time you want to change which program runs, you need to change the source code. But that doesn't happen yet. You will be changing the "Replace this line" with your own code, as described in the main text, then clicking the green Run button.
Later, when you have other classes you want to run, come back here,
and I'll tell you how to work around the unixy limitations in Replit.
So create a new class: Click the tiny "+" sheet of paper icon on the Files line and type in a new class name -- it must start with a capital letter and end with ".java" and also be different from the other file names. You can copy the Main.java file code and paste it into your new class, then change the class name on the first line to match the file name. Leave the method name "main" and change the code to be what you want.
Then go back to the original Main.java file and replace everything that used to be the "Replace this line" with the following single line:
NewClassName.main();where "NewClassName" is whatever name you gave your new class, or if the new class main still has the "String[] args" inside its parentheses, use this version:
NewClassName.main(args);because the parameters must match. Then the green Run button will still run your program.
https://replit.com/@NWAPW/#GameEngineand clicking the Fork button will install another REPL in your account, and you proceed as above, except...
You should open the Main.java file and verify (or change it if not) the one line in that main program reads:
JavaGame.main();Later, after you Build your game program, you will come back here and change it to
GameBd.main(args);or whatever name you gave your game. Each time you switch off between the GameMaker and your own Java game code, you need to change this line to match.
When you are working in the GameEngine, you still need the Console window
for compile errors, but you can squeeze it down to a narrow strip at the
edge of the window by dragging the little bar in the middle of the dividing
line. This leaves more space for the GameMaker window. You can also squeeze
the source code window off the other side if you need more space. I pushed
it all the way off and couldn't make it come back, but the three horizontal
lines in the top left corner brings back the top-level menu, and you can
reselect its Repl in the "My repls" panel, and it rebuilds the default
panel arrangement. Or at least it did for me.
To get into the debugger you must select the Debugger menu (the unobvious open triangle icon, hilighted in blue above) and set one or more breakpoints somewhere in your program. The hint tells you to "click on the left side of any line number," but it only takes when you click out at the edge of the panel, and then only if your line number is three digits or less -- In my test, I somehow managed to get it to set a breakpoint once on a 4-digit line number (1860 above) but the blue dot on the line number is off the panel (but all breakpoints are listed under the "Breakpoints" heading in the second column, click on one of them to show that line of code). Anyway, to use the debugger after setting a breakpoint, click the solid blue triangle on the Debugger line (the green Run button ignores the breakpoints).
The other three icon buttons to the right of the blue triangle give you three of the four usual and necessary functions you need for debugging. The single ">" button is usually called "Step Into" in rational debuggers: It steps one line in your source program, unless it's a subroutine call, and then it steps into the subroutine. I think the bent arrow is usually called "Step Over" because it runs subroutine calls full speed, then stops on the next line. The other ">>" icon is usually called "Resume" and begins running at full speed until it hits the next breakpoint. Missing is the usual "Step Out" which runs at full speed until the current subroutine exits, then it stops.
When it hits the breakpoint, the local variables and the runtime call stack will be listed below the list of breakpoints. It's somewhat flakier than BlueJ -- what can I say? It's unix -- and wouldn't always stop for me. I had to run it several times before I was convinced it actually worked, because there is no separate indication that it stopped on a particular line, other than the line is lightly hilighted about the same as when you are editing it, but you know you are in the debugger because the call stack shows at least the main program. Otherwise it works about like the BlueJ debugger in the main text. On the other hand, BlueJ would stop but not let me look at the variables. That's why my programs are filled with printline statements under the control of a boolean. If you get there and it won't stop, get help from another student or the instructor. That's what we're here for.
Most of your programming errors will be caught by the compiler -- which is as it should be -- but the Java compiler error messages are often obscure and hard to figure out. It gets increasingly confused after the first error, so always fix the first error it finds, then look again. Mikayla Maki prepared a tutorial "What To Do About the Red Squiggles?" to help you understand how to deal with these.
Tom Pittman
Rev. 2022 May 5
* The Bad News is that it's Linux (Unix, see "Unix vs Mac" or my footnote here), so it's hard to figure out when Things Go Wrong. Their lawyers are even worse, so you are forced to agree to impossible "Terms" (which are therefore probably unenforceable, so you're safe, but it's a lie, and I do not recommend lying ever).