Current Situation, state of progress

Things have taken new direction as of late. The recent progress in making The Crawl in voxel style has proven successful, although progress is slow.

Using Evaldraw as the base engine, there are limits but with limit sometimes comes benefits. Evaldraw is pretty fast, runs on a lot of systems and is pretty portable. Recently Ken Silverman, who created the program, added EXE creation support allows for quick play and all resources nicely packaged within.

So far The Crawl is the only project I'm making with Evaldraw, although I've have some other ideas...just not the time.

A nice thing about Evaldraw is that its pretty close to working with C, although it has built in support for basic drawing, image, audio and voxel models.  So once I've completed the engine for TC in Evaldraw I'll be attempting to write it in C++ using Voxlap.  Technically I'll only be using a part of the Voxlap engine, the KV6 display which uses bounded squares instead of cube rendering.  The benefit is its much faster, and using models instead of a terrain map(which is limited) allows for larger maps.

One other program I've been using which has been very useful to me is GLBasic.  I have been using it to convert a few of my Game Maker projects over to an actual language.  Its based on Basic but has the power of C and compiles C based executables allowing it to be ported to various devices.

Currently I have my number based puzzle game E vs. O setup, but it does need a few finishing touches.  Right now its designed for keyboard control, but I plan to change it to mouse/touch based interface.

Also mostly completed is the basics for Shield Breaker.  Although I still have some graphical and audio enhancements to make, the engine is nearly complete and runs nicely.  One drawback is that if you have a POS system with no openGL support it'll not work well at all.   Haven't tested it on a Mac OSX yet, but hopefully I'll do that soon.  I had tried before but forgot that FullScreen does not work on OSX.  The program will be killed if it trys.

Lastly are the tools for The Crawl, the map maker and image to voxel program.  I still need to update my GLBasic to the new version 8 so I can rewrite the image to voxel program.  New features include an image to array function which will allow me to get around the getpixel problem that occurs in some computers.  The map maker is going along well, but will need a face lift sometime in the end.  So far no plans in changing the map format, which is a good thing.

GLBasic, starting all over again.

So a few months back I came across GLBasic, a Basic language based program that can compile to various platforms like Linux and MacOSX.

Sure as I read up on its features, I was pretty much sold. However I did give it a few weeks messing with the free version to see if it was what I was looking for. Skip ahead and I've got the full license and couldn't be happier.

Although its unfair to compare GLBasic to Game Maker, as they are vastly different. GM uses a standard runner that keeps the file size pretty static, relies on DirectX and by comparison is a lot slower from test I ran during a simple re-writing of my puzzle game EvO Lockmap. GLBasic uses OpenGL and compiles to various platforms, creating much smaller exe files with exception to the OSX version that tacks on about 4 meg of SDL related info.

As a result of having a more powerful tool for creation, I swamped myself in concepts. First was setting up the basis to recreate an RPG I had started last year on Mo Mini's Studio, but due to sickness it kind of fell dormant. Then like I mentioned above I started recreating EvO, with the basics pretty much done, it needs a revisit to clean up the code and change some processes that I now know how to improve.

Then I started visiting the idea of remaking Shield Breaker, but stalled do to trying to figure out the best way to handle pixel based collisions. That has been overcome with my most recent and current recreation of Rick Jason which was one of the first GM projects I started a few years back, which can be found here.

Prior to that I revisited the concept of Voxels by simulating them with rendered polygons, to some success, although it too needs to be updated now that I learned a few more procedures to make rendering more efficient. However I'm not quite sure if I'll be reviving the project as I may lean back to Ken's EvalDraw for anything voxel related. The one draw back of EvalDraw is that its mostly windows based, but can work well in Wine, as Ken told me.

Anyways, now I'm starting organize what projects I'll be doing first. Currently Rick Jason is at the top of the list, as it's engine can be reused for yet another project I have further down the road. Next project in line I haven't quite decided on. Either I'll be starting Black Shadow, Shield Breaker or EvO. Black Shadow may move to the back since I'll have to create a platform engine from scratch for it. EvO is pretty much done except for special bonuses and other such stuff. Which leaves Shield Breaker also needing to be done from scratch, but it is a lot simpler of a game engine then all but EvO.

