The 7 Worst Verbs Programmers Use In Function Calls

Here are the candidates for the top 7 worst verbs used in function names. I don’t know if programmers invented these, but whoever did was one evil dude.

#7 – dispatch
The best of the worst is ‘dispatch’. Sometimes it might have a real meaning, but unfortunately you get to see this term used badly in code (where you ‘dispatch’ whatever to wherever). Dispatch can be bit meaningless, but I’ll admit sometimes it might do fine.

#6 – do
Whenever I see a function named “doUpdateSomething” (instead of just “updateSomething”) or “doCompression” (instead of “compress”) I grin.

In a bad way.

#5 – resolve
Another “generic” term for something. Instead of “setConnectionBetweenThingOneAndStuffTwo” some programmers say “resolveConnection”. Looks perhaps cool, but name is meaningless.

Sigh.

#4 – handle
Similar to ‘resolve’ (or to ‘do’). Generic, meaningless word.

#3 – manage
When I see this used in “manageArrays” or something similar it hurts my stomach.

#2 – perform
Another horrible term. Thank god you don’t see this often, but even seeing it once is too much. Why say “performCompression” when you can simply say “compress”?

#1 – populate
The most horrible and worst function name ever.

If class has member function ‘populate’ whadda heck do you expect it to do? From the dictionary you can see that ‘populate’ is defined as follows: ‘To supply with inhabitants, as by colonization; people’

Are you supplying your classes with inhabitants?

P.S. These of courses are final truths and should be accepted without questioning, but since some people refuse to do that then you can alternatively stick to using some of this stuff but also think if you currently code using some generic verbs that have very little meaning.

Casual Games Technology Hurdles for Newcomers

Before Lex Venture, my previous experience on game development was mostly on Flash/Shockwave small games and a 3D playable demo of a DirectX 9 game (which never came close to Alpha, but it was nice).

This article is aimed on developers of other game trends and markets (core 3D, indie, mobile, etc) who plan to give PC casual game genre a try on future projects, like we did. When you are going to develop quality casual games using hardware accelerated technologies, the following hurdles must be considered early on the project.

1. Integration with the OS

Many casual players talk on instant messengers, send e-mail, write on Facebook and things like that while playing the game. They ALT+TAB frequently, they use the windowed mode frequently, and everything must go smoothly when an IM window pops in. The present “Internet generation”, by the way, is much used to multi-tasking, so this behavior will only be more present in the future. Therefore:

  • Players like windowed mode. Make sure it’s in your game options.
  • The memory usage must be low, to avoid OS hangs when the user ALT+TAB from your game on a 256-RAM computer.
  • If the user is on the windowed mode, the game must be completely paused – including music and particles – when someone poke the player on IMs, or when the download manager pops a message, etc. If the user is using full-screen it’s open to debate if the game should minimize or keep the game running and allow the “blip” sound of the IM warn the user.
  • Unpausing must be also very straightforward, the user must simply click on the window.

2. Old computers / on-board video cards

Casual gamers don’t update the hardware often. In fact, since they also play while working, they will use terrible on-board video cards. Expect hardware compatible with old DirectX 7 or 8 – on some cases, not even that, and the game will need software-render. Remember that “Windows-ready” computers with on-board video-cards tend to not support OpenGL very well – some of them completely suck on OpenGL mode. So if you’re running under Windows, don’t risk: use DirectX or software render.

RAM limitation is also and important topic, especially if the on-board video card is using a piece of it through some shared video memory schema. Commonly, it will reserve 64 MB of RAM.

3. Save game / Load game

Save games on casual games works differently from core titles. The save game is associated with a player “account”, not with a save slot. More important, since casual game sessions are short (10-15 minutes) but frequently (more than 5 times a day), the user must be able to quickly quit and return later with the very same state he left. So, save games must be recorded every game turn or every couple of minutes without hanging the gameplay.

4. Loading screens

Load screens should present smooth animations that indicate the amount already loaded – like filling bars and walking characters. It helps to keep players waiting. However, to successfully implement smooth animations during loading times (which, you know, hangs a lot!), we will spell the magical word: “multithread”.

Multithread is not easy! Even when implemented only for these loading times. By the way, don’t multithread on casual games for anything else – dual core PCs are still not as widespread as the casual market requires. An exception would be if you are aiming for XBOX Live Arcade or other present-gen console network.

5. Mini-games variety

On the present standards of casual games, you should think on adding variety to gameplay – mini-games, bonus levels and special levels with different mechanics. You have to foresee the possibility of switching the gameplay mechanics between stages. Don’t overlook this analysis – it will really add to development time and force you reworking many codes if you later decide to integrate mini-games on the project without planning for it since the beginning. In our case, implementing the Boss Battle of Lex Venture later added roughly 2 months to the schedule.

6. Switch fullscreen/windowed

On a number of 3D games, you have to restart the game if you want to make the fullscreen/windowed transition. game developers already know why – the game needs to destroy the fullscreened 3D video device and create a new windowed one, hence re-creating every mesh, texture, scene nodes, particles of your game state. Hence some core games tell the player to restart the game so changes can “be applied” and the whole thing will be re-created naturally on the next load.

Asking the core player to restart his 3D game is acceptable on some cases – asking the casual player to do the same is not. Either your engine support switching, or you will have to program an engine wrapper and make the game on top of it, to facilitate the switch fullscreen/windowed feature.

7. 3D technology and 2D graphics

I like 3D graphics! But casual players don’t care if the graphic is either 3D or 2D. Graphics just have to give the game the proper look, make it unique and allow the game to run on casual players’ machines. That’s the tricky part, because they could be using a crappy video card and have DirectX 9 fancy graphics slowly emulated on software – or, more commonly, not even rendered!

Put as much 2D graphics as you can, even if on 3D billboards. Use 3D meshes for specific objects which will provide that unique feel on the game – but always keep poly count under control. Those old days of obsessively counting polygons are back. :) On Lex Venture we used 3D for letters and board platforms, which were cubic and rectangular forms with very few polys.

Also, take a look on my previous article on fancy and lightweight 2D graphics.

8. Security Wrappers and Setup Packs

That is a must on a market dominated by the downloadable try-before-buy model. The technology – engine or framework – you chose must be completely compatible with the main DRM solutions for casual games. True there are many proprietary DRMs you won’t have access to test your technology, like PlayFirst’s, Big Fish’s and Mumbo Jumbo’s. But others like Softwrap, Trymedia and Game Shield are available for use after signing up.

Also, wrapping things and creating setup packs takes time. Specially if you are trying to use the most advanced security functions, which might demand changes on your code. If you don’t have a publisher to do it for you, reserve yourself at least two weeks on that, not counting the approval time of the DRM provider if it’s necessary (like with Trymedia).

Techniques for Fancy and Lightweight 2D Graphics

So you are going to use lots of 2D graphics on your next game project, targeting lower-end machines. It’s a casual-oriented game project, or maybe just a 2D indie game that should run on the most number of PCs possible (which is a smart move). You need:

  • Beauty
  • Performance
  • Fast download

Hardware-accelerated and software-rendered 2D graphics can be both fancy and lightweight. Even if your hardware-acceleration is an old one, like DirectX 7 or 8. You can make lots of effects (“Beauty”), use few video memory (“Performance”) and consume less disk space on the game final size (“Fast download”).

The three main techniques you use to accomplish that are:

  1. Tilemaps;
  2. Real-time draw deformations;
  3. Particles.

Tilemaps

Tilemaps will allow you to have a large amount of 2D sprites on a single 512×512 or 1024×1024 texture. Perhaps even all the graphics you need for the game! :). You load a small amount of tilemapped textures on your video memory and “mount” game graphics drawing pieces of it in the screen. Check this basic tutorial.

Some tools, like Torque Game Builder, generate tilemaps by slicing a texture on a matrix of equally squared tiles, mainly for frame-by-frame animations. But tilemaps can be more powerful. With a custom tool, you can optimize every single pixel of a texture for a different game assets, not space-wasters equally-sized squares! Consider, for example, what Bookworm Adventures did:

http://www.igda.org/casual/quarterly/2_2/index.php?id=2

With a very small set of textures, hundreds of different monsters could be generated with “pieces” of those textures! The outcome was a very small-sized game download (20 MB), but with lots of aggregated values and a tag price of 29 bucks at the time of its launch.

For Lex Venture, we used tilemaps for user interface and in-game sprites taking advantage of every possible available pixel. Loading times got faster than previous projects that used one texture file for each sprite, and disk space and memory usage got smaller.

Tilemap LexVenture

Real-time draw deformation

On hardware-accelerated 2D drawings, engines render sprites by creating a 2-triangle, 4-vertexes primitive rectangle mesh textured with the sprite image, right into the frame buffer. Think it like a 3D plane right in front of the camera (actually, thats exactly how Blitz Basic do it).

Draw deformation is the ability to modify sprite draw by manipulating this primitive mesh. With a good tool-set, you shall be able to change colors of vertexes, deform, scale and rotate the sprite.

For example: you have a white butterfly sprite. Before rendering you could modify the color of the vertexes of the primitive mesh to green, purple or anything else. You will then be able to draw the butterfly with a different color on the white tones using conventional vertex-color technique. Now draw the same sprite many times and you have lots of colorful butterflies in your game with just one single image file!

Deformations on scale, rotation and overall alpha transparency are quite good for GUI transitions. Almost all casual games today use them, and so should you. Pick tools and engines that allow you the vastest range of real-time draw deformations.

2D Draw Deformation 1Draw Deformation 2

Scale + alpha transition

For software-rendered graphics, draw deformations are more limited. For example, you can’t scale with bilinear filters without making the graphics look badly crispy. So plan ahead what the game will and will not be able to do considering the software-render technology you picked.

Dynamic applied alpha masks

Dynamic applied alpha (transparency) masks is a technique to make 2D graphics even lighter on disk space, extensively used by PopCap Framework. You use web-image formats without alpha – JPG and GIF – for your game graphics. For each image that requires alpha, there is an equivalent gray-scale image with the alpha mask needed. The engine loads the GIF or JPG image, and then modify the texture on the video memory applying an alpha channel based on the gray-scale information.

The sum of those two files is smaller and loads faster on software rendering than an image with the same content on a format with native alpha, like PNG. Works best for GIF images. (Note: you should study the differences between GIF and JPG to pick a format that fits into your game graphic style)

Particles

Particles are a important part of any game, but key ingredient to for casual / light 2D titles. You only need a handful of 16×16 textures to create amazing effects on screen! Don’t you dare not considering the particle system on your decision of the which framework to use!

You need a powerful particle system. It would be better if it could draw 2D particles, where particles will be drawn as regular sprites. Most 3D engines features however only features particles using 3D elements like PointSprite, Billboards and Meshes. They are beautiful, but they are also, well, 3D elements! They will consume more CPU with culling / render ordering calculations, and are not as precise for a 2D-based game.

For casual games, aimed on lower-end machines, I advise you to try engines that supports 2D particles. Specially if you are going to support software rendering. If they ain’t available go with PointSprite particles, which are 3D but optimized for 2D drawing at the DirectX device. Billboard and Mesh particles are heavy on rendering if the user don’t have a good video card.

If you can only choose between Billboard and Mesh, go with Billboard. But maybe you picked the wrong framework/engine!

As the last advice, don’t you get too heavy with particles! Low-end machines suffer if you push too hard. Emitters should not emit more than 20-40 particles at a time. I would say 50 on a very particular case, but try to keep the particle count under control . Remember that each particle is still something to be drawn.

Programming Tips Ebook You’d Might Want to Check Out

A friend of mine Arto (or Arex) has put sale his Programming tips ebook. I’ve known Arex for years and seen his talent in action – and I’ve read the ebook. The short & sweet ebook contains 18 pro tips from a programmer who has poured years of knowledge in doing his 3D graphics engine, formerly worked at Nvidia and currently programs at Futuremark.

