New phone OS and group help Post #6

As I stated in the main thread, the Parts & Portals group and myself will be joining forces to help each other get over our creative blocks this next week.  Jaron has quite a lot of HTML/CSS experience and all of my research into cross-platform game engines has actually made me fairly proficient at parsing engine code.  There is also the added bonus that their group is using Java and I love coding in Java.  It felt great to work with Daniel and just dive into trouble shooting on a new (to me) project.  I actually didn't realize how much I missed coding in Java until we started working on their game engine yesterday.  It really is a fun language to work in.

So back to my phone and feasibility of playing our RTS on it.  It doesn't look good.

I got everything working just fine after upgrading my OS to Jellybean 4.3.  This enabled WebGL and a few other cool developer features on my phone.  While the GPU isn't quite buff enough to handle even simple WebGL it was still really cool to play with the models from this site:

http://www.ibiblio.org/e-notes/webgl/webgl.htm

That being said.  I'm not entirely sure it's my GPU that can't handle it and not my internet connection, so more testing is needed to be sure.  That testing will just have to wait though.  For now, it's enough to know that it will take optimization of some sort to get 3D graphics to work on a phone so we will put that off to the side.  We didn't have phone design in mind when we started the project but I do think it's academically important to understand what it would take to have a WebGL based in-browser smart phone game.

I wish I could talk more articulately about the CSS/mouse event errors I'm getting in my HUD but I really don't know why the functionality is spastic.  There are a few factors that are involved;  the z-index and the functions controlling them, deprecated "prevent default action" code in the tutorial and the 2D canvas element "in front" of the HUD.

It's one of those problems where everything looks just like the examples in the book so I think the book must have a tiny typo.  I have run across several syntax errors in this book when the code spans pages so I at least know where to start hunting.  Overall the book is quite good for programmers familiar with HTML and CSS already.  It has been a good read so far and the first game example "Angry Fruit" was easy to follow.

Pro HTML5 Games: By Aditya Ravi Shankar
http://www.apress.com/9781430247104

Oh, and my terrain map isn't displaying either -even though the web console is showing that the asset was loaded correctly.  This is regular asset loader troubles though and shouldn't be a problem once I track down the missing/broken loader code.

So with the roadblocks over the past couple weeks and losing our 3rd and 4th team members part-way through last quarter it will be necessary for me to update our timeline to fit our reduced crew size.  I definitely planned this project out for a 4 person team and have had to spend far too much of my development time scaling back our model to fit our dwindling manpower.

I'm off to update our timeline now.

Thanks for reading,
-Clay

Recap for Spring: Elm, two clients, and my damn phone

As I mentioned in the main thread, we have realized the end of the school year is closing in faster than anticipated and we need to get this project in a playable format.

What that means.  It means Zach is going to spend the weekend whipping out a crude, top-down, touch reactive client in Elm (a new functional reactive programming language,  http://elm-lang.org/).  It also means we spent the better part of last night on Skype trying to get my phone to run his Elm code from our ftp server.  No luck.

After a few sessions of trial and error we figured out that I could download an ftp client (I used AndFTP by Lysesoft), download his source as a ZIP and unpack it (I used AndroZip by AVG Labs) then run it with my phone's native HTML viewer. BTW my phone is a Galaxy S2.

Everything seemed to work great until the HTML viewer kept only displaying a blank screen.  It did give me the ability to scroll the blank nothingness though so that gave us hope we could debug it and move forward.  So I plugged my phone into my computer and tried to use Chrome's remote debugging features but my computer won't recognize my phone (even for downloading photos) so we were once again stopped by web tech.  ugh...

SIDE NOTE:  a few days ago I even had to turn my WebGL capability ON for Chrome on Ubuntu.  That took me a minute to figure out.

So, the next step is to download the Android SDK  (done) and try and use ADB, the official Android debugger to get this working.  My hope is that we will be able to use the SDKs legacy drivers to get my computer to recognize my phone.  If that doesn't work, we'll have to ditch phone compatibility entirely for now.

If all of this comes together we will be able to have players download a couple simple apps (FTP client and Unzip), download our game, and play it.  All without going through the normal distribution channels.  We think it would be really fun to get a game out there under the radar just to see what kind of community would get involved.

Once we get the debugger working through my phone we can start troubleshooting why the "map" didn't display when we viewed the html page.  Until then we are at a standstill for the phone and will just continue with the regular desktop browser version as scheduled.


But on the progress side, Zach should have an Elm client up and running by mid-week-ish and so we'll be able to start prototyping game mechanics pretty soon.  This will pull my time away from the JS client a bit but we'd still really like to not think of the JS side as scrapped, I just need to build the next version from the ground up.  Really not a big deal, it's just my first implementation was very much a "get it done version" and is consequently gruesome to debug.  It doesn't follow proper best practice encapsulation guidelines, even for JS.  Pretty bad I know.  Things are being initialized all over the damn place.  I gotta wrangle all that in and  classify everything so you can chase down the JS console errors better.

So, that's where our spring quarter is starting.

Wish luck and thanks for reading,
Clay Francisco