Pages

Showing posts with label Game Tech. Show all posts
Showing posts with label Game Tech. Show all posts

Thursday, November 29, 2012

EjectaGL : Quick Update - Basic texture support

Quick Update - Basic texture support has been hacked into EjectaGL.

Here is a super quick (hence the bad lighting, bad finger smudges and bad everything - like all my videos) demo of port of Lesson06 from learningwebgl.com.

To make up for the absence of keyboard the zoom is controlled by tilting the device(which Ejecta nicely supports). Touching the screen toggles between the different filtering options.

I have tried to show the effect of Mipmaps which is the main part of Lesson06 (Open in youtube for bigger size video to actually see the difference)

If at all you want to give it a spin, be warned that I've pretty much stuck to implementing the APIs needed for the lessons for now. I just haven't gotten around to typing all the binding yet. Feel free to jump in and add some of them.

Monday, November 26, 2012

EjectaGL - WebGL on iOS with Ejecta!

Summary: 
I am starting a project EjectaGL which adds WebGL binding to the awesome Ejecta project by Dominic Szablewski. EjectaGL extends the Ejecta framework to provide a WebGL implementation on vanilla JavascriptCore without any of the DOM overhead. EjectaGL provides a way to develop WebGL apps that can be shipped to the iOS app store(Not tested, but very possibly). It is far from being complete - So please contribute if you are interested! 


EjectaGL is distributed in the same MIT license as Ejecta.

Longer story:
I had worked on Voxel Flyer for js13kgames - A WebGL based game in less than 13K compressed Javascript. I wanted to keep developing it but I sort of wished it would work on iOS too. A search for WebGL on iOS usually yields the jailbreak method for enabling WebGL on iOS which is not very useful if you want to ship your WebGL app on the App Store. It feels like Apple might open up WebGL at any time but that never seems to happen. I always wanted to look into adding WebGL binding to AppMobi's directCanvas - but that never happened due to the complexity of the directCanvas code(and not to mention that the open source version has hardly seen the updates of their recent XDK).

Meanwhile I saw that Dominic from Phobos Labs(on whose work directCanvas is actually based upon) released Ejecta, a newer version of his iOS library to provide a barebones fast implementation of Canvas and Audio without all the DOM overhead. This time I felt the code was much more friendlier and  I could actually have a real shot at implementing WebGL on top of Ejecta. 

So couple of days back I started reading my fist tutorial on Objective-C and started hacking Ejecta! The result is EjectaGL. EjectaGL replaces the onscreen 2D canvas with a WebGL enabled canvas. At the current stage it's just a proof of concept and I am discovering and fixing issues as I am porting each lesson from  http://learningwebgl.com/. I tried porting Voxel Flyer to it and discovered that there is something wrong with the way uniforms are being passed in which I'm yet to finish debugging.

So basically it's in a very nacent stage but things are looking mostly doable. I can definitely use some help from people to add more bindings, port more examples and review my code for memory leaks(I'm sure there are few there given my newness to Obejctive-C) and other issues.

Check out the screenshot of Voxel Flyer running in the emulator with buggy lighting turned off at an astounding 9 frames/second. (You can run this demo by downloading the github source, creating an App/ folder and copying the contents of examples/VoxelFlyer to it)





As for some implementation details the one major caveat is the absence of Typed arrays in the current JavascriptCore that Ejecta uses(It might be coming some time later though). I have tried to work around it by implementing a very primitive pseudo typed array in Objective-C. Basically you can instantiate a typed array but that's about it. I found that most WebGL code just create the typed Float32Array, Uint16Array just before binding to the buffer anyway and don' do much with the contents anyway. There could be issues with libraries like glMatrix that use typed arrays for fast matrix calculations. Currently I just replace the typed array with a regular array in my stripped down version of glMatrix. I see a workaround here of implementing glMatrix itself in Objective-C that doesn't have typed array in it's method interface but can use the internal representation of EjectaGL's typed array which can then be passed on to EjectaGL. A similar strategy can be adopted if we want to get libraries like three.js also running on EjectaGL(though that would be a big undertaking of it's own).

There are not lot of WebGL APIs implemented currently but I don't see any other major issues in doing that (other than the typed arrays). Also I am thinking of adding stuff like rendering offline to a 2D Canvas and using that a texture in WebGL (My Voxel Flyer originally had a mini map that was a 2D canvas on top of the WebGL canvas).

So for now I just wanted to quickly mention the project and get the ball rolling so that I can ask for help and also make sure there is no duplication of effort (I am pretty sure 100 different people were also thinking of a similar project).

I think there are lot of applications for this project - It would be nice to get all those nice shader/demos working on the mobile device, possibly even the three.js ones. I also see a possibility of using all the cool WebGL shader effects available on Construct2 to be now fully exportable to the iOS target. 

Drop me a line here or on twitter - @vikerman

Update : EjectaGL is now merged into Ejecta main! You can get it at https://github.com/phoboslab/Ejecta

Tuesday, September 25, 2012

GameDoc: On the fly Javascript game modding for the mobile web

I had a crazy idea and wanted to create a quick experiment to test it out. Mobile browsers are becoming good  - Javascript and Canvas implementation are becoming faster. There are certain advantages to the mobile browsers as a game distribution platform - the most important of which is that it is open and not controlled by arbitrary rules set by Apple, Google or whomever (Classic example - Phone Story). HTML5 games in general are picking up steam but game makers are ignoring the mobile browser.

There are two factors why games on mobile browsers don't work well -

  1. Game developers ignore things like centering the screen on the game area, setting the right zoom level, allowing for touch input(or any alternate mechanism like accelerometer) when there is no keyboard
  2. Browser makers don't provide a good way to do certain things  - locking screen orientation, a working audio API etc.
1) is definitely solvable while 2) involves letting platform creators know about the issues faced by game developers (Some influential developers that are already trying to do that - http://www.phoboslab.org/log/javascript). Maybe newer platforms like Mozilla OS will push the standards higher on the existing ones.

So the crazy idea is centered around the concept that HTML5 games being based on open standards should be modifiable by anyone (An idea floating around in Mozilla land) - In this specific case modified to work well on mobile browsers. If a game developer didn't take care to make the game work well on mobile browsers, anyone should be able to fix it.

To prove this point I created a proof of concept - which I called "GameDoc". For the experiment I took the game emptyblack.com. I really liked the game when I played it on the desktop and I wanted to play it on my phone. The game seems to run ok as far as the graphics is concerned but it had the classic issues mentioned in 1). Since there is no keyboard input in the phone the game is unplayable.

GameDoc is a native mobile App that basically wraps a browser WebView. It loads the game from the original URL but it sets the required zoom level on the WebView to get a good view of the game area and locks the screen orientation to landscape. And here is the cool part - It fixes the absence of keyboard by injecting Javascript snippet into the page that adds on-screen controls. When these controla are pressed keyboard events are simulated using the dispatchEvent mechanism. I used the WebView wrapper route to be able to do this Javascript injection on the device (due to absence of browser extensions on the mobile).

So here is the video of how the converted game works. The video shows how the game is not playable in it's original form in the mobile Chrome browser and how the fixed version works with simulated onscreen controls. It's not perfect - Sometimes keyup/keydown events seem to get missed and I think it might be due to multitouch issues. As you can see I really threw this together rather quickly with horrible looking icons for the controls - But you get the idea.


The grand idea is that there can be a crowd sourced HTML5 game portal where people can add their own customization to the game controls or the game itself and the Gamedoc App(or whatever better name I come up with) would pull that extra information for the game and does the necessary modding.

Can I avoid the need to have a separate App that wraps the WebView and just use the native browser? Maybe I can do something at the server side but that might screw up with things that are tied to the original domain like cookies or the local store. Maybe I can just do the controls with some sort of IME trickery.

