NCFC Forums
Hello There, Guest! (LoginRegister) · Back to NCFC
Search · Member List · Calendar · HelpUser CP
FORUMS



Post Reply 
Notes on Game Optimization.
KiddoCabbusses Offline
Head Director

Posts: 259
Joined: Sep 2011
Post: #1
Notes on Game Optimization.
I think this year's NCFC was pretty good at highlighting how the optimization of game code or a game engine can affect a game's playablility.

Comparing last year's Livestream to this year's Livestream should show you what I mean. Last year

1) I had a pretty good Windows 7 comp
2) There weren't many examples of games that touted optimized code as a feature.

You may have remembered that even last year, MMF, Hello Engine and RPG Maker XP games ran fairly slowly on my computer. Immortal Sword in particular ran slow, back then...

This year:

1) I have a significantly worse Windows XP comp, BUT...
2) At least one game got a new engine specifically for code optimization purposes

In spite of my worse computer, Fire Emblem: Immortal Sword ran much better because of it's switch from RPG Maker XP to Windows XNA. It became -the- example of how code optimization can make your fangame drastically more accessible than it previously was.

Unfortunately, I'm not much a fangame coder myself, but I figured I'd make this thread anyway to highlight this as people get ready for next year's NCFC.

Code optimization is good for your fangames. You don't want to see them running slow as mollasses on the Livestream. My general belief is that a game that looks like a Game Boy Advance or SNES game has little excuse for having loads of slowdown on computers significantly more powerful than either.

Immortal Sword changed it's very engine core for optimization purposes, but I suppose for many others that's not as easily feasible. As some broad strokes to start the thread off, I'll toss some typical "optimization" ideas here;

1) Remove any excess that isn't part of the game from the source before building.
2) Don't force a game to try to run at a much higher res than it actually is.
3) Don't use more resolution than is needed. (Hi-res is pointless if you're gonna use tiny SNES sprites, for example)
4) Don't overdo encryption/compression or overuse file formats reliant on these.
5) Give the user options to turn off CPU-consuming special effects, such as lighting and shaders.
6) Code your objects to not render/not store/be destroyed when not in use (Please stop haviing the entire game stored in my RAM, plz. ;-;)
7) Try running your game on a lower-end computer to spot for optimization issues beforehand. (For the folks who are saying I'm the first person they've seen had the game run slow on)
8) See how trying to broadcast/Livestream your game affects the speed of your game (For games that run fine... until I turn FMLE and SCFH-DSF on.)
9) Try to work using a game engine that is well-optimized.
10) Find optimization guides specific to the game engine you use and apply them to your game.

Any further discussion on this is appreciated. I hope the games next year run even better. :)
11-17-2012 04:12 PM
Find all posts by this user Quote this message in a reply
onpon4 Offline
Member

Posts: 97
Joined: Oct 2011
Post: #2
RE: Notes on Game Optimization.
(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  As some broad strokes to start the thread off, I'll toss some typical "optimization" ideas here;

Just want to respond to some of these.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  1) Remove any excess that isn't part of the game from the source before building.

The only code you would remove in this case is comments, and compilers (both machine code and bytecode) remove these automatically (or rather, don't include them). In any case, it has no effect on speed; the only effect is on the size of the executable, and at that not by very much.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  2) Don't force a game to try to run at a much higher res than it actually is.
3) Don't use more resolution than is needed. (Hi-res is pointless if you're gonna use tiny SNES sprites, for example)

Resolution can have an effect on speed, but not as much as you'd think, and fullscreen even when stretching can allow the game to run much faster by allowing hardware surfaces (passing the rendering off to the GPU). It's really not worth worrying about.

About #3: the main reason to use sprites at their actual size is storage space and RAM use, not speed.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  4) Don't overdo encryption/compression or overuse file formats reliant on these.

Again, this can hypothetically slow things down, but it is not usually the case. When building The Ur-Quan Masters for the Pandora, someone used this logic and included the graphics uncompressed, but my later build (which includes them compressed) does not run any slower.

Actually, I don't think that resources like graphics are left compressed when stored in RAM, which would mean only startup time or level loading time (depending on how the resources are handled) is affected by compression, though I'm not sure.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  5) Give the user options to turn off CPU-consuming special effects, such as lighting and shaders.

This is actually good advice, but far better advice is to not use such dynamically-applied effects very much at all. If they have such an impact, pre-rendering them would be a good idea.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  9) Try to work using a game engine that is well-optimized.

I can't say I'm aware of any engines that are particularly bad at this. Even Game Maker will run quite well if you use it right.

Sure, some things are faster than others, but assembly code is the fastest possibility, and of course no fangamer would want to use that. As long as the game you develop runs at full speed on the platforms it's likely going to run on, it's fine.

(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  10) Find optimization guides specific to the game engine you use and apply them to your game.

