Wanted to share my progress thus far

I suspect by the middle of next week I’ll have more of the shaders working, and gameplay integrated into the codebase:

2 Likes

Two more decent pictures. . .




1 Like

Looking great so far. Is this an action game or more of a space trading game?

Thanks Dave.

It’s actually a technical demo that I will be sharing with a few clubs in the area. Additionally, after some cleanup that it can be made available to the PlayCanvas community at large.

The original game came from XNA days, and had a few missiles and orbs (IIRC). The plan is to provide for three levels with the same type of gameplay. However, I’d also like to add a Crazy Mode where the player battles an assortment of giants carrying various style clubs (and not your nine iron :smile:). The idea is to stay alive as long as possible, keeping a history of best times. There’s no beating the level, many giants would continue to spawn until the player was defeated. You could shoot the giants and take them out but eventually they’ll get you. Being an enclosed level should bring a sense of manic, and with any luck some laughter being bounced off the walls, etc.

Would by chance have any AI written in JavaScript that you could contribute? If not, most likely I’ll be able to find someone at one of the clubs to help out.

So it’s not AI as such, one library I often use when implementing enemy AI is pathfinding.js. I use it in Zombie Pac-Man to make the NPCs run around the level. I also used it in Last Line of Defense to help the tanks navigate from one side of the map to the other.

Thanks Will.

Looks easy enough to use, and the online demo is helpful. I’ll give it a try and provide feedback shortly (hopefully).

A couple more screenshots from the ship selection screen. Next will be the level selection screen:


<br>

1 Like

Looks great! Looking forward to discussions with you add me to hangouts. I’m yottzumm at g-m-a-i-l.c-o-m (note the address is obfuscated, but you get the idea.

Hopefully you got the email that I sent. I’ll be away from my desk for a while but will be back in about an hour. . . Assuming you get my email, then please reply there.

I’ve added the code to GitHub. Now comes the hundred dollar question: how’s my setup going to look locally?

I use VS2015, along with a repository in GitHub. When the PlayCanvas project is downloaded:

1.) I move it from the download folder to a PublishedGames folder.
2.) Extract it in place so that it retains the project name: PublishedGames\XNASpaceRace.
3.) Then I copy the extracted folder to my DevSite folder, which contains a Web.config file that allows the project to run locally with IIS.
4.) There’s also an XNASpaceRace batch file that is used to run either Chrome, FireFox, or IE. REM is the keyword within that file. And I’ve contemplated replacing it with a more elegant and user friendly WScript file with a UI.
5.) The batch file launches both Python2.7, and the browser.

All of this looks good with one (or more) exception: there’s no direct link between the files on GitHub to the ones in the locally running folder. That’s the hundred dollar question. How should these be linked?

As it stands at this very moment:

6.) I would use VS2015 to edit and debug the JavaScript files in the local web server folder.
7.) Then copy the changed files to my GitHub repository folder.
8.) Commit the changes locally.
9.) Then push the changes.
10.) Go to the PlayCanvas site, and Sync the source files.

Any chance I can get this down to one or two steps?

Well you can consider keeping deployment separate from testing. What I would probably do is use git branches. When you have a branch that is ready for testing then use git to clone or pull to your test folder. If you want to keep something separate from other branches, don’t merge it into that branch, or keep a local copy backup and don’t check it in with .gitignore entry. Once you have a master branch ready for deployment to playcanvas, then pull that to the playcanvas site. I don’t know all the ins and outs of git yet, but it’s likely you can do it with it. If you’re creating .cab’s or some such that’s another step.

In other words, instead of doing a bunch of copies and moves, use git. Also use continuous integration to keep your integration environment up and testing when you check files into git. The CI will check your files out of git automatically and deploy your app to integration testing.

Maybe branching is a separate (but needed) issue. And probably adds another layer of complexity when it comes to PlayCanvas. Considering that we have a PlayCanvas project, that may have numerous scene files (or Packs), that are explicitly tied to a specific repository, means that the PlayCanvas projects may need to be duplicated as well. We would have to duplicate the project (not just one scene since the repo is at the project level), then point to the correct repository. That seems easy enough. However, making needed changes in the PlayCanvas scenes (Packs) and getting them back to the “master” is where the challenge may come in.