At this time Rick Jason's engine is doing rather well, so I've started going through the code an organizing it. I had done my best to split things up at the start, but as one goes along things get messy as the code gets bigger. Otherwise I'm both surprised and amazed by the speed increase vs the GM version. There are some drawbacks, rotating sprites is not as easy as it seems. In fact RJ does not use basic sprite draw commands offered but instead generates all onscreen graphics with polygon based texture boxes.

Using this method greatly improves speed and allows me to couple like graphic objects into one large polygon list which further improves performance. The game has a map created from tiles, but in fact there is no tile engine in the game itself. Instead I've resorted to using TileEd to create maps, splits there layers, and slice them into screen sized chunks. The current tech demo of RJ uses 9 slices, which consist of three layers. A glow layer, solid layer and back layer. The solid layer is used to check pixel perfect collisions against game objects. From reading through GLBasic's forum's I found that it is more efficient to have pre-rendered tilemaps vs. live ones.

So everything is going smoothly in that regard, time permitting of course. The only thing I really lack is decent audio and music. I'm still having a little difficulty finding someone who has the time to do anything for me, although I've had a few pieces created. Shield Breaker(ex) had a mp3 made by a new comer to 64digits by the name of Blackhole. One catch with Shield Breaker is that I started using RJ's tiles to create backgrounds. Now that I have revived RJ, I need to find replacement graphics for SB's backgrounds.

And that's about it for now.

All quiet for awhile. Heres whats going on, and ranting. Yay.

Well its been a busy time in the life of myself, moving recently, dealing with some issues, taking care of family and holding down a full-time job. It doesn't leave too much time in ones hands.

So now that things are seeming to organize, I'm redrawing my focus on my various projects. I'm moving on to a new method of game creation.

For the longest time I've been on the never ending hunt for the perfect game engine/lanuage. Its led me to stare blankly at how confusing C can be, lement in Basic's easy but limited uses(like over 10 years ago), freeware creation kits short comings, commercial kits prices and so on. Game Maker was my tool of choice for the last...4-5 years I believe. It did everything I needed and I could do just about anything I wanted. Sure there were limits and drawbacks, but at the time it was not an issue.

Sometimes limits can be part of the fun. I had work with Mo Mini's studio to plan on making cellphone games, but that engine is still pretty young and needs a little more work in its overall layout and methods. It did present me with some interesting notions I now hold, getting the most out of limited space and memory. GM helped me understand some coding practices that were once foreign to me. Reading up on Object Oriented programming and proper use of types also helped.

So now that I'm moving on, I find myself, in a sense, starting back to were I began. Basic. The very first programing lanuage I started with when I was just 10-12(somewhere around there) was gwbasic, and later Quick Basic. I created a few games, finished one and later moved on to my engine hunt. So now I'm working with GLBasic.

At this time, I'm poor, so I only purchased the lite version. Also a lot of my past projects have been 2d, save for my ambitious and still planned The Crawl game/creator.

However, a nice plus is that I'll be giving a shot at making hand-held games, specificly for the GP2x wiz, and open developement handheld device that can be compared to the GBAdance(first one) in looks, but runs linux and has many capabilities that match PSP and DS. I want to do something for the iPhone, but until I can get the complete kit of GLBasic, and have money to setup an iPhone selling service, I'll be going cheaper routes. I've always been frugal and picky when committing to purchasing software and hardware. I've still been burned, but not as much as if I was more careless.

Another thing I hope to change is my solo method. Simply I did everything save for the engines. Made graphics, created scripts, stories, sound effects and so on. Except for music. I tended to use free samples from the web or requested music from some composers.

I have been kicking around the idea of creating some kind of business that connects various talents to create a project, all without binding them into a company. I feel that the independant movement, both in games, movies and other forms is the way to go, or at least something I wish to encourage.

I'm not talking about a networking site, or anything thats automated like those ones that are out there. I mean a business of creating products through the freelance and the talented. One thing I have noticed in life, is that there are a lot of jobs that want papers from college or schools to prove that you know how. I found that this is a load of crap. There are doctors, managers, lawyers, artist, directors, musicians, singers, so on and so on that have papers that say "I know how" but you know what? Its just a piece of paper that anyone can get with the right amount of money.

