[Real life examples:]

After many experiments myself, I settled on the following design which has been working amazingly well for me:

Components are nothing but data.  The only methods they have are convenience methods to operate on that data.

Entities are a collection of components.  They only have an attach() and a retrieve() method to manage components and nothing more.

Systems inspect entities as they are created and destroyed, and if they contain components that the system is interested in, they add or remove it from their own internal operating list.

World is a collection of systems to operate on the data.

Real life examples:
The PhysicsSystem loops through all entities with a PositionComponent and a VelocityComponent and updates the position from the velocity.

The VehicleSystem loops through all entities with a VehicleComponent and VelocityComponent and updates the data based on the parameters set about by the VehicleComponent (current speed vs max speed, current turning direction, etc.)

The PlayerDrivingSystem loops through all entities with a PlayerDrivingComponent, sees if the player is currently driving a vehicle, and if so, grabs its VehicleComponent and begins operating on the data (setting the current speed, current turning direction) based on user input.

Advantages

Order of operations is clearly defined by the the order systems are added to the world.  This is a real nightmare when components define their own behaviour in other designs.

Adding a new system doesn't affect any other system or entity.  Want to add a minimap?  Create a MinimapSystem and loop through all entities with a position and team and draw them on the minimap in colour coded fashion with ease.

With everything localized, enabling or disable functionality couldn't be easier.  Want to debug draw entity hitboxes?  Create a HitboxDrawingSystem, it'll loop through all the entities with a HitboxComponent and draw it.  Enable or disable it at run time.

Rapid prototyping is a huge win.  I'm a Flash game developer and make 1-2 games a month some times.  I can throw on a basic PlaceholderDisplayComponent and build up a prototype in a day, then simply swap out the PlaceholderDisplayComponent for a SpriteSheetDisplayComponent when I get the final art and make next to no other code changes to the entities.

What kind of system do you have?

A. Components are attached to the entity and run the logic.

B. Components are purely data and systems run the logic.

I'm a Flash game developer looking to hook up with any artists who have a jump start on a project, or are struggling with their current team, who are interested in pursuing a sponsorship via FGL.  I'm Market Level 7 there.

I'm up for any project except those using lofi pixel art (sponsors aren't interested).  I'm mostly interested in collaborating but am open to flat fee programming work too if you want me hands off.

Get in touch.

I find tools development both incredibly fascinating and extremely dull.  However, it's fun to see what tools we create to solve our specific problems.

Since making the switch to sprite sheets I've used a a mishmash of automatic generation and hand editing XML files to handle the origin / registration points and animations.  After a few projects of that (garbage), I've decided to take the time to make a GUI to make it faster and easier.

Alignment / origin:



Animations:




What custom tools have you made / do you use?

This all looks insanely over-engineered and like it's the product of not shipping any games and blaming it on tech, or just never getting to the "make game" part. If you haven't made a game start to finish yet, do that (and do it twice more at least).

The engine we're building alongside Crimson, the engine behind KAG (and partly in Crimson as well) has this in the forefront of it's mind the whole time: "how can this code be made faster to write?". If it takes 100 lines of mostly meaningless boilerplate with some useful constructor information buried in there to create a trivial object... that's shit.

Get back to basics, make sure you can build small games in it quickly. If you can't do that, there's no way you'll be able to make large things in it quickly either.

Couldn't agree more.  I actually write my code backwards now a days, starting with writing an example of how I want to use the code and then go back and conjure up the systems to make it happen.

Catchy title!

What exactly did he get his degree in? ;-)

Thanks!

He's actually a veterinarian that does particle physics and engineering on the side.

A combination of "real life" distractions and feature creep has knocked us off our timeline by a week but we're wrapping it up now.  We also picked a name for the game.

Here's the intro comic where you can see why the doctor turned evil:



And here he is scheming away in his laboratory researching upgrades to his ship:

Congratulations on finishing it.  Hope your hard work pays off.

I'm not familiar with Stencyl, but it sounds like its rotation system range is 0 to 180 then -180 back down to -0?

If so, convert it 0-360 with something like this:  degrees = ((rotation % 360) + 360) % 360;

Then add 22.5 degrees and divide by 45 to get your direction: direction = (degrees + 22.5) / 45;

Finally direction = 0 should be east, direction = 1 should be south east and so on.

I dont see why not. It's really just a layer on top of a wrapper for opengl,openal etc... I'd say it's as safe as that.

