Tuesday, July 22, 2014

Straight Ahead Programming - When to do it

When to straight ahead program:
1. The task is very simple and you have a very clear vision of the final product.
2. The task is more complex, but you've done it before.
   You are re-writing it for practice, and in hopes of doing it better this time.

When to plan ahead:
1. The task is very complex and you are not sure what to do.

Sometimes it is impossible to work out everything on paper. The devil is in the details.
Sometimes... Writing straight-ahead the first time could be considered "planning" for the
2nd time you write the code. It really depends on how much time you have on your hands and
how important it is to get things perfect.

I tend to only plan when I am looking at the bigger picture of how everything fits together.

For example... While writing this I am contemplating a very important re-factor of my code.
Not sure exactly what needs to change. But I think I need a GlobalAppStateRegistry.as that will
keep track of the global state of the game from the time it opens.

Maybe I need to approach the problem with a better attitude...

Whatever refactored solution I come up with today will be much better than the current system in place.
Iteration approaches perfection, but never reaches it. And that is okay.

Skull of the Shogun

Ran into a girl who's brother does game development while I was swing dancing. skull of the shogun looks pretty cool.

Friday, July 18, 2014

Level Editors and Seizures

A bare bones level editor is almost finished. At the core, we make levels via editing paint files. But we would like to make a more user-friendly editor that anyone can use. The editor needs to be good enough that it replaces our current method of making levels. I mean, how awesome would it be to say: "Buy our level editor! The very level editor used by our studio!" In other news: Don't click this if you are epileptic: Seizure warning. It's awesome. http://adamferriss.com/nze/

GRVC Design Pattern

My extension to a classic "model-view-controller" design pattern: Example: My tile-map class: G = Geometry Model. (Which tiles are where on the tilemap) R = Render Model. (How should different tiles be rendered?) V = View. (Uses the geometry model and render model to create an internal view on a buffer object) C = Controller. (A basic controller. Maybe better though of as API? It has no UI plugged into it. But has basic commands for editing the tilemap. Maybe should rename it as GRAV (GeomModle,RenderModel,API,View) Sample of the sprite-map I am working on for the level editor:
package JM_LIB.toolSystems.levelEditor.leMap 
 import JM_LIB.toolSystems.levelEditor.leMap.components.spriteHandle.SpriteRecMap_LEM;
 import JM_LIB.toolSystems.levelEditor.leMap.components.spriteHandle.SRMapBasicController;
 import JM_LIB.toolSystems.levelEditor.leMap.components.spriteHandle.SRMapRenModel;
 import JM_LIB.toolSystems.levelEditor.leMap.components.spriteHandle.SRMapView_LEM;
  * My own design pattern: GRVC:
  * G.R.V.C. - Geom-model.Render-Model.view.Basic-Controller.
  * Contains everything you need to render, edit, and save a sprite map.
  * DOES NOT contain any UI or display object container to display the buffer though!
  * @author JMIM
 public class LeSpriteCore 
  /** A basic controller that handles basic sprite setting API.
   *  Also references the _view, _ren, and _geon so it can re-draw stuff after edits are made to the map with the controller. **/
  private var _ctrl:SRMapBasicController;
  /** A render model that tells us how different sprite recs should be rendered. **/
  private var _ren:SRMapRenModel;
  /** View object that renders our geom **/
  private var _view:SRMapView_LEM;
  /** The sprite map geometry. No render data. Just tells us what is where. **/
  private var _geom:SpriteRecMap_LEM;
  public function LeSpriteCore()