So when you say that programs need to be runnable from an exe file, is it okay if their resources aren't embedded into the exe, but rather in a folder with the executable? (Otherwise, I guess I can spend some time adding the ability to load exe-embedded zips to Plum. But I'd prefer not to ;_;)

Saw the warning message today, and figured it's time for a status update! I am working on my game, I just have been pretty quiet because, well, it's not that graphically amazing yet.

Title screen (title letters bounce and waves move):


Veeeeeeeeeerrrry WIP, preview of bubble effects:


Anyways, I'm soon to work on the simple shooting mechanics and some sharks to blast. Shark and jellyfish sprites should be fun. Still deciding how much I want to deviate from the original game, since it was really really boring. Was thinking about making it a more frantic one-screen shooter, where you're constantly blasting sharks, collecting treasures and dodging sea creatures. Considering adding bosses at ends of levels. Really depends on how much time there is, but there will at bare minimum be something more playable than the original.

Anyways, don't remove me from the list!

Oh! And does anyone want to do the music for this? The original theme is pretty awful, so I don't know how well it can be remixed, but I'm sure with a lot of creative expansion it can be a completely different theme doesn't suck.

Prepare for a rockin' Sharks remake.

Finite state machines can be good for simple cases of artificial intelligence and input parsing/recognizing.

Finite state machines based on their current state and input, decide which state to go to next (using a transition function), with a set of final states. Deterministic FSMs can typically be encoded as simple lookup tables or switch statements in code. But actually, FSMs themselves aren't that useful outside of input recognization, since by their formal definition they can only accept or reject input.

Finite state tranducers factor in an action to be performed with the state machine. Moore machines perform an action depending only on current state. Mealy machines perform an action depending on transition taken. These are more useful but are still limited in what can be done with them.

I think a lot of people blur many different stated-based things into finite state machines, but FSMs are only a small subset of state-based things you can do.

Anyways, I think that using finite state machines and tranducers are not useful for everything. In fact, for game entities it is probably rubbish, since these events (jump, run, shoot) are happening simultaneously, continuously over several frames, and with a few exceptions, independently of one another in terms of player control. Only states that are related but are mutually exclusive should be really grouped, for instance, land/jumping/falling state, or running vs walking, or possible player-facing directions (usually just left or right in side-scrollers, udlr (with diagonals possibly) in RPGs/topdown). You will actually want plenty of lower-level variables for each exclusive state (for example, determining exactly how far into a jump you are, the vertical speed, animation related timings, and the list goes on, blah blah every state could have some unique variables unshared by other states). None of these should actually be states in the finite state machine sense. I know I personally don't use finite state machines to encode real-time platformer scenarios.

However, controllers that influence a non-player entity's action could use a state-based system of sorts, probably along the lines of a Mealy Machine could be good for artificial intelligence. (Where the agent controls actions that affect their state, but does not directly affect their state) But typically with real-timed games, you need to put variable timing between each transition, and allow for interruption and other things. By this point, these are strictly not finite state machines, while still relying on state. But here this is useful.

Game menus can sometimes be close to FSMs, but usually aren't.

I tried to keep this quick, hopefully it's of some use to someone and I haven't skimmed on anything too vital. It's possible there are plenty of counterexamples to what I've stated, I've just went with some policies on how I generally approach this whole game-state thing.

Really, it entirely depends on what sort of game you're making. Games with a more static environment or fixed time steps (ex. turn-based RPGs) can get away with the simpler state-based systems. The more real-time, the more crap you need to accommodate for -- it will involve states to a degree, but there are now plenty of underlying variables.

Generally, language creation is a bad idea. If you can avoid writing a parser from scratch or reinventing a language, it's probably good for your sanity. However, sometimes you can't shake the urges and want to get your hands dirty with parsing.

For language building, I would seriously consider ANTLR. It generates LL(*) parsers, from a unified grammar that can contain both nonterminal and terminal definitions, and it has built-in semantics for building abstract syntax trees (with markers to omit or promote nodes in the tree as needed) without having to put in special rule user-code. It also has a tree parser built-in, which might be handy. Another nice thing is with ANTLR, you can actually specify rules for lists-of-things as iterative "regular expression"-like constructs, instead of writing recursive grammar rules, making it a little less time consuming to write complicated things.

Alternatively, you COULD use Lex and Yacc, but it is painful to write and debug, and does not come with a tree parser (though you could hook in treecc or similar).