Money doesn't buy knowledge, cramming for tests doesn't make you remember. I found the best way to learn something is in practice and determination. Its sad that society is so focused on superficial issues to truely see what it needs to. Or at least the companies that hire based on paperwork. To their defense though, how else do you know if someone is any good? Or good to work with. A talented individual can be useful but also hard to deal with if they have a lot of ego, are controlling, greedy, and/or quick to surrender.

So there in lies the problem, even though it would be a much nicer world to work in if we weren't forced to buy our 'knowledge' and 'intelligence', until independants, freelance or what have you band together and push back against the big-box, we as a people will forever be oppressesd by the few.

Knowledge and talent can never be bought.

Its Econapo, Not 3d

The 'Econapo' Project

Originally consider for a competition and then I realized I don't have that kind of time. Now its a slow cook but progressing project. Shield Breaker is on hold due to creative block.

Code named Econapo, for lack of a good title, is a simple Game Maker project that simulates effects I've played with in Freebasic. The freebasic experiment was a simulation of voxels(3d pixels) but used flat planes and a fixed perspective. Econapo simulates a voxel like effect through panning of 20 individual tile layers at various speeds, creating an illusion of 3d depth. Another feature is that the world map exist as a perceived 3d space, as you can go the four main directions (north, south, east and west) at the ends of a map or at alleys and crosswalks.

Each city block usually consists of 4 directional views, maps are labeled as such: 'o_south00x00', with o standing for outside, and the coordinates loosely based on a drawn out map. Effects like fog, rain and snow benefit from the multi-layer approach to create nice effects.

Basic Concept and Plans

Simulating a 3d world in a low-res form, the actual rendering view is 160x120, projected to 400x300, with full screen and stretching working just fine. I used views to keep the pixelation from being dithered, as expanding the view in GM's option tends to add a blur over the pixelation. The blocky look is key to making the panning look nice and keep a general classic look to it.

Levels are based of a sample map and some concept drawings of buildings, positions are placed with objects in the map(deleted after processing) and then tiles painted to the layers with offset depending on the start position of the view.

The current concept of the story involves the player arriving to a city left near deserted by economic collapse. Some drifters, squatters and residents lurk with the city while wild creatures have begun to take over the vacant streets. Your vehicle is out of gas, and of course the station is closed and possibly bone dry.

There will be simple combat in the form of melee weaponry against the wild animals, fighting is not always the best option as there will be no firearms at hand, and you must find your first weapon. Running and darting down street or entering buildings may be your only escape. However not all animals encountered will be hostile, some will just watch you, but others may chase you if you're running by. You can use food items to distract or gain the trust of some animals.

Items will have multiple uses, some can be combined with others, some act as containers for fluids. You will need to consume food and water from time to time to surive and heal. You can also get sick, so you may need to find some kinds of medicine.

Humans you meet in the city will have impression values that change depending on your interaction with them, some may dislike you from the start or simply not trust you.

Navigation is pretty straight forward, you can walk/run/crouch/crawl. No plans on jumping really. No gravity or friction is being used, nor are there any blocker objects.

Possible Future Development

I would eventually like to break from GM to produce the project on a different code base. Currently leaning towards Java and possible Android developement, which may be feasable due to low color usage of the images(tile map total under 200 unique colors) and thus small png files, additionally tools be Kevin Silverman to further optimize and shrink said files. The major challenge would be to project the image pixelated like the gm version, and have Android handle 20 layers of 674x180 sized maps. Grant it not all space will be used. So resource size shouldn't be an issue, but graphical techniques will be a little tricky.

Additionally, using one of those dandy GM port to web, not the Yoyogames one, I do plan to imbed a playable version of the final.

Screenshots and Video Captures


Early development stage


Interior design testing w/ unlimited FPS rate.


Object on screen stress test on a Acer with Intel Atom, stopped once FPS hit 30 from an unlimited setting.


Snow testing, still kind of bogs down things.


Samples of raining.


Run around the block.


Snow test in action, even though its has a live recorder sucking up cpu, the FPS loss is due to over population of tile sprites from the snow...needs some kind of trick to speed it up.

Computer art, a style in its own.

Long time ago, art was always a tangible entity, made of materials, touchable, created through tireless effort and passion. Then computers came around. No big change to art really occurred in the beginning, but we were introduced to the concept of the pixel. A single block of on a projected screen with(at the time) limited color capability.