I do use Git. It’s just a matter of getting the Git folder, and what’s been downloaded from the PlayCanvas site to be one and the same (minus changes of course).

Given that PlayCanvas refers back to the Git repo, then I should be able to “assume” that the files are indeed exact, that is, syncing on PlayCanvas has occurred. I’m going to change my local repo directory to my DevSite\XNASpaceRace folder and see what happens. Hopefully file timestamps don’t influence Git.

EDIT (2015.02.25 15:06):
Visual Studio doesn’t like anything in the folder. So I need to download the repo first, then merge the downloaded copy from PlayCanvas into the same folder. Of course, I need to make sure that existing JavaScript files are not overwritten.

This brings a set of new problems too though. Fewer steps certainly but at a level of discomfort not knowing if something is being lost or not.

EDIT (2015.02.25 15:17)
I cloned the repo locally after deleting the previous folder. Then I downloaded and extracted the files, which gave me the option of overwriting 23 files, or ignoring them. I chose to overwrite so that I can see VS/Git behavior. Given that the files were identical, VS doesn’t show any changes needed. I also set the gitignore the PlayCanvas scene files (HTML, JSON, etc.)

Now I’m going to perform a simple update test.

EDIT (2015.02.25 15:24)
Okay, I’m with the modern times now. The only uncertainty I have now (outside version controlled assets) is during extraction. But as you noted, I could check my changes into a branch before the pull from PlayCanvas to make sure nothing gets lost.

Hey,

Just checking that you know about “local server” workflow? If you launch from the Designer using the Launch Local option, all code is served from localhost:51000.

So you can run a local server and edit your code without having to do the github round trip.

Of course this only works if you are working alone, if you need someone else to have access to the code you will have to push and sync.

We will be adding webhook support soon so that we can pull from Github as soon as you commit. I’d also like to add an option to specify the branch.

Thank you Dave. Yes, I tried the Local Server previously and couldn’t get it to work.

I tried again just now and received an “uncaught exception error loading script 'http://localhost:51000/BootManager.js”. It turns out that starting Python from within the directory where the source files are works.

It actually makes sense when I look back at my batch file that launched Python and then one of the browsers pointing to the subdirectory:

start C:\Python27\python.exe -m SimpleHTTPServer 51000
"C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" “http://localhost:51000/XNASpaceRace

Again, for anyone else that may stumble onto this problem, start Python from the folder where the source files are located.

Now I am able to delete everything else from my folder, just leaving the source files, and work on both the assets and code at the same time. An added benefit of this is that I can compare the previous functionality (launch from server) to the current development (launch local server) simultaneously. That is nice.

Two things come to mind with this (outside of Git synchronization):

  1. Instead of having to select launch locally each time, could it be a drop-down menu checkbox item selecting which way we want to launch? That way we can just press the Launch button. Please keep the ability to launch both though, just allow the default launch behavior to be modified on the fly.

  2. Have an un-minified version of the engine to debug with. That way we can make corrections and submit the changes too.

Yep, the code is loaded from the root of the webserver so you need to make sure the URLs match up.

Your questions: We actually used to have that project setting for this and we changed it to the current system as it made more sense at the time. But remembering your last option might be useful. We’re revamping the Editor in a few weeks and this will get looked at again, so feedback here is great.

  1. The engine version you run with from the Designer is un-minified, but it is concatenated into one file. It might be useful to include sourcemaps so that you can view the separate files, I’m not sure how useful that will be to most people.

For the source files, I’d make it an option if possible. Personally, I would like the opportunity to debug from end to end and make fixes, or enhancements as I encounter them. I’d like to be able to make a change and commit it back without having to jump through hoops in order to do so.

I’m getting an error when loading the level from the Menu code. When the level is loaded separately it works fine but not so well from the menu. Would be able to make any recommendations/suggestions?

Hmm, this is probably an issue with the way the engine loads assets at the moment. Assets for new packs are not loaded. I think I’ll need to look into this on the engine/server side.

Bear with me for a bit, I’m travelling from tomorrow for a week so there might be a delay getting this up and working.

1 Like