Anyway as I said it's a crazy experiment. At the least I hope to push HTML5 game developers to think more about the mobile web.

Let me know of your thoughts/comments.

Update: Looks like IOS6 has better support for Audio opening up better game support! And the awesome folks who make Construct2 already support it - https://www.scirra.com/blog/98/the-web-as-the-platform

Thursday, November 3, 2011

go away, norman


Back from the dead. After two exciting years find myself in a different job and New York. A new start. Hopefully will not ignore my game creation itch this time.

It got rebooted thanks to the amazing folks at Babycastles and Parson school of design, who organized a game jam about a week ago.

Teamed up with the amazing geejay who handled everything from art to sound to level design as I floundered to finish the game code in 48 hours. I knew writing code from scratch in a game jam was bad idea - but I didn't have time to prepare on anything else. So just Javascript and HTML5 canvas it was. Spent a stupid amount of time on the collision detection. If I did it again I would probably just figure out some engine with basic collision detection before the game jam.

The theme of the game jam was any tweet from @Horse_ebooks and we picked "Solution to Cat behavior problems" and "It will catch up with you". So here it is our game - "go away, norman"


You can play it here.

We are continuing to work on it - Expect a more official release soon...

Friday, August 7, 2009

Please Save the Great Flea Circus!

After two weeks in development I am happy to announce the release of my first game - "The Great Flea Circus". You can play it in a few nice places that host Silverlight games.




What's with the name "The Great Flea Circus"? Well, the game is a clone of Circus Atari and hence the circus part. The flea part came because the characters I initially drew looked like fleas. Hence I made the theme a Flea circus instead of a regular circus!

The main purpose of this game was to test the feasibility of using Silverlight for game development - And I have concluded it is not only feasible it is absolutely the most productive way to develop a game given my .NET background.

Also after my previous post I have decided to switch to using Microsoft Expression Blend for the game development. Particularly I have been using the Behaviors feature in Silverlight to separate game logic(code) and game design(in Blend). For example in the Blend design window I just attach the behavior Paddle to the paddle in the designer and Jumper to the two jumpers.

An interesting thing happened where behaviors were really useful - When I showed the game to my wife (A great play tester and critic !) she asked me why there is ball in the middle of the screen which doesn't interact with the Jumpers. So I added the Bounce behavior(which the two black blocks on the sides have) to the ball and viola!, the Jumpers now bounce off the ball in the middle. It turned out to be a nice twist to the gameplay and so I left it in. Also check out the cheesy animation I put on the Ferris wheel in the background through Blend.

More on Silverlight, Blend and Behaviors in a later post. Now go and "Please Save the Great Flea Circus!! "

Monday, July 20, 2009

Loading SVG from a Silverlight Application

The problem:
I want to use SVG files as the underlying graphics format for my Silverlight game.

Why?

First why do I want to use vector graphics for all my game graphics assets? Since vector graphics are resolution independent this allows me to create the content once and scale it to the required resolution depending on the target platform without any loss of quality(which is not the case with bitmap image formats like PNG). The same graphic asset can then be used today on the web, tomorrow on some lower resoluton mobile device and later on a full screen view on a HDTV.

What is SVG? In short, SVG is an open file format that describes a vector graphics image. There are free and excellent tools like Inkscape that lets us create images in the SVG format.

What is XAML? XAML is the basic application markup language for Silverlight and is also very good at describing vector graphics. Then why don't I just use XAML for my vector graphics? The main reason is that I want to keep the original format of my game assets to be portable to other platforms.

So thats the problem in short - I want to be able to create my game graphics in Inkscape as SVG and load it into my Silverlight Application.

The solutions that didn't work
The solution path is obvious - Convert SVG to XAML which Silverlight understands and load it into the Silverlight application. Either I can do the conversion during build time or do it dynamically at runtime. The solution which can load at runtime would get extra bonus points.

So I looked at various existing conversion tools for converting from SVG to XAML.

Here is a list of the ones that I tried and rejected.

