Archive for the ‘Alone, The’ Category

The Monday Report – Boxing Day “Dead Health Potion” Edition

Monday, December 26th, 2011

Uh... I am concerned about what that potion would do to me if I drank it. (a typo/bug from today, hehe)

Hello! This is quite possibly the last post I’ll do in 2011, so lets make with the goods!

This past week I’ve continued working on the demake of my primary project. If you checked out the Ludum Dare prototype, the core mechanics have dramatically improved since then (about 4 days ago).

I actually keep a relatively detailed development Journal while working, but a lot of stuff is either very minor, subtle, contains spoilers, or is simply just too long to post. So what I’m hoping to do regularly is to comb my Journal, and pick some some interesting highlights to show off.

Lets get started!

On December 24th, Xmas eve, I finally switched fonts over from Ariel to the traditional Commodore 64 font. Even though I’m breaking the rules of the Commodore (font is not monospaced, artwork is not pixel double wide, I use varying levels of alpha transparency, audio is not SID), but I still think it captures the vibe. I’m all about vibe. 😉

Text Features! Info bar at the bottom, Commodore 64 font, large numbers on criticals, object names

Later that day, I added proper color scheme support. I have 2 schemes. Commodore 64 Colors:

For the Commodore Junkies

And Vivid Colors:

For everyone else

Finally, since yesterday (AKA. Christmas to some people), I’ve started roughing out items and inventory.

Okay, I thought it was pretty funny, so I left a 'feature' in that let me pick up the bodies of killed enemies

At the moment, the potion can be used, and that’s all the inventory is good for. I just today finished up a bunch of ground work needed, so I should be able to get equipping of items working today.

That’s all for now.

Again, I’m hoping to do these reports regularly. Monday sounds like a good day. No promises on when Mondays, but the goal is certainly sometime Monday. Ta!

Ludum Dare Prototyping

Thursday, December 22nd, 2011

I wont talk too much about how Ludum Dare itself went, as I’ve already done that over here.

But in addition to running the event, I participated for the first time in a long time. The theme was “Alone“, which I find funny given the title of my game. Could I not enter? 😉

About a week before Ludum Dare, I started toying with the idea of creating a demake of my game. I didn’t put too much thought in to it at the time, but it seemed like a good idea and a change of pace. Oh, and I decided to do it in JavaScript using an HTML5 Canvas 2D. Again, a change of pace.

What I didn’t realize though is that it was a GREAT idea.

The past few months I’ve been spending majority of my time building the tech I need for the game, but not spending so much time on the gameplay, the mechanics, and so on. So I have a bunch of pieces working together, but not much game.

So once the Ludum Dare theme is announced, I ran with the demake idea, and about 3 days later I have something far more fun and interesting than I had before… Written from scratch, in JavaScript.

Fighting some Bats

It’s short and not a deep game, but it is a functional prototype that demonstrates some ideas and goals of the design. That’s what prototypes are for: trying out ideas.

You can try it here:

– Best played in Firefox, in Full Screen (F11).
– F5 to reload (WHEN you die, MUAHAHA!)
– If using Flash Block or NoScript, enable Flash. It needs Flash Player 9+ for Sound.
– Arrow Keys, Mouse, or Touch Screen.
– Works on all current Browsers. Some may lack sound.
– Works on all current Mobile Browsers too! Best in Firefox Mobile (w/o Sound).

I wont say anymore. If you’re up for something quick, give it a try. Let me know how your first play-through went, how well you were able to do, and perhaps how many deaths it took. 😉

I actually did not finish the game within the 48/72 hours of Ludum Dare, but just a few hours later than that. It was a mostly good event without too many website problems, but right at the end the ENTIRE INTERNET decided to link us and considered us newsworthy! We were a headline news story on IGN PC nearly all day. Sure, the story was about Notch and the game he made during Ludum Dare, but still. Holy cow! IGN, Kokaku, Joystiq, Rock Paper Shotgun, Destructoid, The Escapist, Edge, PC World, BBC, Wired, Venture Beat, The Verge and Geek to name just a few. 🙂

So, I had a pretty good excuse for being late. 😀

Creating the demake has been an incredibly beneficial to the design. For one, I have something playable right now that can be critiqued. There’s going to be a lot of iteration and improvements, before it becomes a shippable product. And I honestly cannot complain about it taking only 3 days to get it working. That is fast. I am seriously, almost committed now to finishing this HTML5 incarnation of the game, and releasing it as a sort of prequel. That way I can step entirely through the design, start to finish, and have a better well-tested core design for the one I want to charge money for.

Admittedly, I’ve been avoiding prototyping and experimenting in languages that aren’t C++. I was never comfortable with the idea of writing code that *must* be thrown away, due to syntactical differences. I have, on a few occasions, wanted to write a sort-of language converter; Write code in some general dialect, and export to the variants. I briefly looked in to haXe, but really didn’t like how fat the C/C++ generation was. Nothing ever came of that desire though.