Arex is a fine chap and the ebook costs $18 (that’s one dollar per tip). There’s some good info in the ebook (see the free sample here), and the offer comes with 28 day money-back-guarantee, so if you are not happy with the product – just give it back and ask for the refund.

It’s quick read, and the offer is located at Arex’s website: Dawnbringer3D.com

Programming Practice That Might Kill Your Code

I was browsing various programming tutorials and saw the code that was technically okay but had problem with being bit difficult to read. I’m one of those coders who believe that there’s enough room in the hard drive to use bit longer variable names…

I probably wouldn’t have noticed this and wrote about it here, but since it was in a beginner’s tutorial – I believe it’s worth mentioning.

The code looked like this:

switch(event.KeyInput.Key)
{
case KEY_W:
case KEY_S:
…{
……core::vector3df v = node->getPosition();
……v.Y += event.KeyInput.Key == KEY_KEY_W ? 2.0f : -2.0f;
……node->setPosition(v);
…}
…return true;
}

Basically there’s nothing wrong with that code. It will check out whether somebody pressed key W or S down and moves a node according to the button pressed. Technically that code looks alright.

But practically there’s a fatal problem that should be avoided readability shouldn’t suffer.

The same code could probably be written something like this (or various alternatives where no “break” lines would be needed etc.):

switch(event.KeyInput.Key)
{
case KEY_W:
…speed = 2.0f;
…break;
case KEY_S:
…speed = -2.0f;
…break;
}
core::vector3df unitPositionVector = unitNode->getPosition();
unitPositionVector.Y += speed;
unitNode->setPosition(unitPositionVector);
return true;

The point is… in the first example, the line “v.Y += event.KeyInput.Key == KEY_KEY_W ? 2.0f : -2.0f;” isn’t very easy to read. Sure, one can get what it means after pondering a while – but in my opinion code should be easy to read. In terms of efficiency we don’t lose anything even if we don’t put all that stuff in one line (after all – it’s the rendering that usually takes time, not asking input from the player once).

But by simply telling what KEY_S and KEY_W do (they change the speed – and it’s pretty easy to spot in which direction) and by mentioning that the vector is moving an unit (or whatever) instead of “v” we can get a better picture pretty fast.

If one must decide between “making code as short as possible” compared to “making readable and easily understandable code”, the latter wins in my books in a heartbeat. Don’t let readability suffer – it may kill your code.

Program Your Game Bug Free – Carefully

Today as I was going through our Edoiki game code and realized I needed to get rid of some old code and replace it with better. I made some changes to bit poorly programmed part in the interface system and it caused me a headache. For some reason after making the code cleaner, the game characters stopped moving.

I (bit hastily) made some fixes that didn’t help anything. I made a few more quick changes, yet the bug remained.

Then I stopped for a moment, and took a deep breath. If I was going to fix this problem, it wouldn’t do any good to try to make it quick. Bug free programming always beats quick programming. I went through a big chunk of code line by line getting rid of some old code. I took all the time in the world, and carefully went through the lines and fixed them line by line. As I was progressing I saw clearly where the errors were and was wondering how it could have worked in the past – since there were some obvious flaws. As I fixed some bad code, making new changes was easier.

In the end, it didn’t take me many minutes to finish the fixing of that piece of code – and I thought that there were two lessons for getting rid of bugs:

Bug free programming ensures a stable base
Ensure that you kill all the bugs in the program as soon as they occur. This ensures that you have a stable base, and can build your product on top of it. I’ve practiced this guideline in the past as much as possible, and I’m pretty confident that it’s the best policy. I think killing bugs is pretty similar to building a house: better make sure that there’s a solid base before putting walls on top of it.

Killing bugs takes time
There’s no need to program in haste. I tried that, and it didn’t work out. It took me much less time to fix problems slowly. Some bugs will take more time, some less – and that’s just how it goes. Simply take your time: there’s no need to rush.