I'd discourage writing a compiler completely from scratch without existing tools, but it's doable. First write a lexical scanner to convert input into tokens, then feed those to your syntax parser (probably of recursive-descent LL family, since they're much simpler to code by hand). Should basically look ahead at a sequence of tokens (maybe LL(1)) and decide which branch of your parser to follow or terminate based on your current state.

If you compute first and follow sets of a formal BNF notation you could ensure your grammar doesn't have ambiguities, but these are moderately painful.


If you're doing this from a game's built-in editor and selecting symbols from a menu instead of actually having the user type things in, you could just generate the AST or opcodes directly, avoiding parsing entirely.

Sorry. Unfortunately, this is not revolutionary, nor particularly "dynamic". You've simply split a set of larger pseudo-tiles into smaller concrete pieces. This idea has been around for a while now.

However, a tile layout like that is only effective if your tiles don't demand good transitions or variety. If you happened to have an edge that was more than a single tile long this would fall apart pretty quickly, and you've also effectively killed the amount of transition you can fit at each corner. Really, you couldn't necessarily get away with this method of packing if you upped the tile fidelity.

Secondly, I don't see how this saves you hours for your particular tiles. You could have VERY quickly copy-pasted and rotated things, and for a negligible memory cost saved time making a system to automatically calculate the tiles for you.



If you wanted to be truly lazy, and you are set on using that art style, you could use a few inferences: your bricks are a really small repeated pattern that doesn't need any variation or edge-specific coloring, the frame is very simple and does not change depending on direction of corner.

Your tileset should just separate things into two layers: the brick layer, and frame layer. The brick could be your simple 8x8 or 16x16 pattern. To save on number of frame pieces, you need to draw, just make three: the outer corner, the inner corner, and an edge. Now rotate them to get the other edges in-engine (either pre-rotated or runtime decided). You're down to just 4 tiles!

I intend to 3-clause BSD license the source I release with my finished freeware games, since I honestly don't care if someone else wants to use my code in a project of their own, and adapt or sell products with my code in it.

However, I would probably make it so there was a restrictive license on all game assets used by the code, requiring explicit permission to reuse any of the art, music, or maps in a derivative work.

This essentially meets my agenda. Do whatever you want with my codebase, but keep this license saying that you based your code off of mine, I'm not responsible if it blows up, and I am not promoting your project. You must tell me if you plan on reusing any original game content unless it's used specifically in a port of the game.

Done.

This will keep the option for people to bring the game to newer platforms, or make completely new games with my engine, and keep it away (unlikely anyways) from fan-remakes or commercial games with my assets unless I give them permission.

Dumping my thoughts on this.

I think it's perfectly okay to fail. If you don't fail at something, how can you improve? It's almost impossible to complete the first few game projects you've ever conceived. However, the horrible odds don't stop people, since surprisingly a lot of developers come back after their initial disappointment with a better, more polished idea.

In the case of released work, I think it's perfectly okay to fail at that point too. If you release something, you are at least a moderate success. It takes committment to actually finish the ideas you've started, especially when you start to notice flaws and discouraging dull moments along the way. A finished, crappy game is more valuable than that abandoned game project with awesome ideas you've had for years. Both are failures, but a completed failure can be appreciated more.

The only thing that annoys me is when authors don't act humbly about their work, and ignore criticism (even positive criticism) from other people. This sort of arrogance is what rubs people the wrong way.

And of course, most of what I said does not apply to business. In that case early feedback is critical. I'd imagine if a person or company wants to ensure sales, they should at least get some testers outside of the development.

I got one of these after seeing my twitter feed flooded with peoples' answers to questions. Neat idea, but I can see getting bored of it fast. http://www.formspring.me/Bananattack

Wikipedia says Alex McQueen was a famous fashion designer. Are you sure this was the same person?

I also like Audiere. I'm using it in my game-engine-in-progress right now. It supported pretty much every format I need, and provided reliable xm and it module playback through DUMB. Before that, I was using FMOD Ex, but I decided I wanted something free to use in any kind of project, and something that didn't sound like stabbing ear pain when listening to certain xm modules with effects.

It was even really simple to hook plugins that would read from a custom file wrapper, I just implemented a class that extended their base file type. This meant that adding in a packfile-aware player without having to create temporary files on disk was possible.

I also liked that, if I wanted to, I could actually statically link audiere (although dynamic linking is entirely possible), making there be no need for any extra DLLs with my engine. The actual benefit of this is pretty minimal, but hey, it was doable.

The doxygen documentation was a little opaque at times though, and I found myself occasionally digging through the library source instead of reading the docs. I think that the documentation and website need to be more frequently updated to make more people aware of Audiere. I'm sure that a tutorial on it would go a long way, too. I'd probably be able to help with something like that if I weren't tremendously busy with school.

Anyways, that said, I hear SDL_Mixer can do a decent job too, in a low-level sort of way.

I have no real opinion on OpenAL, but not particularly liking OpenGL's API (but not like I have a choice for THAT one as much), I figured a similar name meant similarly awful ideas of how you should set up audio samples on a machine.

This was a fun little sandbox to play around with. The colorful flowers, trees and bees made it a fun experience. It was a lot of fun building up huge forests, though I was disappointed that eventually trees started disappearing ;_;. It was an entertaining diversion for about 10 minutes, though.

I could easily see a sandbox thing like this becoming a game, if you had to build up a forest with some sort of goal size. There could be fires and baddies you had to rain on to keep your progress from being lost (it would alert you or something). And you could have different levels with varied sky and vegetation themes! And maybe switch the background music (which was well done, by the way) based on amount of progress.

Of course, maybe it isn't your intent to make this into a larger experience down the road. Either way, it was fun, but at the moment it's not very lasting.

Nonetheless, good job.

Hey, it's 4mat! At first I wasn't sure who you were, but then I heard "I breathe in black and white" in your trailer, and made the connection.

This looks really cool. Though it looks like 3D glasses are mandatory to not be overwhelmed by the amount of things on screen :D

Regardless, looking good so far.

Well, it took a while for Leech Tool to work (a couple hours -- would have been faster if it could do multiple wgets at a time), but I think that it managed to download *most* of the resources. Idea soon, possibly.

So yeah, I entered in part one with some cheesy pixel art. Now I'm back, this time as a programmer. Time to bust out the game juice.

I might need to make a tool to better organize the current mess of artwork and music into a more coherent thing. Something so I can actually see what resources there are to choose from without having to scroll across tons of pictures and music resources.

So I figured this was the right to place to 'advertise' this.

There's a game contest hosted by RPGMaker.net, called "Game Chill 2009".

http://rpgmaker.net/events/game_chill_2009/

You can also jump on IRC. Go to #compo on irc.esper.net.

It goes from December 11th 12:00 AM - December 28th 11:59 GMT. Yeaaaah, blah blah, the time overlaps Assemblee, among other contests. I'm planning on entering both. So you can potentially show how much better you are at making games than me, in multiple places!

The theme will be decided when the contest starts. You can use whatever engine you want, and, no, you don't need to make an RPG.

The entries are judged at the end, no prizes, just for fun.

Oh, and the contest also needs judges, so say something if you're interested.

I just wanted to leave a comment to say your art makes me happy.

(also what happened to Super Banana Nanaba)

Any chance you can make some walk and attack animations for the birdman? Don't need to be super fluid animations, but something would be nice.

Just wanted to bump to say that the server is back online now. So my stuff should have reappeared. Yep.

About that.

I've been informed that the motherboard on the server they were hosted on blew up. Apparently the server will be revived after the weekend, when the admin can get into the colohost facility.

So in the meantime all my stuff is down. Please be patient! ;_;

Also, mang, school is kicking my butt. If I didn't have all these assignments to do, I'd have time to make real games! If get bored and doodle in class sometime, or I magically get a ton more free time, I'll add more here!

Thanks for the comments everyone!

reminds me of G.I Joe for Atari VCS

Oh man, that's cool. I don't think I played ever played that game. That snake has some crazy waveyness to it.

To be honest, I was actually originally thinking of Megaman 2, the Air Man stage with the red robohead things. And I decided near the end, ehhh, I'll add a tower support so I don't have to bother drawing propellors. And then I was just sort of like, why not make it a shmup scene instead of sidescroller scene?

Anyways.

By the way, nevermind what I said about not using your assets in the second part, Derek said there's no problem with that.

Don't worry. If I *do* use any of my art, I will only use like one or two pieces. I plan on using as much other-people-stuff as possible. I'd think it'd be cheap if I *only* used my art, no doubt about that.

OVK! Nice graphix.

I plan to meet you in battle in part 2 of this as well. WHERE'S MOLASSES MEOW NOW.

GET READY FOR BATTLE.