Through work, I got an evaluation copy of ScaleForm’s Flash-based UI SDK. Unlike business apps, where UIs can be static, games invariably have animating menus, windows, and buttons. Flash is perfect for this. The other option is HTML with animated gifs, but HTML rendering in games is a fairly new thing(see Gecko and WebKit) and won’t be mainstream for a year or two.
And compared to all UI SDKs for games I’ve worked with this is by far the slickest and probably most useful. There have been technically more advanced UI SDKs, but the real power is in leveraging Flash as the UI creation tool for games because traditionally creating UIs have meant editing textual layout files by hand.
I harp on this to game development newbies: tools, tools, tools. There are hundreds of 3D engines out there, but few can rival Unreal, Source, OGRE, Gamembryo because of their tools. The power is getting art assets into a game engine quickly… and most engines can not do that and require manual processes which are buggy and human error prone.
It happens all the time. With me – “Boom Boom Rocket” – was the most recent example. Although, I didn’t think it had any commercial appeal beyond the DDR junkies and my version would be 100% “Artsy-fartsy.”
Yesterday, I discovered another game I thought I’d write first: mygamebuilder.com
It’s a Flex/Flash 9 based game where the player makes a tile-based web game and others can play it. Brilliant idea! Everything is hosted on the webserver so anybody anywhere can access your game. Brilliant, I say! Even the company name, Jolly Good Ideas, is brilliant.
Here’s hoping the game is success, because we’re all short on fun ideas.
For those in the GTA area – there is a mentoring / game business competition happening in the next two weeks initiated by the McLuhan International Festival of the Future
The deadline is May 31st to submit a game proposal. The coaching sessions happen June 2nd to 4th and the physical pitch sessions take place June 18th to 21st.
I seriously asked that myself that before I founded Casually Hardcore. The hours are long and the salary is pitiful – negative to be honest and even worse when factoring in opportunity costs. Your games might get rejected in the marketplace or nobody plays them because of the lack of distribution. The honest answer is ego. The lie that tell everybody else is “I want to create great games for other people to enjoy and there is a need for the types of games I can make.” This lie is true, but I’m not that altrustic in life to make games solely for greater good of mankind.
Artists are inheritently egotistical. Programmers are no different. They want their name attached to something that is THEIRS. This is mine. I created this. See, the critics hate it, but it’s still mine. That’s the honest answer.
Now, why should anybody CARE about Casually Hardcore games? Because you will WANT to play them. Big game studios won’t make satirical games for fear of lawsuits. They will continue to choose the path of the least-offensive. Choosing safe over fun. If Leisure Suit Larry was created today, it would not be funded by a major publisher. Grand Theft Auto III was an exception to my rule, but it was a sequel to a well-known 2D franchise. Postal and Carmeddegon are other exceptions.
Currently, most satirical games are simple one-off Flash title with little depth and longevity. I am for what Kingdom of Loathing has done. Extended gameplay in a not so normal world…
Scripting languages are very useful things to have in a game engine. It allows the developer to offload content-related programming (AI, animation, UIs) to junior programmers and also make the system more dynamic since the developer no longer needs to recompile + redistribute the game after changing one line of AI or UI code.
For example, instead of writing this in C++:
Sprite* s = new Sprite("Character.png");
s->setPos(10,20);
I’d prefer to write this in Lua:
local s = Sprite("Character.png")
s:setPos(10,20)
so that I wouldn’t need to re-compile every time I changed the sprite name or position. The ideal method utilizes a data-driven design with exporter tools, but I’m going to ignore it for now because it is loads more work and requires writing parsers and complex exporters.
Integrating Lua is quite easy and only requires 3 components:
A C++ engine – preferably you know what C++ classes you wish to expose to the scripting language.
For Lua to be able to access C++ classes directly we use tolua++ to create binding code between C++ and Lua. Without tolua++ this binding needs to be coded by hand, but luckily tolua++ can autogenerate it via .pkg files.
So, if I wanted to expose the Sprite class to Lua I would first create a Sprite.pkg – something like this:
Notice how the .pkg is similar to C++ header files. They are exactly C++ header files with private and protected variables and methods removed. You can use any C++ class you wish in .pkg as long as you provide a definition of it somewhere else. In the above example, I use Ogre’s Vector2 – which I would define in another .pkg called OgreVectors.pkg then connect all the packages into one called All.pkg like this:
The output would be Bindings.cpp and Bindings.h which you copy to your game engine’s source and include directories. In your C++ code you write the following:
#include "Bindings.h"
lua_State* lua = lua_open();
tolua_MyGameSprites_open(lua);
int s = luaL_loadfile(lua, "myscript.lua");
if(s == 0)
{
s = lua_pcall(lua, 0, LUA_MULTRET, 0);
}
report_errors(lua, s);
Where report_errors is:
void report_errors(lua_State* lua, int status)
{
if ( status!=0 )
{
std::string s = lua_tostring(lua, -1);
std::cerr << "-- " << s << std::endl;
lua_pop(lua, 1);
}
}
And that's it! You can call any Lua script and use the C++ classes as if they were native in Lua!
There are many alternative scripting languages to Lua, but none as easy to integrate as Lua. The following are used in a variety of games and game engines. I suggest you look at them if you don't like the syntax of Lua or don't use C++ classes extensively.
I’m about to release my latest speech-controlled game – a microphone controlled battleship (on a traditional 10×10 grid). However, I have declared it a disaster before anybody else has even played it.
Unlike Speech Ladder and Rap A-Long, Speech Battleship is next to unplayable because the recognition is so poor when only using letters and numbers as the vocabulary. B/C/D/G are constantly misheard because they all sound alike. And unlike the first two games I mentioned, errors are unacceptable in Speech Battleship due to the nature of the gameplay. A misheard phrase costs a valuable move whereas Speech Ladder will ignore a misheard word as it can’t be played on the crossword board and in Rap A-long a missed word only costs 100 pts – you also need to miss 10 words to fail the song…
What helps is to add words like Alpha, Beta, Gamma into the vocabulary, but players have to remember these “hidden phrases” and use them instead of the simpler (and labeled) letters. Overall, the game can be as fun as the original battleship is . With better sounds and graphics it probably would make a cool mini-game in a commercial title that used speech recognition.
In making Speakeasy, I had great dreams for a fast paced arcade game using speech as the input system but ended up with a slow paced game with word recognition issues. I worked with speech recognition systems before (Annosoft’s), but only to detect phonemes in real-time. I just assumed word recognition was almost as fast and painless – I was wrong – The freely available Microsoft recognizer was wild inconsistently. It’s poor word recognition severely hampered gameplay mechanics causing me to change my original game design.
For example: The Rap A-long mode (aka “Parappa the Rapper”) asks the player to rap along with the Master Chop Chop song. But unlike the PS1 game with a joystick, the speech system can not be relied on to report a word within a finite amount of time. And the recognizer also incorrectly guesses words if forced into an early decision. So the gameplay was changed to allow a large recognition window making it less challenging and slowing the pace quite considerably.
In building a speech-controlled game, I realized:
What can be relied on:
Recognition for a limited vocabulary
80-90% recognition rate.
Pre-installed on all Windows XP systems
What can’t be relied on:
Fast AND accurate recognition
Recognition of multiple words slurred together – like “Kick Punch Block” spoken quickly.
100% accuracy. Even at the highest recognition settinga and clearly spoken words, the system will report false positives.
Because of these limitation, no speech controlled game can be built with the assumption of “fast reliable input” like that of a haptic input device like a mouse or keyboard or joystick. Still, the lure of a speech controlled game is too great for me. It’s weird. It’s funky. It’s different…. and I’m all about different. For future speech controlled game designers, I have a list of pros and cons before you dive in and create a speech-based game:
Pros:
Word/sentence/language oriented
Wide input spectrum (i.e infinite words vs. 6 buttons)
Unique selling point: Not a mouse or keyboard or joystick
“Telling” a computer what to do and having it do it is a great feeling
Players who love their sound of their voice, will love speech games
Cons:
Latency issues
Accuracy issues
Microphones not as common as mouse and keyboard
Noisy backgrounds cause poor recognition
Accents cause poor recognition
Game become language specific
Anyhow, I’m onto my next speech-controlled game: ‘You sunk my Battleship!”
I’m hoping for a public alpha release July 1st. By that time I should have the Maya exporters much improved for people to create new stages/environments.
