Forums » Help » Structuring [impactjs] games

Some people have put together some really impressive impactjs games and demos. I was wondering if there is any type of recommended resource that would help explain a good way to sanely structure a full game. Games are complicated beasts with a lot of moving parts. An open source impactjs game I could look at would be stellar. A pertinent article in a different language would be great too.

I suppose the question I asked is pretty broad, but I'm hoping any sort of resources or advice will be pretty broad too.

In my opinion, there's really no "right" or "best" way to structure a game. Yes, there are some architectural patterns you can follow, and books like Game Coding Complete outline how you can follow a traditional MVC pattern. Regardless, most game code bases are anything but sane. They're downright ugly and horrid! But, that's because game development is an elitist form of programming, or better put, damn hard =)

That said, there are some open source bootstrap projects you can use, which gives you a fairly good skeleton project that you can start with and build on. One of the better ones I've recently seen is the one by Jesse Freeman (author of Building HTML5 Games with ImpactJS).

https://github.com/gamecook/super-jetroid-starter-kit

If you search more through GitHub, you'll find other ImpactJS projects as well that you can look at. Once you've started developing your own games though, you'll quickly learn what works best for you.

It will depend on each game, but for what it's worth you can view my source here. It's rather messy as these were rush jobs for One Game a Month, however:

https://github.com/drakonka/Alien-Tree
https://github.com/drakonka/Promiscuous-Flea
https://github.com/drakonka/My-Mind-Is-Going

Awesome, thanks for the links! Where I typically trip up in terms of sane structure is juggling all of the minutia. It seems no matter how much I plan, there's always "some THING" that needs to be shoe horned in (some delay on an animation, a weapon that needs to be reworked in a different way that cascades a mess through the code, etc). I'd save a lot of time and sanity if I mimicked people who have done it before me and have done it better :)

I totally know what you mean.

I get paralyzed worrying that the choices I'm making in my codebase today are going to screw me in the future and that there should be some best practices out there to help steer me through the swamp.

I tend to get fascinated by abstract code architecture instead of working on my game. "Wouldn't it be really elegant if this entity called this method on this other object that sent a message through this pipe that..." Meanwhile, I don't have a game.

So, besides the confessional, I would say this:

* You&039;ll probably have multiple #ig.Game classes. One for the title screen, one for the actual game part of the game, if you know what I mean.
* You&039;ll probably end up with multiple #ig.Entity#s per entity in your game. You'll have one logical player, but the player is represented by the #EntityPlayer, EntityPlayerSwimming, EntityPlayerClimbing, etc. It helps keep the code and behaviors clean and separate, helps to organize your thoughts.
* Don&039;t store state on your entities. What's your player's current score? If you store it in the #EntityPlayer then you&039;ll run into problems when you #kill that entity or swap it out for the EntityPlayerTransformIntoWolf or whatever.
* Be careful about storing state in your ig.Game instances. If you ever find yourself needing to swap the game instance you'll have painted yourself into a corner. Then again, maybe you won't.

These are things that are bothering me right now in my RPGish thing:

* How to code for a player moving between levels. I can&039;t directly add the #EntityPlayer in Weltmeister if the player is supposed to show up in different places.
* How to restore state if the player dies and respawns somewhere else. What if they picked up some object? What if they unlocked a door?

Sorry for the ramble.

Quote from drhayes
I totally know what you mean.

I get paralyzed worrying that the choices I'm making in my codebase today are going to screw me in the future and that there should be some best practices out there to help steer me through the swamp.

I tend to get fascinated by abstract code architecture instead of working on my game. "Wouldn't it be really elegant if this entity called this method on this other object that sent a message through this pipe that..." Meanwhile, I don't have a game.

Yep, I was (and probably still am to an extent) the same way.

Very sound advice though drhayes. A big headache will always be storing the state of your application in the wrong place.

Ahh, the good old "loadmapdeferred" doesn't mesh with dynamic entity starting locations problem! The way I've handled it in the past is that I put an entity in weiltmeister that in turn spawns the dynamic entities in the right spots with the right values.

Thanks for the structure tips! Those are things I definitely haven't been doing, and might explain some of my issues with swapping maps and modes.

I've been making state machines out of the main game class, and changing the state to an appropriate value when loading different maps. In a sense I may have been using maps the way I probably should be using the ig.game class. I do try to keep state out of my entities as much as possible, but it always finds a way to work its way in there >_<

Again, great links and advice everybody!

@skel1: Yup, that&039;s what I'm doing. I have a few #EntitySpawnPlayer around. When the map is loaded they check to see if they are named as the ig.game.currentSpawn (or something) and, if they are, spawn the EntityPlayer.

The level exits set the name of their connected spawn point when the player uses them. Works great, but involves some manual bookkeeping.

As some others have said, it really just varies too much from game to game to have one "right way", and maybe even to have a "good way" for every case.

One of the things I love about Impact is that it thoroughly uses OOP, so we can have separate class files (entities, etc.). Not a ton of JS game engines have that since JS doesn't include a great way to include external files inside the code itself. Usually I just try to keep my classes as lean and as focused on their own business as possible, try to keep as much logic out of the main file as possible (of course that can't be 100%), and then simply use folders inside my game folder to keep things from cluttering up. For small games, I usually just have a few, breaking them down into enemies, player entities, etc. For larger projects, I would take that system and add another level of grouping on top of it. Perhaps group them by level, game world region or something like that. My rule of thumb is that if I am having more than 5 or 6 classes in a single folder, it is likely getting cluttered and I need another level of organization.

That is pretty low-tech organization, but it works for me. I can't really see adding in another library or framework just for organization. I think really where disorganization will kill you is not in the pile of files, but in close coupling of entities (making entities depend on each other too much, such as allowing an entity to tinker with things it shouldn't in another entity to make the coding easier). This causes a single error to ripple through your project like a tsunami. Of course, that is an issue with all software development, and not unique to games.

Just set up an organization structure and strategy at the beginning of a project and stick to it and it should be fine. It only becomes a thorn when no thought at all is given to it.

Do you guys have any opinions on that HTML5 game development book Dom has listed? Is it very in depth, or is it more geared towards newish programmers?