JavaScript I rationalized by the rather safe assumption that “JavaScript will never die”. I certainly don’t plan to stop using the Internet any time soon, and HTML+JavaScript are pretty much all internet. So learn to love it, and you’re better off.

And actually, I do quite like the language. Unlike Java, it does not force OOP style designs. You can OOP, but you don’t have to. It feels more like a really wacky version of C, with super flexible macros, than it does Java. Structure can start hacky, dirty, or essentially functional, and over time it can be cleaned up. It’s nice.

The future of Flash is a bit uncertain, though it sounds like Adobe will be making it more of a general 3D gaming VM, to solve the whole WebGL problem on the desktop (i.e. Microsoft’s Arrogant Pride X). And that’s cool. That sounds useful to my native codebase. But I’m left concerned about where that leaves a large codebase built over the next few years. It may do sound, but it’s still not going to run on iPad. So Mike, Mr Portable Code, has decided JavaScript should be his #2. Prototyping, game jams, and since it’s the whole internet, we can accept it.

What’s also nice about JavaScript is its similarity to Squirrel. Sure, JavaScript/EcmaScript is the old man, the daddy, the parent of the relationship, but after much homework Squirrel is what I chose for my embedded scripting in the new game. It has distinct floating point and integer types, among other things. In general it’s designed as a Lua alternative, embedded scripting, conscious of the things us game developers care about (memory usage. GC is optional). And hey, best part, it counts from zero instead of one, unlike Lua. It’s been a while since I dabbled with it, and honestly I haven’t done much with it. But after a review of it this morning, I’m actually quite pleased to see much, if not all of the syntactical features I got comfortable using in JavaScript are available in Squirrel. Heck, it looks like I’ll be able to bring over some of the code as is; Rename a few “var’s” to “local’s”, a few other minor tweaks, and that’s it.

Very encouraging.

So that’s my little rambling. I’m still shooting to meet my “Learn more GDC time” goal, which means March, which means ~2 months from now. What exactly I’ll have for then is a little different than I had hoped originally, but just as good. Back to work! Lets see what I can finish before the end of 2011. Go go me!


Thursday, November 10th, 2011

Enough of this non-game talk.

The past month has been extremely good for progress. I did not meet my goal for the month, but I’d be silly to complain. Yadda yadda ya.

Against my better judgement, I’m going to stop beating around the bush and show you:

A mish-mash or random objects sitting in some sculpted terrain. Subtle glow. Vignette blur.

That’s cool Mike, but what is it?


Wait Mike, you could have done that in a day using Unity? It would be faster!

So? What’s your point?

I’m a fairly capable (and technical) coder, and something I’ve wanted to do was code the 3D tech for a game. What I have after a month is nowhere near as cool as Unity or UE3, but it is comfortable and capable for me. So yes, I’m working in C++ writing OpenGL rendering code and shaders. Why? Because that’s what I’m comfortable in.

Oh, and it runs on mobile too.

Running on a low cost (~$100) Chinese Android device featuring an ARM MALI-400 GPU

There really isn’t any significance to this above device, aside from the cost, or perhaps its own insignificance. Like what Smiles became, I’m testing my code across a plethora of modern devices as I go along.

I am not particularly targeting this for Moblie. If anything, PC is my primary target. In working on the tech though, I’ve found that by changing the target platform regularly, I find issues with code that I would not have discovered until much later.

My regular test devices include:
– PC (Windows Desktop) with an NVidia GeForce GTS 240 GPU (custom, my workstation)
– PC (Windows Desktop) with an AMD Radeon HD 6670 GPU (custom, my standing desk PC)
– PC (Windows Notebook) with an Intel HD 3000 GPU (Lenovo X220, my laptop)
– Phone (Android) with a PowerVR SGX 540 GPU (Nexus S, and my phone)
– Tablet (Android) with an ARM MALI 400 GPU (Onda VX610W)
– Tablet (Android) with a Vivante GS800 GPU (Window N50 DT)
– Tablet (webOS) with a Qualcomm Adreno 220 GPU (HP TouchPad)

Notably absent are iOS devices and a device featuring a Tegra 2, but as you can see the goal here was to cover every serious GPU vendor today. I’m currently only interested in shader capable GPUs that benchmark equal or faster than an iPhone 3GS (PowerVR SGX 535). At the present time, there are no plans to support fixed function rendering (Intel GMA 945, PowerVR MBX, Wii, PSP).

The thought is by having a device on hand featuring every major GPU, I’ll be able to find the most ideal and cross platform friendly way to render things. I would still like to get my hands on an NVidia Tegra based Tablet, a PlayBook, an Xperia Play, and something with a parallax barrier display. But unless I can find one stupid cheap ($100), I wont be buying them any time soon.

Though I have all these devices and am regularly testing against them, I’m not optimizing for mobile yet. Yes, I will eventually do tablet and mobile versions, but I am starting with the PC. The variety of devices are here as a sanity test for my code. If it runs everywhere, unplayable framerates aside, then it works.

That’s cool Mike, I see you’re still a porting nerd.

What are you actually making though?

I’ll tell you when you’re older.

Oh come on!

Alright, here’s a mockup I made back in 2009.

Apparently I've been designing and redesigning this game since before I started Smiles

That but better.

What does the post title mean?

Reinventing? Apparently a few things.

The main one is how I typically work. I was going to sit on this, wait and keep working until it was just right, then do a big push. That sucks. It takes forever and I build no buzz/interest prior to the launch of the game. So fine, lets not repeat Smiles’ mistakes.

The other is that I’m building a story driven game. I have a story I want to tell inside a game world, and I still plan to do this. However, it’s going to take me a while to get that far. According to my latest math, the soonest I’d be able to release was going to be early 2013. Yuck.

So let’s change that.

Now this doesn’t mean I’ll be releasing something tomorrow, but the plan is to make something available publicly far sooner. My goal is still to make this story driven game, but I’m going to make another game too, using much of the same content. In a sense, an expanded testsuite for the game I want to create. Less focus on the continuity, but a definite focus on how it plays, how it looks, and in time entertaining in its own right.

This here is the first step. Hello, yes, I am working on something. And over the next few months, it’ll start becoming something.

Notes: Exporting .bullet data from Blender 2.5

Thursday, October 6th, 2011

Here’s some notes from my internal wiki.

How to export .bullet data from a Blender 2.5x scene (awfully close to 2.6 now ‘eh). This might be as of Blender 2.57, and should continue to work well in to 2.6x.

Exporting Bullet Data from Blender

Exporting Bullet Physics data from Blender is a pain in the ass. Plain and Simple. It *SHOULD* be a right click export, but no, it’s complicated.

1. Switch to Game Engine Mode (In the Title Bar, the default setting is “Blender Render”. Should be “Blender Game”).
2. Game Engine Mode changes the *Physics* Properties (bouncing ball)
* Make the Physics Type a “Rigid Body”
* Enable Collision Bounds, and pick a bounding volume type (boxes, hulls)
* To make compound objects, you need to treat one object as the parent, and check the compound buttons
* Under the *Object* Properties (tiny cube), Relations Parent can be used to identify oneself as a child of a parent
* Defining compound objects is required to make overlapping volumes that don’t affect each-other.
3. Change a pane to a *Logic Editor* (little red-ball joystick)
4. Add a “Keyboard” sensor, and set the key to the spacebar (for example… we’re binding the spacebar to an action)
5. Add a “Python” controller
6. Change a pane to a *Text Editor*
7. Hit + to create an instance (default name is “text”)
8. Paste the following script in to the text editor

9. Update the “Python” controller to use this script file
10. Drag a link between the Keyboard sensor and the python controller (see the little nodes between them)
11. If you haven’t already, save the .blend file. If you close Blender, then double click on the saved .blend file, it will change the current working directory of Blender. This is important, because the script above (with no path) saves the .bullet file to the working directory.
12. Finally, to generate the blend file, run the simulation (R key).
13. To export, while the simulation is running, push the spacebar.
14. The console will show the “Exporting…” message. If you don’t have a blender console, you can enable it under Help->Toggle Blender Console

Done. That’s the annoying way to export .bullet data from blender.

The reason for the complicated procedure is that the PhysicsConstraints and bge libraries are just not available in standard plugin scope. Right clicking and running the script, just not an option. So we need to enter a game instance, where all these helpful library instances exist (as otherwise you wouldn’t have physics).

Research conducted on October 6th, 2011, using Blender 2.59.


On the Journey to Live Coding

Saturday, August 13th, 2011

This past couple weeks I’ve been busily working on architecting many little things (super important things) for my new game. One of the big things I really didn’t set out to do initially, but once I realized my efforts were converging there, I decided to make it a priority: Live Coding.

I am using a scripting language Squirrel to handle the gameplay side of the programming. This is new for me, having hardcoded or written my own sub-par scripting and data entry dialects to make my prior games.

I opted for Squirrel over LUA due to its similarities to C and C++. It’s created by a fellow gamedev, so issues we have with the LUAs of the world are taken in to serious consideration. It counts from zero (!!), uses C/C++ style comments, has an integer type, uses float instead of double, uses reference counting instead of a GC, and most importantly: uses a file extension “.nut”… LET THE TOTALLY SILLY LATE NIGHT CODER JOKES BEGIN!

