Yacc is meant for writing context-free grammars. On the other hand, natural language like English is very context-heavy and ambiguous. Syntactic validation should be easy enough, but semantic checking could be painful. So make sure to only accept sentences of limited structure, like commands: "look at the treasure chest" (action article proper noun). But remember to support alternative actions that may mean the same thing, like "inspect the treasure", "examine the chest", "look at the red treasure chest". I think that could be a lot of fun.

My alternative suggestion is to make a simple scripting language with a few basic constructs. Parse it into an abstract syntax tree, (optionally) do semantic passes, then interpret/execute the tree. If you only have a month, I suggest keeping the feature set limited. Maybe support just a single number type for variables (one type = no real type-checking required), if statements, while loops, printing to stdout/reading from stdin, functions, maybe allow 1D arrays (and make strings into arrays of numbers). This is not as fun though.

Of course, you could go for something in-depth, but the time-frame sounds kind of tight, and if you get to choose what you're doing, you might as well avoid some work for yourself.

Oh! Maybe a dialogue scripting system for an RPG or something that's laid out sort of like a play?

I've yet to find a cross platform OGL lib set / engine that allows for fake surfaces, in that they're basically an image that I can draw on and supports alpha. Already burned through 5 things so far looking... I really don't see this as an extremely complicated thing to add ><

If the library has support for setting clipping rectangles, you could at least make a wrapper for it without too much work.

Even GM can do some of this to a certain extent. What GM and everything else I've tried so far has failed at is being able to create a transparent fake surface to draw to. Every one of the fake surfaces so far has had a solid background color.

