Monday, 19 December 2011

Random stuff #1214141412

Something I implemented a couple of days ago while my net was down, based on some readings from Game Engine Design by Jason Gregory (http://www.gameenginebook.com): 
 
Basically what I did there was add three differently colored lines pointing in the direction of each Coordinate Axis (X, Y, and Z). This is the basis for Debug Drawing, which is an amalgamation of techniques that allow a developer to verify why something is behaving differently than it should.

For instance, let's say that your character is shooting oddly. You could draw a line from its position towards the direction it is pointing at to verify what exactly is happening instead of just reading some confusing debug values or trying to figure out why your code is not working properly.

This is only a simple example, of course, but it is nonetheless very useful.

Tuesday, 29 November 2011

Fling for Android released!

That's right, after a little over 9 months of work, Fling for Android has been released at last.

Right now you can't find it on the market without a direct link, since it was released just a few minutes ago, so you can find it at http://bit.ly/sd8bpO

Here's a youtube video on how the game is played:

Tuesday, 27 September 2011

Game Design Fragments: Layered stats


DISCLAIMER: I'm not the best game designer out there, however I often come up with interesting ideas. I don't mind if you take an idea of mine and use it in a game of yours, however I'd love to know of any games that use any of my ideas. A credit line like idea based on the thoughts of Nuno Silva (Little Coding Fox)" would be nice too, although it is not required. I hope you find this information helpful.

Layered stats

We could have layers of stats, instead of the usual RPG stats. For instance, having a high confidence stat should increase both agility, precision, and speachcraft. So you'd have on the top layer, "Confidence", and on a lower layer "agility", "precision", "speechcraft".

Increasing a stat would automatically increase the upper stats related to it (so increasing either agility, precision, or speechcraft would increase Confidence too), and increasing a upper stat would increase all lower stats. (If you're confused by what I said, upper/lower means higher layer / lower layer)

This is interesting because increasing a lower stat would increase the upper stat, but would not increase all other stats of the same level. So the most expensive equipments for role playing games with this kind of stats would be those that increase the top-most layer, since it would increase all other stats.

Friday, 2 September 2011

Stuff I've done at CandyCane LLC



Figured this would be useful somewhat, especially as a way to see what I've accomplished so far at my job...
I'll be updating this from time to time, since I can't remember everything I've done so far.


Not Platform Specific

  • Developed a CRC32 generator for unique IDs based on a string's data, more often used to save time when using Maps or to generate a unique ID for a game object
  • Developed a drawcall cache that caches several similar drawcalls and then draws them when a call with a different texture/blending mode is applied

iPhone

  • Developed Facebook, Twitter, and E-Mail support to Fling
  • Developed a custom Sound Engine supporting sound and music streaming, self-repeating sounds, music cross-fading, among other misc features
  • Implemented AdWhirl ads on the free version of Fling

Non-iPhone

  • Reimplemented native widgets like Text Fields and Alert Views to either a custom OpenGL implementation or the native equivalent of the targeted platform
  • Reimplemented large platform-specific parts of the CC codebase, like the OpenGL implementation, sound, file access, among other low-level code, from iOS to the targeted platform.
  • Developed a custom libPNG image loader that supports Grayscale, Gray-alpha, Indexed, and RGB/RGBA images, processing RGBA images so they had their alpha premultiplied.
  • Developed a custom FreeType text renderer that takes care of properly converting UTF-8 to UCS-4 in order to not only render high-quality text to existing bitmaps, but also to render unicode text properly. This renderer also formats the text accordingly so the game only had to send a blob of text and the maximum bitmap size to format and the formatting type (Characterwrap, Wordwrap, truncation, etc)
  • Reimplemented SFML's HTTP client to use non-SC++L code, since SC++L code of any kind would crash on Android, and used it to query the CC server for statistics purposes

Android

  • Partially (as of this post's original posting date) ported Fling to Android
  • Implemented AdMob ads and Tapjoy Offers for Fling Free
  • Implemented in-app purchases
  • Developed multiple java "gateways" to save RAM and allow the C++ side of the game to take as much control as possible.
  • Implemented screen scaling so the game works on all screen sizes.
  • Due to a lot of problems with the Android platform and Native Code, had to debug most things with no debugger, or at the very least, a print-based debugging session (that is, no debugger, just printing values from relevant variables or states)
  • Implemented app licensing and obfuscation of java code 
  • Implemented a common java library used by all versions of Fling based around a base class that handles communicating with the native C++ Fling code and several Feature Sub-classes that implement features such as Admon Ads and in-app purchases
  • Implemented save file transferring between free and paid versions of an app
  • Wrote an app that can gather a user's adb logcat without that user having an SDK

webOS

  • Ported Fling to webOS
  • Partially ported Fuzzle to webOS
  • Developed a SDL_ttf Text Renderer (later superseeded by a FreeType Renderer I also developed)


Wednesday, 31 August 2011

Special Delivery

I was looking through some of my mediafire files, and noticed an old not-so-stable version of some tools I developed for WorldBase. Those of you who have been following this blog might recognize them as the material editor, the model converter, and the world editor.

Since I ended up dropping it in favour of making the game on a stable game engine so I wouldn't get lost on the technology, and since I broke it all in the end (so I can't get you any code), and since I noticed that even if it was never completed, it was still pretty cool, I figured you guys might be interested in trying it.

Download Link: http://www.mediafire.com/?gmmyvkoykmn

Some Guidelines:

Some elements were never completed. For instance, some nodes on the Material Editor can't even be created, and the Light entity on the World Editor will crash the editor since it was never implemented.

Before you do anything, you need to keep in mind that all tools require the Core.package file which is generated from the BuildPackages.bat file in the System folder. Whenever you add/remove/modify a resource like a model or material or texture, you need to call BuildPackages again.

Material Editor:

In the Material Editor, you can drag nodes from the node list to the middle of the screen that has other nodes.

You can middle-click-drag on that area to move the working area too, so you don't run out of space.

To delete a node, select it with the left click and press DELETE on your keyboard.

To make nodes work with each other, left click on a connector (the black squares) and drag towards another connector (Node Inputs are to the right, Node Outputs are to the left, you can't connect one kind with the same kind). This will create a Connection between the two nodes.

To remove a connection, you must left click the connector while pressing CTRL. It may not remove it immediately, so try clicking a few times. This is a bug which I probably solved later on but I can't recover it right now.

Constants are the most used datatype. They come in four flavours: Constant, Constant2, Constant3, and Constant4. Each can keep a certain amount of values. Most Nodes provide a certain datatype as their value, like the Fresnel node which returns a Constant, and the Normal node which returns a Constant3.

Sometimes you will get errors, like incompatible data types. For instance, you can't LinearInterpolate a Constant as the first value with a Constant2 as the second value, since they are different data types. You can get over this by converting from a data type to another. This is usually only possible when you convert to a higher data type.

For instance, you can't convert from a Constant2 to a Constant. However you can convert a Constant to a Constant2 by e.g., setting a Multiply node with a Constant2 with values R: 1, G: 1 to multiply by the Constant you want to convert. In this case, you'd set the Constant2 as the "A" input, and the other Constant as the "B" input.

The TextureSample Node allows you to select a texture from the package filesystem. It has 4 Outputs ("Black", Red, Green, Blue, Alpha). The first output is a Constant4, while the other ones are all Constants. This allows you to extract the components of the texture for various uses.

An example would be if you had a "filter" texture and two other textures who you want to combine. You could use a LinearInterpolate node to interpolate between the two textures, and use the filter's Alpha component as the last input to LinearInterpolate to do so.

Model Editor:

In the model editor, you can import bXporter models or modify existing wbmodel models. Do notice that I don't remember which version of bXporter I used, and I do know it's not a very popular format, so you'll have to make do with the .bx models on the System folder.

After you convert or open a model, you can swap the Z-axis of the model (if it's showing improperly rotated for instance), and change its size.

Mind you that changing its size is not the same as performing a scale to the model. It'll literally make the model be at most have a height of X units.

You can change the materials of each mesh of the model too. To do so, click on a material on the list and it'll highlight the area the material belongs to in yellow. Double-Click it to choose one of the materials on the Package Filesystem and then double-click that material to replace the first material.

World Editor:

This is probably the most complex tool of them all. First, you should either open an existing world or create a new one. When you create a new one, you should choose a relatively small amount of sectors. That is because each sector contains a huge area.

After you create a new one, please wait patiently until it is done processing it. It will randomly generate the world's terrain and calculate the world's pseudo-average normals for lighting (this last part might take a while, however generally speaking on any decent computer it shouldn't take longer than a couple of minutes.

Afterwards you can move around the world, use the terrain tools (Raise, Lower, Flatten, and Paint (Paint was never implemented)), you can even create your own entities and spawn them in the world.

Mind you that the default entities (Light) are not implemented, and trying to use them will result in a crash. You can create new entities, although a lot of entity settings (Like having Physics and Client/Server ownership) do nothing since I never got to implement them. You can select a model, and then save the entity library and use it within the world. Other than that you can also browse the world around.

The viewport controls work as soon as you left-click once at it, so the viewport will gain Focus for your mouse input. Then you can hold the right mouse button to do mouse look with the camera, and use the left mouse button to use whatever tool you're using at the time.

That should be enough detail for now. I've delayed this post long enough. Remember that this is not a production-quality release, I'm only releasing it now because, although incomplete, it is "cool".

Monday, 18 July 2011

UDK Adventures #1

I was playing with the UDK yesterday, making a fancy C++ DLL. This has been the 3rd time that UDK behaved oddly.

First it exhausted all my free RAM (That's over 4GB of free RAM out of 6GB) just trying to compile my scripts to use the DLL. Then it kept compiling forever without increasing much RAM. All this for a piece of 100% completely valid and completely logical code that had no way to cause any potential bugs at all.

Like I said, this already happened at least 3 times. It makes no sense at all how these issues happen, really... my first time it would say it can't Bind to the DLL, and the reason was that my DLLMain function did not return a value.

What the hell, man?

Sunday, 3 July 2011

Android Adventures #2

Here are a few more issues I remember having while porting Fling to Android (Note: When I refer to java code, I mean Android Java-specific code):
  • Optimizing the code with the compiler (e.g., -O1/2/3) caused awful graphical corruptions (see http://i51.tinypic.com/raqogl.png for a sample). Solution: Use vs-android and enable compiler optimization flags for certain files you figure could have something to do with it (e.g., your texture loading / resource loading class. You may even have to split the offending files so you can keep non-OpenGL code optimized.
  • The Java VM has a limit of 16MB for the Java heap, while the native heap has no limit. That means that for any minimally sophisticated game out there, you'll have to use the Android NDK to make a native binary while using java to access the Android APIs.
  • The file management APIs don't have any way to get the size of a file or seek it. This is especially bad for Asset files, which are resource files bundled with your package, since those are encrypted. So you have to read each file you need in chunks until you get a EOF flag while reading. In fact, there is an available() method that will return the total amount of bytes you can read until it "blocks for more input". That means that it can return 0, 1, 1234, infinite, etc. See http://developer.android.com/reference/android/content/res/AssetManager.AssetInputStream.html#available%28%29
  • (@#2 and #3) Because of these two problems, when our native code needed to read a resource file, I had to read the file to a java byte[] array, pass it as a buffer to C++, and then use a hackish way to change our File class's implementation between a resource file and a regular file since regular files didn't need to go through Java.
  • Java code sometimes doesn't behave in a standard way. An example of this would be when I created a texture through Java and used glTexImage2D, so I wouldn't have to compile libPNG and zlib statically with our bin. It would always fail with an INVALID_VALUE error. The documentations say that INVALID_VALUE only happens when width or height are < 0. The very same code, in C++, worked with 0 GL errors.
  • I had to load the game in a separate thread, not only because it could take a significant amount of time (On debug anyway), but also because a black screen for more than a second can cause any user to quit the app. The fact that the OpenGL thread is not on the main thread due to the way the GLSurfaceView class works didn't help either. So I had to make a proxy to properly init textures, and to draw the loading screen.
  • (@ #4, #5, #6) Because of all this, I had to severely modify the way textures are loaded and ended up doing the following when a resource file was required:
Java reads multiple chunks into memory while keeping a huge-ass buffer (e.g., 5MB in size) to prevent reallocs (this happens with any resource file request)
Copy the resource data to another array to prevent potential overlaps of read/writes through threads (Only copies actual data, not the whole 5MB buffer)
Copy the java resource data array to a C++ array
Free the java resource data since memory is of the essence
Decode the resource data with libPNG
Save the bitmap data, verify whether we're starting up (e.g., not on a GL thread), if so, queue it for init, otherwise init it now
On the GL thread, at the beginning of a frame, for each texture queued up, init it.
  • The Emulator runs at nearly 1 to 10 FPS most of the time. On a Core i7 2.80GHz computer. In fact, it will not run Fling, and will in fact freeze (as in, actually freeze, not give a "App not responding" Android warning when an app doesn't respond) and/or crash.
  • Installing the app packages takes over 2 minutes on the emulator (60KB/s), while on device takes less than 20 seconds (1-3MB/s on any decent device, 4+MB on a Samsung Galaxy S makes it take less than 6 seconds).