The kids of the 70-80s era played with these new video games with focus on the game play and not always so much on the art. But in reality, even if resolutions were low and color capability was little to none, a sort of style was created from limitation.

Consider ASCII art, composed of predefined characters, with a large enough space you could create a vista, portrait or any type of image. Sure there were limits, but consider the best of art is self limiting.

Of course breaking limits became a focus of the computers evolution. Even though they were originally designed for writing and data storage, computer games began to steer the evolution of systems. Memory, audio, visual and input became a factor. The consumer was always amazed at each new generation of game that worked upon the evolution of computers.

Yet for a long time pixel art was the norm. Some works were done in vector, defining points to create lines and ultimately images. Asteroids being the most memorable, and later on flight simulations and their likes.

Consoles highly depended on pixel artwork to evolve, Nintendo and Sega both assisted their developers with newer systems with more colors and memory, allowing more elaborate works do be done. In the early 90s, pixel art had become far more mature than its Atari days. Even the first generations of first person shooters relied on pixel art as they rendered their environments.

Polygons were around for awhile, but largely unused. Their abilities in the early days did no catch up to pixel art's quality until much more recently. We began to see the return of inferior or ugly looking games do to limitations in polygons. It was really a slow climb back to quality after that. While 3d was...3d, it still did not have the developed style that pixel art had. Characters were now blockly and spiky, color usage was low, gradient usage was high and levels and areas seemed vacant and bland.

Another big issue, in my opinion at least, was game areas got too large. Were in the past you may of found yourself crammed in a hall way, or even having to go from one block to another(Metroid), now you found yourself walking into concert sized living rooms, hallways you could drive a truck through and in general, no real scale between objects.

Of course I could be critical of pixel based art's past, but its a different story there. When polygon based 3d engines started popping up, focus was put on the fact that it was 3d, not that it looked any good. There were games that did manage to use 3d when it was young and weak, but the best quality 3d game of the mid to late 90s didn't always hold a torch to either pre-rendered(which is unfair to compare) and pixel based artwork.

There were some exceptions, some were able to meld a polygon system and sprite system to create a decent harmony of the two. Two older games used vectors to create smooth animated characters and impressive cut scenes for its time, Flashback and Out of this World. While they made use of solid colors and no shading, the visuals were impressive and the animation was smooth.

However memory was always an issue, but polygons required complex calculations, demanding more of CPUs, so video cards have become a mandatory aspect of game playing. Complex games tend to suck up CPU with basic unseen routines, take the Sims games, lots of stuff goes on in them, now throw in 3d graphics and you've killed your pc.

A third system was also devised, in the late 90s we had a game called Outcast(never played it sadly..) which used a new style of creating 3d, voxel. A 3d pixel cube which allowed the artist to create, in a sense, a more organic look. Some flight sims used it for height maps as well. Ken Silverman, creator of Duke3d's base engine, the Build engine, started to work on a voxel engine around or before 2000 was coming about. Unfortunately theres been no big takers in the industry, now that polygon based engines have near movie quality looks.

Its unfortunate because of the power that a voxel system has over polygons. If we ever see more of voxel based engines, we can look forward to a resurrection of pixel art, in a 3d form without the sacrifices and excessive reprocessing that current 3d polygon engines have today.

Personally I'd like to see, and have been interested by the big industries renewed interest in voxel visuals, Id software seems to be coming up with something using it, but I do like the classic look of old games. Realism can sometimes make a game hard to play. In real life, most things tend to blend together, picking out people in a 3d fps from the background is sometimes impossible. Another downfall is games start looking the same, improvements become less noticeable.

So in conclusion, we may keep seeing all styles stay in existence. Pixels will always be part of screens, until we devise a newer systems. And like classic music, movies and other stuff of old, what people enjoy tends to stick. Mozart made his music centuries ago, but people in this day still love it. Likewise people love Tetris, a game that looks good in near any form and most likely will survive the test of time as well.

Organize for ease. Part 1 - Coding

One of the main reason I prefer game makers is the ability to organize your resources. Resources pile up, I look at my old projects and am always suprised at how many resources are in it. From graphics(majority) to sound effects, it all ads up and it all can belong to different catagories. Of course even with a handy program to sort the stuff in your application, the original resources need a home too.