This is probably the most important point; different languages and engines work differently, and what might be good for one language or engine might be detrimental for another. Also, some optimizations might be not worth it.

I want to add one more thought: if you're using something that makes this easy (Game Maker isn't one of them), it might be worth it to look into delta timing, which allows the game to run at full speed at a lower frame rate, and whether the choppiness introduced by this is worth it. Also, running the game at a lower frame rate (e.g. 30 FPS instrad of 60 FPS) will improve performance significantly.

My website: https://onpon4.github.io

[Image: 590167.png]
11-17-2012 06:18 PM
Visit this user's website Find all posts by this user Quote this message in a reply
sylvanelite Offline
Member

Posts: 6
Joined: Oct 2011
Post: #3
RE: Notes on Game Optimization.
I did some heavy optimisations for Fire Emblem World Cup. I'll post some of them here in case they help.

(note: FE:WC is a browser-based game, so some of these things won't apply to standard desktop-based games)

1) Know your environment. (this is pretty much number 10)

Since FE:WC runs in a browser, it doesn't hurt to look up performance tweaks. For example this article by Google explains how to greatly speed up rendering in a browser. Since my game uses DOM manipulation, not Canvas, this was a particularly worthwhile read. There are similar topics for just about any platform. I could probably list 100 optimisations in FE:WC, that arise from it being browser-based.

2) Know your algorithms.

Knowing the difference between Depth-first, Breadth-first and A* search made a huge difference to FE:WC. (FE:WC uses breadth-first for map movement)

3) Profiling!

Don't make random guesses as to what's hurting performance. Profile it, and focus your efforts. Often 90% of the result comes from 10% work.

4) Space-time tradeoffs.

In FE:WC, some sprites are flipped using Javascript (e.g. battle animations) while others are actually separated images, saved as flips (e.g. background tiles). Pre-computing the tiles sped up performance, with negligible file size. Pre-computing the battle sprites to be flipped would have given no performance increase, but would have increased the size of my game by 25%. It's pretty clear which options to take.

5) PNG crush.

If you use PNG images, look it up, you can often reduce their size for free, often by large amounts. I managed to cut the file size of my game by 50%. (this probably won't impact your run-time performance, but it can often reduce the file size of your game. This is important to me, because my game initially was designed to run on a web site, so bigger files = longer load times on every page view).
11-17-2012 11:18 PM
Find all posts by this user Quote this message in a reply
KiddoCabbusses Offline
Head Director

Posts: 259
Joined: Sep 2011
Post: #4
RE: Notes on Game Optimization.
(11-17-2012 06:18 PM)onpon4 Wrote:  
(11-17-2012 04:12 PM)KiddoCabbusses Wrote:  1) Remove any excess that isn't part of the game from the source before building.

The only code you would remove in this case is comments, and compilers (both machine code and bytecode) remove these automatically (or rather, don't include them). In any case, it has no effect on speed; the only effect is on the size of the executable, and at that not by very much.

You'd be surprised just how much content is kept in games that is never actually used in them.

http://www.tcrf.net/

Unused game content: Great for hackers, hobbyists and nerds, not so much for people who have a chunk of hard drive space or RAM being taken up by an unused object.

Of course, I don't necessarily know if any fangames are guilty of this, but the sheer amount of major commercial titles which had content you needed a Game Genie to see speaks volumes.

sylvanelite: Neat tips! I will say that FEWC ran pretty smooth for me, as far as I could tell.
11-18-2012 01:46 AM
Find all posts by this user Quote this message in a reply
onpon4 Offline
Member

Posts: 97
Joined: Oct 2011
Post: #5
RE: Notes on Game Optimization.
(11-18-2012 01:46 AM)KiddoCabbusses Wrote:  You'd be surprised just how much content is kept in games that is never actually used in them.

Not surprising at all, actually. Most of these cases are video games stored on physical media. Unless you have reached the limit of the space in the medium, there is no point in removing the unused stuff.

In the case of fangames, I'm not sure, but I assume that most unused data would be graphics. For example, I was going to have a fire flower in Bowser's Last Stand, which would have restored Bowser's stamina, but I dropped the idea without actually removing the flower sprite. I also left in an unused jumping frame for Bowser that I thought looked weird. It really didn't make a massive impact when I took these out later on.

Also, in some cases, removing things can cause other things to break. Especially when the space savings are small, it just isn't worth the headache sometimes.

But in some cases, yes, removing some unused graphics and sounds can be worth it to reduce the size of the executable (not so much for RAM, since if your game comes even close to maximizing anyone's RAM simply from the amount of stuff in it, you've got a serious problem). Still, this has nothing to do with how fast the game runs.
(This post was last modified: 11-18-2012 10:55 AM by onpon4.)
11-18-2012 10:52 AM
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)