1) Inkscape XAML exporter - The current version on Windows has known bug and crashes. Also it is difficult to integrate this with the build process.
2) The commercial ViwerSVG - Allows to dynamically load SVG into a WPF application(Silverlight also I would assume). I gave it a quick spin and not very happy with the conversions. And the price tag was too heavy.
3) Next I tried the excellent XamlTune. The conversions from SVG to XAML were great and it had a command line utility which I could use as part of the build process. I saw the live version of XamlTune and was even more excited. The only problem was that the output from XamlTune works with WPF but is not exactly friendly towards the subset of XAML supported by Silverlight. I needed to find a better solution.

THE REAL SOLUTION : SVG2XAML.XSL
Enter svg2xaml.xsl. This is a XSL transform written originally by one Toine de Greef. It basically provides the rules to convert a SVG file to a XAML file and it supports Silverlight XAML! As it turns out Inkscape uses this same XSL to actually do the XAML export So I got the XSL from Inkscape since I thought it would have some extra bug fixes to it.

So now I could use a command line XSL processor like msxsl.exe and use SVG2XAML.xsl to convert SVG to XAML and it worked really well with the sample set of SVG files I had.

Now only the bonus question remained. Can I use svg2xaml.xsl to dynamically load SVG into my silverlight application? I had seen the live version of XamlTune. It seems to be using server processing for converting SVG to XAML. But that seems to be a waste of server resources. If I wrote a silverlight game I would like to avoid using sever resources since it costs money for the server CPU and bandwidth.

Can I do it entirely on the client side? As it turned out I can! Eventhough Silverlight itself doesn't support doing XSL Transforms it can call into javascript code which can do the XSL transform and return back the transformed XML.

Using client-side Javascript to convert SVG to XAML
The following is the Javascript code I used to do the XSL transforms from SVG to XAML. The script loads svg2xaml.xsl which in turn refers to colors.xml. I made some extra fixes to svg2xaml which allowed me to succesfully convert few more SVG files succesfully - You can get the updated svg2xaml.xsl and colors.xml.

You can use the following Javascript code in the page that loads the silverlight control.

function loadXMLDoc(xml, isFileName) {

var xmlDoc = null;

// code for IE
if (window.ActiveXObject) {
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async = false;

if (isFileName) {
xmlDoc.load(xml);
}
else {
xmlDoc.loadXML(xml);
}
}
// code for Mozilla, Firefox, Opera, etc.
else if (document.implementation && document.implementation.createDocument) {

if (isFileName) {
xmlDoc = document.implementation.createDocument("", "", null);
xmlDoc.async = false;
xmlDoc.load(xml);
}
else {
parser = new DOMParser();
xmlDoc = parser.parseFromString(xml, "text/xml");
}
}
else {
return null;
}

return (xmlDoc);
}

function svg2xaml(svgString) {
var xml = loadXMLDoc(svgString, false);
var xsl = loadXMLDoc("svg2xaml.xsl", true);

if ((xml != null) && (xsl != null)) {

// code for IE
if (window.ActiveXObject) {
result = xml.transformNode(xsl);
return result;
}
// code for Mozilla, Firefox, Opera, etc.
else {
xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsl);
resultDocument = xsltProcessor.transformToDocument(xml)

var serializer = new XMLSerializer();
var xaml = serializer.serializeToString(resultDocument.documentElement);

return xaml;
}

}
else {
return null;
}
}


Then you can call this javascript function from your silverlight code to convert the SVG file to XAML which can then be loaded in the silverlight application. The following code prompts the user to select a SVG file on the local computer's file system and converts into XAML by calling into the javascript code using HtmlPage.Window.Invoke. It then displays it so that it fits the current silverlight control dimensions. "mapCanvas" in the code below is the just the main Canvas object that displays the loaded SVG image.

...
using System.IO;
using System.Windows.Browser;
using System.Xml;
using System.Windows.Markup;
...


OpenFileDialog fileDialog = new OpenFileDialog();
fileDialog.Filter = "Graphics files (*.svg)|*.svg";