Tossing between Unity and MonoGame now.  Unity seems much easier to go cross platform with but more difficult to get 2D to work with (which I find personally hilarious from a Murphy's Law point of view).

Thanks for your input.

Here's some folks gettin' nice and crispy:


Really happy with how the electrocution animation shaped up.  Need to add in the security guard and soldier now so things can start fighting back.  Monday or Tuesday is looking more reasonable at this point.

Oh yes. Far better now.

Good to hear.

Really unique sounding concept and the art is shaping up nicely.

Some progress on the art:


Victims on the street (civilian, security, army and a tank) are currently being animated.  We're hoping they can be finished tonight and implemented tomorrow.  Coding wise, I only have the upgrade shop and various other menus to finish.  It's basically a race against time for the art at this point if we're going to hit our goal by finished on Sunday.

Well, four days left. Seems rather simple, but I hope you guys get this done. I quite like the scientist. Maybe fix his mouth though. I can't tell if those are his teeth or his moustache.

Hopefully the smile is a bit cleaner now.  Thanks for the support.

+1 to background parallax.

Making solid progress.  Keep it up.

[Dr. Flammenwerfer]

Dr. Flammenwerfer

Description
Suffering from some burn out working on our main project, my co-conspirator and I are going to whip up a quick project to resuscitate our creative mojo.

Setup:  A young scientist competes in his very first science fair.  Unfortunately, his experiment backfires and explodes, leaving him covered in soot.  The crowd explodes in uproarious laughter and relentless pointing.  Scorned, the young scientist begins plotting his revenge and toils away the years constructing a giant airship complete with death ray.

Gameplay:  You control the (now evil) scientist in the aforementioned airship, shooting civilians, security officials and eventually army personnel.  Collect research tokens from their charred corpses to upgrade your ship while you make your way to the science fair to have your revenge.

Deadline:  We plan to have this game fully complete and polished by March 10th.  Fingers crossed!

Team

Game Design and Programming
A. Scott McCallum (www.grozzler.com)

Art
Kandi Maciejewski (www.artbykandles.com)

Audio
John Hughes (www.twune.com)

Media

Prototype gameplay:


Concept image of the scientist in his turret:

Hey all,

I currently eke out a living making Flash games.  As my skills continuously refine as a game designer, I'm evaluating my future growth as a full-time indie.  I'd like to begin building a code base to springboard from when I finally detach from the sponsorship model in a year or so.

I'm mostly interested in 2D games and I want my games to be cross platform for both altruistic and financial reasons.  I'm well versed in many programming languages but I strongly prefer C#.

So is MonoGame a safe bet for the foreseeable 3-5 year future?  Is cross platform development really as simple as everyone says?  Is Unity a safer bet, even with my focus being 2D?

I'm open to other options too, so please share your experience.

Hey all,

I just released my latest game, Fractured, on Kongregate.  It can be pretty hard to get out of judgment now a days, so I'd appreciate it if you'd play and give it an honest rating.

I'm pretty proud of this game.  It features a mechanic that has never been seen before.  You have to navigate the world by viewing it through cracked "fractures" (get it!) that are re-arranged all around the screen.  This gets quite a bit more difficult as the fractures become smaller or rotated.

Here's a screenshot of the first level to give you an idea:


http://www.kongregate.com/games/GroZZleR/fractured

I'm also up for any questions you might have about flash development, sponsorships, etc.

Thanks for looking.

Pretty busy weekend so I haven't got as much done as I would have liked.

I added the logic for the free for all and team deathmatch game modes.  The AI chases and strafes hostile team members while also keeping an eye out for weapon / health crates to pick up.  Right now target acquisition is a simple "who is closest" type behaviour, so I need to add some weights to the decision process.  A wounded AI should prefer to go after a health crate (if within a reasonable distance) rather than chasing down a random target.  That's my next task.

Visually I added the backgrounds to the game.  The jets really pop out now.  Explosions and projectiles remain programmer art.

I spent today working on the weapons / projectiles for the game.  There's going to be six different weapon systems available:  the default slow machine gun, a much faster machine gun, a spread gun a la Contra, a plasma cannon, a homing missile launcher and deployable mines.  To obtain them, you have to fly over special weapon crates that spawn at specific points in the level.  If I get the AI right, I'm hoping a lot of the strategy of the game will centre around controlling weapon spawn points like Quake.

Additionally, I added trails to the jets and they're coloured coded to your team.  I was doing it entirely for aesthetics but found it really helps with target identification, so I'm very pleased with the result.

Projectile / crate artwork is programmer art still being finalized.  Tomorrow I'll implement the game rules.

[Aces]

Aces

Description

Aces is a sidescrolling arena shooter with fighter jets.  And hats.  Lots of hats.  I'll be posting about its development over the next week and a half as it goes from a basic prototype to a completely finished product ready for sponsorship on FGL.

Progress Overview

03 January, 2013

A playable prototype with limited game rules is up and running.  Over the next few days, game rules such as free for all, team deathmatch and capture the flag will be added.

Team

Game Design and Programming
A. Scott McCallum (www.grozzler.com)

Art
Kandi Maciejewski (www.artbykandles.com)

Audio
John Hughes (www.twune.com)

Media

Prototype screenshot: