design by coding ================ 1) first objective ------------------
there is a target, a fully working playable game (the game already exists) to be completed by the process of design by coding. the coder has to start somewhere: the target game shows a small portion of the game area. the view of the game area changes as the player approaches each of the boundaries of the view. this is a simple first objective. the player also encounters objects, some of which can be collected, others which do complex things, and others which are merely obstacles blocking the path. here, with coding by design, first the pure obstacle - the wall - coded. the complex objects are discarded from the design. the wall is implemented, and then the second level of objects, those which filter movement, are implemented, and other objects - those fulfilling the objective of the game - the collectables which must all be collected, these come next and finally the exit to allow completion, or closure of the level when all the masks are collected. then the coder has something which works, something which achieves all the game play targets of the first level of the game. but it would be nice to have a replay option, just like the original game, and as it turns out is easy to slot in with the existing code. 2) second objective ------------------- the next step, the complex objects - these can be pushed in two directions, and gravitate in one directions . these are the target of the next objective, the next stage of development. the first stage of this is to allow these objects to be pushed about by the player - restricting the push direction to the directions they *can* be pushed. this is a puzzle game all about directions and restriction of direction of movement. the fish can be pushed left or right, but will fall at any opportunity, the chickens likewise, but they gravitate left and can be pushed only up or down. so we now have the fish and the chickens being pushed around but no implementation of gravity. this seems nothing much of a step to the player, but to the coder it was huge. this coder designs the code by coding it. the first stage with the collectable masks, the walls to block the player, and the force-fields to filter the players movement, this design was coded to achieve that objective. the coder thought about the way the fish and chickens would be pushed and gravitate, but could only take one stage at a time. the new objective does not fit the design created by coding the first objective. it's not like badly fitting clothes. it's like trying to dress an elephant in baby clothes. you can't just stitch on longer sleeves which are the length of a elephants leg, onto the legs of a baby suit. the coder is also aware that the movement of objects in the original game has a strong set of rules prioritising movement of multiple objects. the coder has to download a BBC computer emulator and a file re-presenting the original game for the BBC computer. The coder does this purely for reference of course. there is also a level designer and this becomes more important for testing the movement priorities. for example: ! 1 @< ## key: !=fish @=mask <=chicken #=wall 1=player the player can only collect the mask by approaching from its left and has to move back out in the opposite direction to continue collecting masks elsewhere. but what will happen? will the chicken kill the player because it moves left before the fish drops, or will the player survive because the fish drops blocking the chicken? the coder thinks about all this while trying to code a design which lets the player push fish and push chickens. it gets muddled, the coder thinks about how a line of fish all on top of each other will be coded to fall, or a line of chickens all next to each other will run left. surely some generalisations can be made, or some kind of recursive processing of movements. data objects storing information about a movement are created. data objects to create dynamically growing/shrinking lists of these movement objects are created. maybe the player's movement can also be handled by these generic recursive movement processing algorithms? maybe so, things are easily confused. code jumps around from file to file. data structures containing information about how objects can move and other more complex things they do, these get changed, created, deleted, and the original routine to move the player around gets changed, chopped up, re-arranged. new routines are created to begin processing the list of object movements - including the players. things are easily confused. and why update the entire game view window when it is not needed, surely when a player or object moves, just erase it's icon in the old position and redraw it in the new. because this will help when the coder now who's got all this confused broken stuff unconfused and unbroken rearanged almost clearly now with a definite almost target for coding gravitation and multiple targets moving - like the coder had for when coding the pushing of fish and the pushing of chickens. the coder in the player likes to push the fish and push the chickens about, it's quite satisfying but let down by their lack of gravitation, and it's worrying how all this will change and be troublesome when it comes to coding the new design with gravitation - and the coder has not even touched the bombs or dolls yet or the maps and the mask collection code is broken and you can walk over exit doors and erase them. http://www.jwm-art.net/art/archive/XorCurses-0.0.1-4f.tar.bz2 _______________________________________________ NetBehaviour mailing list [email protected] http://www.netbehaviour.org/mailman/listinfo/netbehaviour
