So the only reason I'm posting today is because Hao and I had a pretty successful night of coding last night (at Starbucks no less, looking like a couple of hipsters).
Hao got our mouse scroll feature working. You know the feature where you hover over the edge of the screen and the viewport moves in that direction. I'm actually kinda of ashamed at how excited I got to have a ball move around a screen but I guess its all about the little victories.
I was less successful as Hao but still made great headway on the UI. I got the CSS/HTML heads up display mocked up and have the WebGL rendering screen in place but for some reason it's not displaying and doesn't show when I use Inspector. I believe I'm having trouble with scope. I think I have my canvas element buried to deep into my DIV structure (for UI layout) and need to have it declared outside my DIV tree and then attach it to the DIV after initiation.
For those of you who don't know, HTML5 came with this AWESOME object you can instantiate and attach to the DOM which has WebGL GPU acceleration built in (on most browsers; Chrome, Firefox, etc...). Really fun stuff. Playing with the Canvas element has been a total blast. The API support for it really is amazing. It has it's own pixel-based drawing features that are great for UI and just basic bells and whistles but where the real fun is in the third party APIs.
HTML5 libraries are incredibly daunting to Google through because of the vast array of subjects underneath the "web dev" banner. But if you can keep your BS buffer from overloading you can find some really spectacular libraries. Everything from simple 2D vector art APIs all the way up to complete 3D gaming engines with links to physics engines and everything else a lazy game designer could imagine up.
Anyway, that's enough off-ish topic ranting for this morning.
Thanks for reading.
-Clay Francisco
Thursday, January 30, 2014
Tuesday, January 28, 2014
Scrounge World Post #5
Alright folks, time for a foray into the server side of our app.
So Zach has been the one creating the server side framework (in Haskell for those of you just skimming) with only myself as a sounding board for rubber ducking. And while I love game logic and am great with the overall structuring, he has create the framework almost completely by himself.
That being said the framework is missing the game logic itself, so it really is just the empty shell. This might sound kind of fishy but it actually aligns perfectly with our original project goal(s). Our original idea was to create an RTS engine not dissimilar to the Spring RTS project. Where the Spring RTS project is not a client/server model and has tons of game logic that it comes with (because you host the engine) our project is designed to be a shell that you create your own mods for and configure with your own code.
aaaaaand Zach just stole my keyboard.
Hey this is Zach. I'm working on the server portion of our client/server model RTS engine. The server handles game logic, streams graphical information to clients, and handles client commands. I've completed 90% of the networking code for receiving and transmitting data in our own binary format. I've been working heavily on pathfinding and started on a line of sight algorithm.
The plan for this engine is to be highly modifiable by anyone who wants to make an RTS game. I've designed it so "modders" can upload (nearly) arbitrary Haskell code and run it on the server. We will be implementing our own "mod" just like anybody else would to showcase the engine.
aaaaaaand I'm back.
As Zach mentioned we are going to be using our own binary format for sending game-state data. This is because we are sending "tile/map" data to the clients in a piecemeal fashion. I.e. the client only receives data for the tiles and units that that player has discovered. This will make hacking the game much harder because no client has access to information they shouldn't for their given game-state. The only information players have on the client side is graphics. Everything the players see is just a dummy/slave to the streaming info from the server. Additionally, because the players can only send requests to the server to change game-state, we will get to decide what a valid request looks like from the client.
When we create our "version" of our engine we will be using the "mod" interface just like anybody else. This is partly because we think it's cool and partly because we want to make sure we have an intuitive system for modding in place.
Modders will be able to define pretty much whatever they want. So far the only functionality a "unit" or "entity" comes with is x,y,z coordinates. Modders will need to define from whether or not to even have resources, buildings, avatars, etc... We do have the frame work for containing all of these ADTs but there definition and in most cases even creation is up to the Modder.
Again, thanks for reading,
-Clay Francisco (and today Zach Kamerling)
So Zach has been the one creating the server side framework (in Haskell for those of you just skimming) with only myself as a sounding board for rubber ducking. And while I love game logic and am great with the overall structuring, he has create the framework almost completely by himself.
That being said the framework is missing the game logic itself, so it really is just the empty shell. This might sound kind of fishy but it actually aligns perfectly with our original project goal(s). Our original idea was to create an RTS engine not dissimilar to the Spring RTS project. Where the Spring RTS project is not a client/server model and has tons of game logic that it comes with (because you host the engine) our project is designed to be a shell that you create your own mods for and configure with your own code.
aaaaaand Zach just stole my keyboard.
Hey this is Zach. I'm working on the server portion of our client/server model RTS engine. The server handles game logic, streams graphical information to clients, and handles client commands. I've completed 90% of the networking code for receiving and transmitting data in our own binary format. I've been working heavily on pathfinding and started on a line of sight algorithm.
The plan for this engine is to be highly modifiable by anyone who wants to make an RTS game. I've designed it so "modders" can upload (nearly) arbitrary Haskell code and run it on the server. We will be implementing our own "mod" just like anybody else would to showcase the engine.
aaaaaaand I'm back.
As Zach mentioned we are going to be using our own binary format for sending game-state data. This is because we are sending "tile/map" data to the clients in a piecemeal fashion. I.e. the client only receives data for the tiles and units that that player has discovered. This will make hacking the game much harder because no client has access to information they shouldn't for their given game-state. The only information players have on the client side is graphics. Everything the players see is just a dummy/slave to the streaming info from the server. Additionally, because the players can only send requests to the server to change game-state, we will get to decide what a valid request looks like from the client.
When we create our "version" of our engine we will be using the "mod" interface just like anybody else. This is partly because we think it's cool and partly because we want to make sure we have an intuitive system for modding in place.
Modders will be able to define pretty much whatever they want. So far the only functionality a "unit" or "entity" comes with is x,y,z coordinates. Modders will need to define from whether or not to even have resources, buildings, avatars, etc... We do have the frame work for containing all of these ADTs but there definition and in most cases even creation is up to the Modder.
Again, thanks for reading,
-Clay Francisco (and today Zach Kamerling)
Monday, January 27, 2014
Graphics.... oh the pain. Post #4
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
...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
Tuesday, January 7, 2014
Defining our SAP model Post #3
Currently we are doing our best to scale-back game features and functionality in order to solidify a SAP (simple as possible) model for our minimal working product (this is simply for scholastic requirements, we will not be stopping at an incomplete game just because we've graduated).
The necessary graphic simplification has caused me (Clay, well... Zach too of course) a little headache about what Client-side implementation we want to use for graphics. JMonkey Engine 3 has proved to be too cumbersome for our needs, and additionally would require the user to download our client-side app.
Our main requirement for UX (user experience) is the option to go mobile (really just for tablets because of screen real estate requirements) with our game. i.e. having touch/swipe controls and a slick UI (user interface) for an RTS style game. Ideally making the mobile experience of our game as rich and responsive as the PC version. Something our group believes has yet to be done successfully for the RTS genre.
This requirement has steered us towards Javascript (WebGL/HTML5) for our game client. Javascript has a huge support community and some great books on HTML5 game development as well as a "native" WebGL API called ThreeJS (which is also amazingly documented). We had initially ignored Javascript simply due to our misunderstanding of it's graphics processing power.
Examples like this (www.chromeexperiments.com/detail/100000-stars) have caused us to believe that WebGL/HTML5 will have all the GPU power we should need especially if we keep our graphics clean and use HTML5/CSS best-practice for rendering optimizations.
Zach has completed the Host "game shell"* and much of the server functionality for game initiation (logging on/off, dropped players, etc...).
Recap:
We are moving forward with a Javascript (WebGL) implementation for the client. Focusing on UX for our SAP leaving us the job of re-factoring graphics implementations after gameplay/UX is fully functional.
*By "game shell", I mean the data structures/file system of the game minus any of the actual game logic for Unit behaviors.
The necessary graphic simplification has caused me (Clay, well... Zach too of course) a little headache about what Client-side implementation we want to use for graphics. JMonkey Engine 3 has proved to be too cumbersome for our needs, and additionally would require the user to download our client-side app.
Our main requirement for UX (user experience) is the option to go mobile (really just for tablets because of screen real estate requirements) with our game. i.e. having touch/swipe controls and a slick UI (user interface) for an RTS style game. Ideally making the mobile experience of our game as rich and responsive as the PC version. Something our group believes has yet to be done successfully for the RTS genre.
This requirement has steered us towards Javascript (WebGL/HTML5) for our game client. Javascript has a huge support community and some great books on HTML5 game development as well as a "native" WebGL API called ThreeJS (which is also amazingly documented). We had initially ignored Javascript simply due to our misunderstanding of it's graphics processing power.
Examples like this (www.chromeexperiments.com/detail/100000-stars) have caused us to believe that WebGL/HTML5 will have all the GPU power we should need especially if we keep our graphics clean and use HTML5/CSS best-practice for rendering optimizations.
Zach has completed the Host "game shell"* and much of the server functionality for game initiation (logging on/off, dropped players, etc...).
Recap:
We are moving forward with a Javascript (WebGL) implementation for the client. Focusing on UX for our SAP leaving us the job of re-factoring graphics implementations after gameplay/UX is fully functional.
*By "game shell", I mean the data structures/file system of the game minus any of the actual game logic for Unit behaviors.
Subscribe to:
Posts (Atom)