Now I can't quite say I have an exact system, its more an evolving one really. So let me break it down into a few catagories, for now on coding...

Coding-
There are many different languages out there to code in. C, Python, Ruby, basic, and so on. They can be similar and different in the way code blocks are structured. Some require ending with ; or containing blocks with {} and the worst off is how some use different symbols to control arrays. That always gets me when jumping from one to the other.

Since I'm no expert coder, just a decent one, I can't give advice on making your code faster, more powerful and the likes, but organizing it will make bug fixing and upgrading much easier.

1) Indents - Without it it would be a wall of gibberish, with it you can seperate your routines, statements and all that junk. Normally editor have indents set to 4 spaces, which I think is twice as much as it needs to be.

2) Comments - Commenting is not just good for other coders to learn from your code, but also a good reference when you get lost in the thick of it. Commenting your predefined variables always helps, as sometimes you may use short names or coded names for them. Routines should also be commented as to seperate them from the rest of the code. Using a comment as a page break is also nice, simply creating a line of * or = or - to split up different sections of the code like start, looping, routines.

3) Sub Routines and Includes - These are your best friends, breaking up commonly used code into subroutines and packaged in include files saves your main program of a lot of unnesscary characters.

4) Folders - If using a more traditional language, or doing it old-school with notepad and a compiler, making folders in your project directory to sort your code and resources is a must. The more complicated and more content, the harder it will be to sift through it.

A generic folder structure I use:

(.. representing prior folder name, * meaning all sub folders)

Project\
..\Graphics
..\..\Working (for multi-layered/editable graphics)
..\..\RAW (for processing images into textures)
..\..\Done (completed graphics)
..\..\*\System (UI, mouse, ect.)
..\..\*\Game (Items, portriats, ect.)
..\..\*\Textures
..\Audio
..\..\SFX
..\..\..\RAW
..\..\Music
..\Archive (for old builds)
..\Releases
..\..\Demos
..\..\Snapshots
..\Models
..\..\Working
..\..\Done

So thats how I organize my files and coding, next time I'll cover my graphical procedures.

Game is Art.

Coding is a crucial part of making a game, but at esence theres alot of engines already made. Engines that are better than those who try to make their own, at least when the majority is concerned. Theres a lot of elements in code that make up a game, graphic handling, audio managament, data resources, ect.

Even though the code(the engine) is what sets a game apart from a slideshow, it is ultimately the visuals and audio that wins over the player. However it is not how realistic a game is, but how well it fits. A common problem with indie games(the majority not the minority) is a lack of consitancy in art style and audio. A consistant art style and fitting audio(if needed) can make a buggy game more attractive than a well coded but horribly slapped together with clip art and different art of different styles.

I'm not trying to short change the coders though. Its not easy work. I've had a few attempts, but when it comes down the graphical and audio handling I'd rather leave it to the more experienced. I'm more of a creative type, but I do enjoy coding the game itself.

I focus on the visuals because to me a game is a piece of art. At root its art, it can also become a story, lesson or challange. Unfortunatly high demand has made First person shooters the dominate game of todays consoles and pcs, kind of killing the art aspect when everyone is trying to do realism. The alternative? Usually top-down or 3rd person games. The 2d world is almost forsaken by big industry.

Nintendo has thankfully not gone against its art style. Which to state they even handled the transition better than most. 3d graphics were all the rage when they began to grow, but if we really look back some of the transition some games made or even new ones provided a crappy use of 3d, showing its limits. We now need computers far faster than ever to come close to decent. Even emulating cartoons is more work on the computer than displaying frames.

Focus on making the game a game was begining to fade the more advanced visuals and audio got. The industry began to forget how to make games and just how to clone them. As a result you get games like Oblivion, who had to be aided by user content and lacked the most features of all the Elder Scroll series. Sure you can buy a house(very few) and ride a horse, but sacrafices for graphics cost a lot for that title. Another good example is the much forgotten DeusX 2 and Thief 3. Both originally were very great games but sacrafice a lot due to the 'realism' wars amongst game companies.

While I don't hate realism, I do enjoy it, its just if every game looks real then isn't every game the same?