So I know I said I wanted to talk about the "tech tree" but I think that can wait in lieu of discussing the more technical aspects of the design process (sorry, I'll get there eventually).
...and so...
While I may not have been updating these posts on our progress as regularly as I should, we have definitely made strides in the right direction with Scrounge World this past month.
Which brings me to this post. A digression from the chronological order of things to show how and why we arrived at Javascript for our client side code.
Because I like things in order, we'll start at the beginning. The first language both Zach and myself learned was Java. With Hao's strong background in the entire C family of languages it seemed like a natural choice to try and use Java for the client side portion of our application.
...enter JMonkey.
Note: We had already decided on using a MVC style framework inspired by a Haskell/C++ design where the user would download the client to their desktop (in order to keep graphics and other expensive assets from hogging bandwidth) and receive the entire game-state from the host machine.
After a few weeks of researching APIs like Java-OpenGL, JavaFX and LWJGL (lightweight java game library) I settled on the Java Monkey 3 Engine. The frustration that followed was a blurred mess of missing normal maps, bitmaps that looked like melted wax, API dependency insanity, and a whole slew of minor details that just seemed to create more problems than they solved.
I am in no way bad mouthing all the amazing work that went into JME3. The tutorials and example code is great to read through and really does a god job of laying out the way things are supposed to work. However, after another few weeks of tinkering around with the asset loaders and whatnot it became clear that JME3 was just too bloated for our needs and the scope of this project.
...enter JavaScript... well... really webGL...
(we wanted 3D graphics because I'm comfortable with Blender)
After one of Zach and my brainstorming sessions about how to lighten the game we came to the realization that if we had a light enough client we could simply host the whole shebang. So off I went into the search bar to find Javascript APIs for game design. What a bad idea that was. There are more Javascript APIs out there than actual JS games themselves. Which is kind of cool if you don't have a deadline to meet.
More time passes and I find BabylonJS. Soooooo cool. I'll say it again. Soooooooo cool. But alas, webGL was just too new and unstable a technology for an exploratory project with a scholastic component. Dear readers if you don't believe me about web technology being unstable just look up "requestAnimationFrame" and get back to me after a few Advil. If I had (when I have?) the time I would spend it on this engine because we all know the future of the web is full 3D. Zach and I would love to produce a game right on the edge of possibility but our plates are just too full to accommodate that kind of creative ambition at this time.
This is when we realized we have been spending to much time on graphics and just need to get a proof of concept up and running in order to work on meat of the project (the character AI logic).
So I got to work on learning a vector graphic library that will enable us to show all of our features in a lightweight, math-centric fashion. In the interest of finishing sometime before tonight I'll just say that either; I am not as proficient a coder as is needed to squeeze the frame rate out of the animations or perhaps the vector library I was using is not performant enough (to support a 500 unit stress test) but no matter what the reason the outcome is the same.
Sprites.... NOOOOOOOO!!!!!!!
Oh how far our lofty and grandiose ambitions have fallen in so short a time. But that's software design. Could we really expect things to be any different? Besides, it looks like I've found a great book on software design and Javascript: Pro HTML5 Games by Adita Ravi Shankar.
The next post or so should have links to youtube to show our progress with graphics.
Thanks for reading,
-Clay Francisco
No comments:
Post a Comment