(And if you're wondering why not just use surfaces, it's because I plan on using OGL, and for some odd reason most integrated gfx cards don't support OGL surfaces, and I want to keep my audience wide)

Have you tried just drawing to memory raster (there are plenty of software image libraries that draw to rasters and support alpha), and then later uploading the changes to a texture with glTexSubImage2D? This obviously incurs lame performance penalties if done constantly. But I found that this covered most cases that for which I actually needed off-screen surfaces. I'd make a small alteration to an already loaded texture like a color replacement (actual palette changes and not a silly texture tint like glColor applies) or rotation/flip (the latter can be done directly on the video card easily however with scaling and rotation matrixes) and then refresh the changes when I was done manipulating the software canvas.

I don't know what you've got planned, but the less off-screen software rendering you do, the better the video card can help. If you're reading a lot of pixels back from the screen, there's probably something wrong going on unless you're just dumping it into a texture and applying the effect directly to that.

Of course, there's frame buffers. But yeah, not every graphics card has them. Which is seriously retarded, but still true.

I do backend game engine work with C++, but I write most of my game logic in scripting language frontends, such as Python or Lua. This way I can squeeze the performance out of the things that matter (rendering mostly), and bang out the actual game parts quickly in languages that lend themselves to rapid development. Easy to read, easy to rewrite later, and typically somewhat reusable.

That said, I have no problem coding in C++, but my work-flow often goes several orders of magnitude slower than it'd go with a few scripts, and rewriting old projects tends to always be a moderate undertaking. The main thing for me is really that everything has to have large design assumptions, library dependencies, and ugly workarounds.

I'm not going to yell anyone for using C++, it definitely has its merits, and I still use it! However, I try to avoid writing in it whenever possible, for my own productivity's sake. But do whatever suits you best.

Anyways, who cares. Make games.

It's actually not using any HTML5-specific features. It just uses <div> tags with CSS sprites and an <iframe> for sound effects (presumably with Flash embedded), with some Javascript DOM manipulation to move it all around. Nonetheless, it is very neat. I kept dying on the first level, apparently I can't play this horizontally stretched version of Pac-Man very well. D:

This is their spritesheet:

@Overkill

I was replying to your suggestion to prevent images from drawing until all were drawn. Kind of emphasizing/elaborating/agreeing with your other idea. 

Oh okay. That "durr" smiley made me think there was some sort of large nasty sarcasm associated with that at first. My mistake!

Anyways, I tend to brain-dump when I give solutions to things because there's often a plenty of different alternatives to take, with programming design situations, and they all seem to pop into my head at the same time. Anyways, I think I've done enough derail for now, hehe.

This is actually written with HTML5's canvas, so there is a draw routine.. but my problem is much more basic than that.  I can't seem to understand how the "onload" event should be used.

I've tried the following code, yet the alert never pops up on my page.  What am I doing wrong?

Code:

function createSprite (src) {

this.img = new Image();
this.img.src = src;

this.img.onLoad = function() {
alert("hello");
}
}

I see. Maybe I shouldn't have been so quick to jump to conclusions. I admit I haven't used HTML5 features yet, since they're still relatively new. Eventually I'll sit down and learn how to use the <canvas> tag though.

Anyways, that aside, I think your only problem with that code is that you have written "onLoad" instead of "onload". Remember that Javascript is case-sensitive. Unfortunately, it isn't an error to misspell things here either, since you're setting a property on an object, which if it doesn't exist will be created for you.

If it still doesn't work after correcting the case there, I found this article which talks about order mattering too. I'm not entire sure of this, but I guess if the load occurs very quickly (or the image is in cache), it may not call the onload function if it happens to be set after the image was already fetched.

I think it'd be much easier to, for instance, deny use of the sprite until isLoaded is true. This is kind of the reason for the access[get]/mutate[set] concept.  

Hmm... Much easier than what? That was already one of my suggestions. At least, I thought it was! I made it so the script wouldn't die or completely ignore modifications if it wasn't finished loading, but rather defer them until it was finally possible to display the changes. Perhaps I've miscommunicated that though.

Code:

SpriteObject Draw Function:
    if isLoaded is true
        Allow sprite drawing operations
end function

(I really don't think it's necessary to supply pseudo-code for that, but I've never tried writing it before, so it sounded fun!)

Heh, pseudocode can be fun, but I don't know if it's very accurate here. This is Javascript, so his sprite is fairly likely to not actually have a draw routine, just HTML attributes that get modified by events (possibly with an update/refresh function that changes the element attributes after the sprite gets modified).

Yeah, Chromanoid's right, you can use an onload event which modifies the remaining sprite data when fully loaded (and keeps a flag of whether it is done loading). Just be careful, this may cause problems if you want to use the sprite itself before its data is fully initialized. If you're okay with some attributes not being known right away, like how many frames are in the file, or how big the entire spritesheet is, you should be in the clear. So just make sure not to directly change display-related things, but rather have functions that will make the request, and will be applied when the sprite is in a fully-usable state. Keep details like total frames and the like as internal attributes, which you don't need to know in order to setup animations for the sprite outside of its class. It seems frame width and height are passed into the constructor, so those would be safe to use, on the other hand.

Another way, possibly more elegant, around the onload is to just wait until EVERY sprite has finished loading its image before starting your game (setTimeout and check every sprite's loading status so often -- probably in 1/10ths of a second intervals). This way the game doesn't start until everything's ready. When all sprites are loaded, you know you're ready to rock.

When I made an isometric tile-based game in Javascript, I remember that I actually passed a known width and height in as parameters to my sprite constructors, so I could use info right away. I also preloaded all the game resources when the page was first loaded, which meant there was no real waits on the images either (because there were enough interfaces between the start of the webapp and the actual game part). Not the most elegant though. However, I think I would prefer onload now.

I am not aware of many other solutions to this problem.

My project's repository is handled by tortoiseSVN.

I want to publish the source in an easy to read, documentation style html format. The project is built with VS2005.

What is the easiest way to do this?

A nice tool for this, if you have a PHP-enabled webserver, might be WebSVN (they have a demo tucked away on one of their pages too). I have no experience actually installing or managing this myself, but my university used this for viewing SVN repositories, and the interface is pretty friendly.

I suppose you could also use a public hosting service like Github, which while it IS meant for git repositories can handle SVN as well, either through their import tool (which can read public repos) or through the git-svn tools that come with git. (Really I now prefer Git over SVN, but I suppose this doesn't apply to everyone)

I guess it's fine that many people hurl Flixel and Flashpunk suggestions at him, but it is still very possible and in fact pretty easy to work without this sort of middleware. I made a simple but usable game engine in Actionscript 3 within a couple days of picking it up. Unfortunately got distracted with other things (and Flash Builder beta expired), but I'm just putting it out there.

I have no comment on the Flash IDE, since the last version I used was like... Flash MX? But I tried the Flash Builder 4 Beta, and it seemed pretty neat, since it was basically Eclipse for Actionscript projects. FlashDevelop sounds like it might be okay too. If I were to pick up a Flash project again, I'd probably use mxmlc and a plain code editor like pnotepad, but that's just me.

I managed to play this game until level 42, at which point I gave up, like the title suggested. I think a combination of the flashy colors, motion blur, slight sliding after movement, and difficult timing for the very last part before the exit, kind of caught up to me.

That said, it was a fair deal of fun and had some very neat level designs. Grappling felt a little awkward at times, mainly when you had to gain momentum and launch over obstacles (grrr level 40), but I don't know that there's anything you could do to change that.

The vocoder voices were pretty awesome, I remember lots of "ha ha ha ha" and "good job, robot" as I died over and over.

RLE compression is a must.

You can convert a shit load of tile data (especially empty space) into one tile reference with a frequency indicator next to it. And it's still readable when you look at the XML, more so than the data being uncompressed.

I'd say when you're actually at the point of needing compression, you probably have a large enough map that you aren't editing tiles by hand anymore. Just zlib compress a binary representation of the tilemap to get the size down, and then base64 encode so it can be stored in XML (takes 4/3 times more bytes than the compressed binary blob, but this is pretty minor).

That said, nothing stopping you from having many different compression options!

First off, increpare, you got those backwards! The colon : is syntax sugar, with a:b() being shorthand for a.b(a).

Next, as checking for a global is a table lookup, if you look for 'something.whatever', it is going to try to rawget(_G, 'something.whatever') which will fail (_G['something'] is a table, _G['something']['whatever'] is a function, but _G['something.whatever'] is nil)

In order to check if something.whatever exists by string, you'd need to tokenize on '.' and do table lookup for each piece individually. So 'a.b.c.d.e.f', would search _G for 'a', then with a on the stack, look for 'b' inside of that, then with b on the stack, look for 'c', and so on.



But, I recommend a better solution. First why do you need even to check existence? I'm assuming this is because you want to check if something 'exists' because you're actually referencing this data later in C code and invoking it or something. This is okay, but don't use strings for this purpose. Bad idea.

If the object is nil, it does not exist (any undefined variable is nil), see lua_isnil. Also you can verify Lua value types in C code. The Lua auxiliary library can help you with certain parts of the type checking, like luaL_checkudata. The other parts can be done through various lua_is*(...) checks or by lua_type. You don't need a function_exists helper.

If you need to keep a persistent reference to this data in C which lasts beyond whatever initial call needs this function, you still don't want strings. Instead have them pass their Lua object directly to your C functions, and use the Lua registry (special table located at the stack pseudoindex LUA_REGISTRYINDEX) to store any references you need to keep. See luaL_ref for storing registry entries, luaL_unref for removing them, and lua_rawgeti for retreiving that data back later.



Otherwise, there is no point in coding functions to do an existence check. Inside Lua scripts, the user can already very easily just check with a simple if my.magical.var.from.outer.space then ... end block to see if something exist (since if statements consider both false and nil as logically false, and any other values as logically true). If you need to check explicitly for type in Lua code, there's bad design somewhere, but you can do type(expr) and get a string for what type a value is.

Hope this helps.

EDIT:

I suppose since there are rare cases you actually want to do this for other purposes, here's a Lua implementation of functionExists:

Code:

helper = {}
function helper.resolveName(name)
    local a = _G
    for key in string.gmatch(name, "([^%.]+)(%.?)") do
        print(key)
        if a[key] then
            a = a[key]
        else
            return nil
        end
    end
    return a
end

function helper.functionExists(name)
    return type(helper.resolveName(name)) == 'function'
end

Okay, fair enough. I figured there was a reason like that behind it. I just was sort of annoyed, but that was ultimately because I wasn't pushing enough. And a bigger concern was really that I forgot to pay attention to the turn counter that only appears at the bottom at the start of each turn.

I wonder, is there any way it could appear periodically at the bottom, or somehow popup in more splashy detail when your turn begins? Fire Emblem, Advance Wars, Disgaea and other strategy games tend to pop up a little banner when turns switch. That sort of thing could be a cool effect and communicate the turn information in a more attention-grabbing way. Obviously not a complete necessity, but could be a minor improvement.

Hmm, I think I noticed another little quirk with viewing enemy unit range. If you go to view an enemy's range, you lose the ability to undo your last move. Which can be deadly in certain cases.

I have to say I really hate the fact there are is a turn limit on the levels. The fort level directly after the village defending where you're fighting against lots of Pikemen and Trebuchet was very difficult (for me), and TWICE I had just about won (two guys left) but then I ran out of time. At any rate, overall, it's fun and challenging. Maybe I'll get through the level faster if I can figure out a better strategy than using my Ballista and Crossbowmen to clear the Pikemen and other guys away.

Also, I noticed, if you're viewing an enemy unit's range and you make the camera scroll, the unit range display will disappear. This should probably be fixed.

EDIT: Okay, after I decided to complain, the next try I finished that mission no problem. Heh. Now figuring out the tavern map.

Yes, the official website isn't that helpful under that section (or really, most sections), but it is supported directly by the library. It is in their doc wiki about SDL 1.2 (look at the API under the Video section): http://www.libsdl.org/cgi/docwiki.cgi/SDL_API

Also, I just googled "SDL OpenGL" and found this: http://gpwiki.org/index.php/SDL:Tutorials:Using_SDL_with_OpenGL

The thing is SDL (or any library, really) doesn't need to provide much. You make a call to setup the video mode with SDL_GL_SetAttribute and then SDL_SetVideoMode (with SDL_OPENGL set), then you use regular GL calls after that. When you want to refresh the screen, you call SDL_GL_SwapBuffers.

trying to do some lowish level sound processing, and getting tangled up in char*s

That's what string.h is for.

Unless the char* aren't actually strings, but rather, byte arrays representing a sound buffer. I guess string.h would still give you memcpy and memset though.

Also, AFAIK SDL is limited to software rendering which is definitely not ideal. I think we're at the point where most even integrated graphics chips will support oGL.

OpenGL is definitely supported by SDL. I saw people say SDL only supports software rendering in another thread too, but it's not true. It does support an OpenGL drawing mode. Though there are a couple downsides OpenGL in SDL, mainly that any time you resize the window or adjust the resolution, it nukes your GL context. You can get around this by not allowing windows to be resized, but it's not entirely ideal.

That said, I've been considering switching my engine to SMFL. It seems interesting, and I've read a little about it.

Keep it simple. Use a file called todo.txt, and put it in your repository. Bulleted lists with optional little text markers like [DONE], [!], [BUG], in front of the text and after the bullet. Group by person.

Example todo.txt:

Andy
* Come up with a title.
* Complete forest town map.
* [!] Speed up textboxes.
* [!] Add item menu.
* [BUG] You get stuck in walls occasionally. Find out why.

Barf
* Come up with dialog for first meeting the player rival.
* Clean up intro text.
* Make music.

Anyways. you get the idea.

EDIT:

I've used Tiddlywiki at certain points too, and it was pretty fun to work with, very lightweight. Never tried the server edition out, however. I'd imagine it wouldn't be as enjoyable to use, since saving would actually require transfer time.

I once tried MediaWiki, but it had too much bulk. It seems great for larger projects where you're hosting articles or code documentation, though. But not for something as simple as a todo list.

Google Docs and Google Wave are both too buggy and have crappy text refresh rates. Google Wave broke several times while I was trying to work on a wave, and I'd have to refresh the page to fix it. Google Docs would occasionally revert changes while I was working by myself, and the formatting is colossally screwy, and it was hell when multiple people were editing at the same time (which it is apparently supposed to support), since it'd sometimes only partially update or obliterate another person's changes due to buggy diff-checking. I really don't recommend either.

I wonder, who will release the source code here?

My unfinished/unreleased game engine, Plum (which I've only developed under Windows -- since my Linux partition died a while ago and I don't have a Mac), is BSD licensed with source available here: http://github.com/Bananattack/Plum

The game logic for my thing is in Lua. I might pack it in a renamed zip file, to bundle things in a tidy little package, but that's about it. I've never really bothered hiding coded for my games when I'm giving them out for free, since it's not like people are going to really "steal" anything by looking at the source. For games from jams or compos, who really cares either way.