Sep 26 2011

REFACTOR

I’ve released Vigilance, I’ve been sick all weekend, I’ve been repainting a subframe (more on that later)… it’s been pretty hectic!

Well.. mostly, I’ve been ill. But while I was ill Vigilance went up on Newgrounds, got reviewed on JIG (“a side-scrolling beat-em-up fighter with an artsy, ironical soul, where you kick unconscious people on the ground… to save them“) and is basically taking over the Internet. Top stuff.

So… work this week! It’s about half Fight Back and half… car maintenance.

I’m currently polybushing my car, which involves removing all the soft bits of rubber and replacing them with cats polyurethane. To do this I need to disassemble my car’s suspension and entire rear axle, then put it all back together with a replacement subframe and brand new bushes by Saturday. I’m currently repainting the new (second hand) subframe, having stripped all the rust off it earlier, and it’s currently sitting in the kitchen with a coat of primer curing. I’ll slap on another coat of primer this evening and a topcoat tomorrow, then start really dismantling stuff and swapping parts over on Thursday/Friday.

Yep. This is our kitchen this week:

Needless to say that’s going to take up a bunch of my time over the next few days – and Elizabeth has the patience of a saint. 😀

In the gaps between Urgent Car Maintenance Task, I’ll be working on Fight Back. There’s a similar level of deconstruction and reassembly involved here! I’m totally overhauling the game’s codebase to support the following:

  • a component-based entity system
  • event-driven, deterministic simulation
  • a totally decoupled renderer
  • framerate independence with interpolation
  • zero allocations per frame

What does all that mean in English?

  • I’ll be able to easily change the graphics. I’d be able to switch to a lower-res version of the game on the fly to support less powerful machines. I’d be able to support a 3D version with Flash Player 11, or support different resolutions on PC, iPhone, iPad, etc.
  • It’ll be able to support networking. All the necessary things would be in place for a robust peer-to-peer or client-server networked multiplayer mode.
  • It’ll run really smoothly on damn near anything. 😀

Now, I’m not guaranteeing I’ll add multiplayer or make it 3D or put out an iPhone version or anything. I just want to keep these options available. All this refactoring will give me a much more solid foundation to press onwards with.

Wish me luck. I’ll try and get enough done that I have screenshots with some of the new graphics by Wednesday. 🙂

4 Comments on “REFACTOR”

  1. A programmer AND a mechanic? wow. Of course its easy when you getting more than 60, all you really have to do is cap it or do more work. But the problem I’m having is that how can you have framerate independence if your framerate is so low that you cannot get 20fps?

  2. Strictly an amateur mechanic, but hey, everyone needs a hobby 🙂

    As far as 20fps is concerned… well, the game might just not work at all on severely underpowered systems! That shouldn’t be a problem on any modern PC though (even netbooks). It’s not a hugely CPU intensive game, except for maybe the AI.

    Framerate independence is about having the game work exactly the same way no matter what framerate it’s running at. This is pretty important for networking. The game logic itself might run at 50Hz or 100Hz, and if the client would be best off rendering at 70fps, I can do that – by interpolating frames wherever necessary. It means that things will move smoothly at 40fps, at 50fps, at 60fps or 85fps… basically whatever framerate would be best for the machine it’s on!

    The goal is that it’ll be deliciously smooth no matter what. I think that’s important – it’s quite a fast-moving game.

  3. I understand. Its just that the article makes it seem that it works at low frame rates. when it fact it online works when you have “extra” processing time between frames. Any game which is “time” based as a opposed to “tick” based will work fine without fancy interpolating frames. The real problem is when you hit 30 frames a second and you still have 60 frames of work to do. At this point it seems like the only solution is to drop unnecessary tasks and skip frames until the machine can manage the work.

  4. Oh, right. Well…

    The actual game logic of most indie games (the ones without physics, at least) would probably run fine on a SNES with a little work. Flash games (for example) are mostly so CPU intensive because all the graphics are done in software, on the CPU, instead of using the GPU.

    That’s why you could probably scale a 60fps Flash game down to rendering at 10fps on a slow machine and still be running updates at 60Hz in the background – the rendering is the expensive part.

    Fight Back shouldn’t have any trouble running smoothly on really low spec machines though. If it does, I do have some potential solutions in mind (like dropping back to the older graphics!).

Comments are closed.