If you are not a programmer or are unfamiliar with any type of authoring
so ware, then you must rely on your programming team. This can be di?¬? cult because ultimately
programmers want to write good code, and their ?¬? rst impulse is always to build well-engineered reusable
code that they can then use in the ?¬? nal product. This is not a bad idea when you have a clear idea
of all the elements of your game, but this approach to rapid game design prototyping is like building a
tractor to make a sand castle. It is overkill, and it prematurely locks you into something that you might
not be trying to build.
Will the Tool Be Flexible Enough?
Ultimately, you want to be able to change rules and values easily and have the ability to experiment as
quickly as you would be able to in a paper prototype. Although this is somewhat of a holy grail, there
are things you can do to make your so ware prototyping tool more ?¬‚ exible. Here are some simple
suggestions:
Everything is a variable.
Try to avoid using any literal constants in your code; in other words a code snippet that looks like this:
totalOutput = 15 ?? 2
should look like this:
totalOutput = rateOfProduction ?? numFactories
3.
Pages:
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586