if (fileDialog.ShowDialog() == true)
{
string svg = null;
using (StreamReader reader = fileDialog.File.OpenText())
{
// Store file content in 'text' variable
svg = reader.ReadToEnd();
}

try
{
// Call the Javascript XSLT processor to convert SVG to XAML
Object returnVal = HtmlPage.Window.Invoke("svg2xaml", svg);
if (returnVal != null)
{
string xaml = (string)returnVal;

Canvas canvas = (Canvas)XamlReader.Load(xaml);

double scale = Math.Min(640.0 / canvas.ActualWidth, 480.0 / canvas.ActualHeight);

ScaleTransform scaleTransform = new ScaleTransform();
scaleTransform.ScaleX = scaleTransform.ScaleY = scale;
canvas.RenderTransform = scaleTransform;
canvas.RenderTransformOrigin = new Point(0, 0);

canvas.SetValue(Canvas.LeftProperty, (mapCanvas.ActualWidth - (canvas.ActualWidth * scale)) / 2);
canvas.SetValue(Canvas.TopProperty, (mapCanvas.ActualHeight - (canvas.ActualHeight * scale)) / 2);

mapCanvas.Children.Clear();
mapCanvas.Children.Add(canvas);
}
}
catch (Exception ex)
{
mapCanvas.Children.Clear();
TextBlock text = new TextBlock();
text.Text = ex.Message;

mapCanvas.Children.Add(text);
}
}


Demo:
You want to see something cool? Here is the Live version of the silverlight application served via Silverlight streaming. You can download the following test SVG files locally and then load them into the live application by clicking on "Load Graphics" and selecting the local SVG file (Wikipedia has tonnes of public SVG graphics).




Caveats
The XSL transform is not perfect. Some SVG files might error out during conversion. It works well for most SVG files created with Inkscape which stick to mostly Paths and use linear or radial gradients.

Also, even though the above javascript code tries to be cross-browser it does not work very well outside IE and FireFox. IE works the best with this code. Even Firefox doesn't work completely because the XSL transform applied is slightly different than IE. The XSL transform behavior is so different in Opera that many of the sample SVGs above don't even work. Safari didn't even come to the transformation part of the javascript.

Please consider this as a proof of concept. I will be posting updates to the SVG2XAML XSL and the Javascript code as I figure out how to fix these problems.

Final Thoughts
So there we have it. The ability to load SVG graphic files from a Silverlight application and that too dynamically at runtime. What use is it to load the SVG file dynamically at runtime by doing conversions in the client side? Think Live Game Map Editors...

Thursday, July 9, 2009

Silverlight for games

Target set. Weapons chosen

What sort of game do I want to build?
Even though this blog is quite recent, I have been thinking about the kind of game I want to make for a long time. I asked myself - "What do I miss in games these days?". Then I knew what I wanted to build. A simple 2D adventure game with a deep plot line. A game simple enough that anyone can pick up and play. A game that packs entertainment in a nice little package so that you don't have to invest 40-80 hours to finish it.

A game where the story is central and the graphics and game play are just elements that help in telling the story. A game which someone shouldn't feel bad for giving up a good book for (OK -I might be setting the standards too high here)

Weapon of choice?
Having decided what I wanted to build I started thinking of the tools I want to use to build the game.

My initial choice was XNA and it was an obvious choice for games. I have been dabbling with it and was quite excited about being able to deliver games on the Xbox 360 through the Community Games channel. I had even figured out the toolset with Paint.NET for pixel art and a custom Game Map Editor like the Xna Map Editor and even looked at SilverLua for game scripting.

Then I started looking at WPF for the Game Map Editor since it was much easier to get traditional UI as well as 2D graphics needed for the map editor(instead of hacking XNA with WnForms). This is when something clicked inside me. Suddenly Silverlight which shares its API with WPF seemed to be a really compelling option.

Silverlight vs XNA

Advantages of XNA
1. Ability to deliver the game on Xbox360(or the Zune). There is no other way to do this currently without XNA.