Performance benchmarks of Squirrel 3.0 place it on-par with the non-JIT LUAs. There’s a well known scripting benchmark that shows Squirrel doing poorly (Version 2.2), but a friend did his own benchmarking recently that shows things have dramatically improved. Another dev informed me that LUAs JITs are now available on ARM and PPC, and at least the ARM benchmarks are a huge improvement (PPC not so much). Apple still has their execution policy in place, making a JIT useless, but that aside I value my own sanity and prefer not-to have to switch my brain in to coding thinking too far away from my comfy C/C++, and admit there are elegance improvements to be made over that (I see working in Squirrel to be a potential improvement… maybe!).

On Live Coding again, I see it as more than just code. Right now it’s only script code, but very soon I plan to extend this to other forms of game content (textures, models, shaders, maps, etc).

My Live Coding setup is bound to the Window focus. When the game re-gains focus, a process of scanning content begins, and any assets found to have changed are reloaded. Pictures:

Script before modification. Showing a no-change refresh. Currently just text printing that AWESOME line.

An ALT+TAB, some munging with the Main.nut script file, an ALT+TAB back in:

After modification, things go from AWESOME to SILLY. Tom is an instrument.

Assuming there were no errors, script is recompiled and executed, so that it re-overloads the referenced functions.

I’ve given myself a relatively short timeline on this game, considering what I want from it, and considering all the distractions I have in the coming weeks (I am moving early September). I want something playable by IGF Submission time (October 17th), though I’m undecided if I am entering (unlikely far enough). I want it VERY playable for GDC (March 2012). I want to be shipping on the first platforms late Summer 2012, so roughly a 1 year timeline. Being able to SUPER-RAPIDLY do and test something in game is VITALLY important if I’m going to make it.

Currently the Live Code system is set up for Squirrel scripts, the language all gameplay code will be written in. Next up I need to add support for Shaders, Textures, and 3D models. Search paths are already set-up to pull files from the source folders first (unless a release build, then native/optimized content gets loaded first).

Next weekend is Ludum Dare, so I have a little bit of work to do there in the near term. I am hoping to have several forms of Live Code-able content ready to be used before we begin the event. Fun fun.

Premake: My new best friend (RE: MSVC & Xcode)

Sunday, July 31st, 2011

Alright, I’ve spammed the twitterverse enough.

Here’s something I started playing with today, and finished just a few hours later, satisfied. Premake. In essence, it’s a build script and project file maker, just like CMake and Scons. It uses Lua scripting, to contrast custom and python for the others (CMake a Scons respectfully).

If you weren’t me, you could save yourself a slew of portability headaches with this simple script.

(From here)

Stick that in a folder with code, or code found in some directories. Then from a command-line, invoke the tool premake4 as follows:

premake4 --file=myfile.lua vs2008

Blam! Your prize, a Visual Studio 2008 project file and solution. Want 2010? Just change the argument.

Want it building elsewhere? Walk over to your Linux box, or your Cygwin/MinGW shell, and do this:

premake4 --file=myfile.lua gmake

You now have a makefile.

Of course, anyone that’s done project management knows that the above is just your most basic of projects. Standard C/C++ libraries, and whatnot. Per platform you still need to link versus external libraries (OpenGL, SDL, etc). No problem, just add new sections to your targets. includedirs, libs, libdirs, and so on. Want to apply a setting to both? just place it a level up in the hierarchy. Nearly everything you would normally do on a platform, there’s a means of adding content to that.

Honestly, there’s little point having me regurgitate how to start using it, as the docs have a wonderful tutorial that steps through it. And once you get to the files stage of the tutorial, you can generate a usable project file with just that. Here’s the link:

My one last tip though, is that the scripting interface is doing some housekeeping behind the scenes. The functions Solution, Project, and Configuration specifically. Calling them changes the scope of the calls that follow. This is important to note if you try to use normal Lua scripting activities, a “printf” will write to the console as the project is generated, but not while it runs. There’s a command for setting the actions at each stage.

Oh, and you can invoke MSBUILD from the command-line if you want to live in shell land (like me). Start a Visual Studio 2008 shell (under Start Menu/Visual Studio 2008/Visual Studio Tools/..), then browse to and invoke it as follows.

msbuild MySolution.sln /property:Configuration=Debug

And presto. Your actual errors will be logged to the console window.

* * *

So hey, ahem, back on topic. If you’re not me, you can use something like this to do your project management work. I however have and REALLY LIKE a fancy GNU make based build system I wrote. Unfortunately, this only helps me when I’m developing for Windows, Linux, and certain devices. It does no good when I am actually required to use Visual Studio (certain libraries, DRM, SDK’s), or Xcode on Mac. But that’s where Premake comes in, to take care of that stuff for me.

I have some wild plans ahead, but I wanted my original working script available somewhere. Hit the jump for the full listing.

Remember, it’s Lua, so double dashes are line comments.