2. XNA is built for games. Silverlight on the other hand is not. There might need to be some adjustments made and some performance/features sacrificed owing to this.

Advantages of Silverlight
1. With the little info available XNA community game sales, it seemed to be not that exciting after all. I felt more and more that PC was a bigger delivery platform especially given the nature of the game. I had better chances of delivering it to a more casual audience through the PC than the Xbox. For this Silverlight is much better suited than XNA since I don't have to worry about installation, runtime redistribution issues in Silverlight like I would have to do with XNA.

2. As an added bonus I can potentially get the game delivered cross-platform to Mac and Linux if I used Silverlight (Even though I am not sure how open Mac and Linux users are to an Microsoft technology)

3. In game UI can be greatly simplified by using the Silverlight controls but at the same time have the flexibility to "skin" the UI to make it look more exciting in a game environment

4. Making the game experience more social by integrating with social networking sites(like Facebook connect) is much easier with Silverlight game delivered on the web. This opens an entirely new avenue to explore.

5. Containing piracy on PC would be easier with Silverlight than XNA (Or so I hope. Theoretically it would be possible to get the Silverlight code and find a way to hack it and run it offline)

6. Delivering the game solely through the web also opens interesting monetizing options.

7. The Roadmap for Silverlight with Silverlight 3.0 and beyond like Out of Browser experience and GPU accelerated graphics is quite exciting.

So there it is. I've decided to use Silverlight for my adventure game.

An intersting side effect of chosing Silverlight is that I started to increasingly consider Vector Graphics for my game instead of raster graphics since WPF/Silverlight 2D API is more vector graphics based. The main advantage in my mind is cleanly scalable graphics and resolution independant games (Consider playing a silverlight game full screen. Scaling pixel graphics would make it blocky or too fuzzy after filtering to avoid blockiness). I have looked at using the cool and free tool Inkscape for SVG graphics that can be converted to XAML and used from Silverlight(More on this in a later post)

Flash?
People might ask me why I didn't consider Flash at this point. It has all the advantages of Silverlight as well as much wider adoption across machines and platforms. The main reason is I like the productivity I get on the .NET platform over ActionScript or whatever new environment I have to get used to.

Also the installation of Silverlight on Windows takes less than 20 seconds and I don't think that should be a big barrier if the game turns out to be good after all. (I am not sure of the experience on the Mac and Linux but something I will be looking into).

And again the roadmap/rumors on Silverlight on Mobile platforms(and Xbox360?) makes me think Silverlight might not be bad after all in the longer run.

iPhone?
Everyone wants to get their game onto the iPhone. It seems to be becoming the defacto mobile gaming platform that is open enough to be easily developed for. At this point I am going to concentrate my efforts on the broader PC base and probably revisit iPhone development at a much later time(once my game is successful?). For now I am just making sure I am not basing any of my game data directly dependant on Silverlight(like using XAML) so that it can be more easily ported to other platforms. Who knows? Silverlight might be ported to iPhone even.

So that's it. I have decided on the game to be built and therefore the technology to use based on my target platform.

This post has become much longer than I anticipated. Please feel free to post your comments here if you disagree(or agree) with me on any of the above things.

Update(July 10th, 2009) : Silverlight 3 has been released

Sunday, July 5, 2009

Why this blog

I am setting up this blog so that I can chronicle and share out my experiences in trying to become an independent game developer.

Right here is step 1.

The other purpose of this blog is to share out information on specific technologies/ideas that I have been playing with in creating my games - Aggregation of information I found on the web or things about which I haven't found enough information on the web where I would like to fill the gaps in.

Also my hope is that this blog would be a place where I would announce progress and completion of my games and the lessons I learnt on the way.

And finally the name of my blog "indie-indian" - Is to probably just identify myself with the sub-minority group that I am in - The Indian independent game developer. Maybe there will be some posts on this, trying to reach out and connect with others in this group. Maybe if I become successful I can get more people into this group...