I started writing this post in hopes of putting it up yesterday, but I guess that didn't happen. I don't know why I never did it - but here it is:
Not much to post. It's been a slow couple of days. I spent some time fixing up some code, removing obsolete code, etc. Lot's of tyding up.
I started to make a little introduction animation sequence to go along with the demo which will eventually be released, sometime. The game probably won't have a name by then, so I will just use the name "Untitled" in the intro, too. :) Who knows, maybe I will think of something to use.
Anyways, my first little intro idea was really terrible. So, I started working on somthing else, and ... well, that's it. I just kind of moved the code for the first intro out of the file, and set up a general structure for the next one. Nothing else was done.
Pity.
Note: Images removed
Well, now I've done it. I couldn't wait! I just had to add bullets! They are fully functional, however functional they may be in the engine's state. They will move on their own, in the right direction, and will become 'eliminated' if they hit a blocked tile :) It's pretty nifty. What's better than bullets that just disappear? Bullets that make some debri when they hit a wall. My little explosion engine works fine just for that! You can set the time length, number of particles to 'use', speed, and partical distance multipliers!
It can be used for anything, not just bullets. Want some random particles anywhere? Just call up the engine!
Here are some little samples of what everything looks like:
Check it out! You can shoot bullets now! So what if they're not perfecly aligned with the gun? It's not even my sprite anyways. It is copyright of Capcom. Anyways, I added a whole other sprite range for running-shooting, jumping-shooting, and standing still-shooting.
See? There's some shooting while you're jumping! You can only shoot one bullet per each press of the 'shoot' button. However, as long as you hold down the button, the character will be holding out his 'gun'. Pretty nifty, eh?
Here we take a look at the little explosion/particle engine. When the bullet hits the wall, it will tell the engine to spray particles in the correct direction! You can't see it too well on a screenshot. It looks better animated.
Here's another look at the explosion/particle engine in effect. You can change the size of the particles, as well as the color, too!
Wow, I never thought I would have finished map changing in a single day. It was a pretty complicated task. I ended up reducing the amount of different maps you could load from a single map to 10. This number is changeable, but it's better than the 10,000 that it would have been. Such a high number for map changes from a single map was too big, and would have taken up too much space to save to file. I kept things minimal.
It works like a charm. Each time you leave a map, it will save your minimap chart, and when the next map is loaded, it will load up the minimap chart! :)
I'm off to build a little miniworld. I'm going to have to sketch it out, because if I go straight into the editor, I always fumble things up. A demo might be released soon. Since I have map changing out of the way, I can build a little demo world for everyone to play on. I'm still not sure if I will put shooting in the first public demo, however. We'll see when we get there.
Wow. I've never hit 3 posts in one day before. Oh well. Guess I update too frequently. That's not neccessarily a bad thing, though. It's a nice break from straight coding.
Anyways, I've added a super awesome little function to the game: MiniMaps! It's wonderful. The minimap will only show areas which you have 'charted' or walked near, with the player. Right now it's fully functional. I also created chart saving/loading functions to save which areas you've charted or not. This is going to be needed once I start making multimap levels, and have player saving/etc. If you've already explored a part of one map, it should stay explored, therefore the chart needs to be saved. Saving it to the player info would prove to be super annoying, since the chart is built off of the current map's dimensions, etc. Instead, It will just save each chart to a separate file. :)
Check out a screenshot at the Untitled page!
There was a little bug that existed when I created the jumping stuff. That was easily fixed. It was searching just one pixel too far when doing collision detection. This would stop the player from being able to fall into pits, and fit between walls that they should have been able to. All because of one pixel. Mrregh. :)
Anyways, I've got some wonderful media for you. Now that the collision detection is working fine again, and I've added a little 'debug' mode to my game, I am deciding to show you some screens of it!
Notice: The sprite used for the player is copyright Capcom. I used them just for testing purposes, and animation purposes. :)
Whew. 2:30 A.M. I just finished doing the jumping stuff. I ran into a lot of problems with this one. For each animation type, running, jumping, or falling, there is a special flag. One to denote whichever you're doing. Well, when jumping, there was a problem - because you were ALWAYS falling, no matter what! I had to change this, so I made it in such a manner that you only fall when you're not pressing the jump button. That worked out well.
It wasn't perfect then, though. You could still jump in mid-air. If you walked off a cliff, you could just jump like you were hopping off of nothing. That was bad. That was a pain in the butt to fix too!
There was this other little problem with the jumping. If you held the space bar, you would just keep jumping. This couldn't be solved so easily since you need to HOLD it down in order to complete the whole jump. I couldn't just make some sort of switch to turn it off once it was pressed, because that would end the jump right there - and it wouldn't meet maximum height. I fixed that by messing around with the jump timer.
Since the flags also denote how the frames are drawn, when you jumped and the jump was over - it would still show the jump animation, even when it should have been showing the running animation, because you were still pressing the jump button. THAT was annoying to fix.
In the end, I had to make a falling down function within the jumping function, that doesn't change the status of Jumping to Dropping.
That probably made no sense to you, but it makes a lot of sense to me, after trying about 50-thousand random things. I'm glad it works.
I'm off to make some "jumper" levels in order to test what I should change the jumping limit to!
Yay! Animation! I coded in everything from running left to right, to jumping up and down. I animated the whole thing. I determines which way you're facing, and which frames to show when running. It's pretty slick, if you ask me. A lot better than a little fixed figure floating around on the screen.
Anyways, there are no screenshots up because I used ripped sprites in order to get the animation working. Instead of spending tons of time making bad-quality sprites, I just used sprites from a known game and placed them into my engine. This way I could test the best frame delay, and test things much better.
Everything worked out, and all I really need to change is the jumping. Right now you can just kind of fly anywhere, forever.
That's about it for today, I didn't stay home and code all day like yesterday :)
I have been doing non-stop work on untitled. Make sure you go and check out the Untitled page. It's got two new screens. Not to mention, I've updated the current screenshot as well.
I have done so much to the game. I made a general map editor for the game. It allows you to use any size tile set, resize the map dimensions, and place tiles either as having a blocked status, or a passable status. This doesn't seem like much, but, believe me it took a while. Now basic levels can be created.
I also updated the engine to read in the maps that the editor makes. Collision detection of 'blocked' tiles is fully implemented. I also implemented the feature where when you are moving, the map will scroll, but when you hit the map's edge, the player character will scroll instead. It's pretty nifty. Did I mention collision detection? Oh yes, I meant to say FULL collision detection, no matter where the map has scrolled, or where your character's at.
Currently, the character's sprite size is 64x64 pixels. This size seems to work pretty good, so I am going to keep everything at that size. Enemies/whatnot. I may have some enemies at a tiny 32x32 pixel size. I don't think anything bigger than 64x64 will be possible without adding extra code just for that sprite into the engine. (That would be for bosses. I may do super-huge bosses).
That's what I've been doing all day - and it works perfectly. I even tested it on a low end 498mhz 11mb-video card computer, and the level worked perfectly. The title screen still needs some optimization, however, but that can be accomplished later. I'm having too much fun with the editor!
Time to go make some fake levels and play around on them! :)
I meant to post yesterday, but I konked out and fell asleep before having the chance to do some late night work on my game. Anyways, I started working with getting tiles to draw on the screen. Soon, I'll have to start an editor and get my map structures working. I am going to allow for 'scrollable' maps, where each map isn't just the size of the screen. It will be a little bit of a task doing this, but I am sure I can undergo it.
I also wrote another piece of music to accompany the introduction animation. It still doesn't fit perfectly, and I need to add some more components to the introduction, but I think I should hold off on that until I have more of the engine produced. I need to see if I can even get the game working before I do some major hard-core development on storyline.
Now, off to a full, free weekend of time that I can spend on my game. Now, let's just hope I actually spend most of that time working on some aspect of it.
Not much was able to have been done in the past few days. I've been doing non-game related stuff. I can elaborate at a later date, if you understand what I mean. (If you really have no idea, I can't talk about it at this moment. ^^)

Anyways, I was able to whip up a quick sprite of the spore enemy (friend?) that may appear in the game. It is really quick, and doesn't look to good right now. There are parts I have to edit, because they use opacity differentials, which can't be shown in .gif format, so that's why it looks kind of sketchy on the 'hangy' parts. If you don't really understand what the thing is, it's a spore. See that circle enclosed at the bottom of the hanging piece? That's the actual spore. The stuff surrounding it is a mucus-like substance, which will hold it onto any surface. Kinda nifty. I am thinking about making it in such a manner that the spore breaks out of the casing before you can fight/whatever it. Lot of concept just for one little enemy guy, but hey, at least I am thinking.
That's all the news I have for you today, seeing as how that's the only thing I have done related to the game.
Well, here is the new layout. I hope all of you like it. If it really bugs you, then send a line to jay(at)loomsoft(dot)net with suggestions on what you think would make the site better!
I went back and even ported over all the archives (previously known as "old news") into this template, instead of just leaving them all crumby and in a different format. Everything should be working fine. I tested and tested, but some things may still be incomplete. If you find any broken links or anything else, please let me know.
I spent a big portion of the day working on some tiles for the game.

I also made a simple rendering of the character! I basically transferred what I had for character concept sketches into this little sprite here and added anything that was left out. It still needs some beefing up, but it looks very nice if you ask me! :)
I placed a bunch of the tiles together in a formation to simulate a "map" which the game might contain. It's pretty nifty. Swing by to the Untitled page to see them.
I also did some programming today, as well. I added in a little introduction screen when you go to start a new game. It doesn't do much right now - just scrolls some bitmaps in a really cool fashion. I may release a little 'demo' once I polish that up.
Now it's time for a break, and some sleep. :)
I decided to take a break from working on the game for a while today, and what do I end up doing? I end up starting a new design layout for the site. I go from one thing, to another just like that. Some break I am taking huh? Just working on more frustrating stuff :)
Hm. The new site may be up sometime tonight. It's a possibility. If not, it will definitely be up by the end of tomorrow (I hope).
I'm still converting all of the pages, and I have to make some major directory changes for the way the new layout works.
Be patient, it will be up soon
After totally revamping the title screen, I made a little 'window' class. It doesn't do too much: it just draws a window with the specified title at the specified location. You cannot drag it around or anything. This will be used to provide a background for buttons, etc. There was a glitch in it, that I did stumble upon right after creating it -- but I figured I should tell you anyways. When the window is drawn, it is drawn to it's own bitmap, and then drawn to whichever bitmap the user specifies. There was a little glitch where for one loop's time the window would be drawn at the default location (0,0) before recognizing where it should go. The problem was solved by just changing the order in which it would blit to the bitmap, and the function which sets its location. I hope that made sense. I always feel like I can't describe what is going on well enough. :)
Aside from confusing bugs which don't even exist anymore, I created a window for the options part of the title screen. So far, it contains buttons to close the window, and raise/lower the volume of the music. It's pretty cool! There is even an indicator bar and number display for the current volume of the music. It's all so very awesome.
I think the next thing I will have to do is create a save/load function for player preferences, to store such things as music volume, sound volume, etc.
The title screen is really starting to look awesome. I'm glad I have been taking so much time to work on it - it's very helpful. It's helping me write neater code, and comment a lot more. I hope this will force me to do the same once I get to the engine, so things do not get out of hand. I'm sure it will! :)
Oh yes, I almost forgot - I also created a little piece of music to go along with the title screen. I'm quite happy with how it came out. It goes along with the overall mood the screen sets right now. Of course, this doesn't really mean anything - because this screen is just conceptual, but it's still a good song.
I downloaded tons of fonts tonight so I could re-vamp my conceptual title screen. I remade the whole thing, background, buttons, button special effects, and the actual title letters, too! I created a new "stealh"-y mode button scheme, which looks much better. It's futuristic looking, along with the rest of the title screen.
With the old button scheme, when you would roll over the button it would display random lines across the screen in between the heights of that button. Instead of having circusy colored lines flashing about, I created a "noise" effect. It basically shows a bar of static across the screen in between the heights of the button. It looks like an okay effect to use for now.
Other than that, I haven't done any programming on the game. Just beefing up my button code. Fun stuff. Check out the current title screen (conceptual still) at the Untitled page. Have fun!
I added even more to the button class. I allowed for sound to be processed when rolling over, or off of buttons. It's completely functional at this point. You can also pass NULL to the sound intializer and it won't process any sound if you don't want it to.
Keep in mind that each button can handle its own unique sounds! It's very nifty. My button class keeps getting better and better by the minute.
I also coded some stuff into my title screen. So far, once the title screen shows up: all of the buttons slide in from the left side, and stop at their designated spots. It's pretty cool. What's even better is that when you hit the options button - all of the buttons slide back over to the left to allow for an options window to be shown. (I have yet to implement the options window). Once you're all done with the options window, you can hit the okay button, and the original buttons will slide back into place.
The really nifty thing about the whole sliding process is the fact that you can select buttons in mid slide. There is no stalling, no waiting, no crashing. You can hit the options button and send the buttons sliding to the left even when they are in the process of sliding to the right. You can hit the options window okay button even as the original buttons are sliding left, and they will begin sliding back to their designated spots.
Whew. That was probably a little confusing, but nontheless it is absolutely awesome. It creates a wonderful effect. If anyone knows of a avi recorder that can record what the computer monitor displays please send a line to jay(at)loomsoft(dot)net. I would love to be able to show you what it looks like. :)
I could always upload a "title screen" demo, but things are a little too messy at the moment. I still need to find adequate sounds to use for the buttons. ;) Keep checking back though. I might just release a demo of the title screen. I'm itching to show people all of this greatness!
The button class is now much more efficient. When I first wrote it I didn't even think of giving it it's own drawing function. Now the buttons can draw themselves. The way the old code was I would have to hardcode and predefine a lot of the settings for the buttons such as their location, all before drawing them.
With the updated code all I have to set are the bitmap grahpics for the buttons, and the drawing function does the rest. All I need to do is pass the (x,y) coordinates to the function and it will do the rest of the thinking for itself. Testing whether the button was clicked is simple to. All I have to do it test the return of one of the class's functions to a boolean value (TRUE or FALSE).
I was able to delete over 50 lines of needless initializing code for the buttons with the new structure for the class! I am so happy with it. I think I might write some more functions for advanced buttons that may show a little more animation than just an ON/OFF sprite. :)
Well, there have been a big change of plans. Seeing as how I can't decide whether I want to make a side-scroller, or a puzzle game - I have decided to stop calling the game Monkotata. All links pointing to the game's page will just point to a blank page now.
Anyways, I've decided to call it Untitled for now. That name will probably change to something like "Project X" or anything similar. The only reason I am doing this is to take the game away from looking like it is going to be a puzzle type of game. I'm not even really sure what it will become at this moment.
Back when I was starting this new project that is exactly what I thought it would become: a puzzle type game. I guess I jumped the gun a little to early and put all that information on my site. After weeks of coding general game stuff (buttons, high scores files, file i/o procedures, etc) my mind drifted from game type to game type. I still haven't even fully decided what type of game it will become. So, as for now, it will be called Untitled. I took out all reference to Monkotata. I probably won't even use that name when the game is finished anyways. I know it will end up being something totally different than what I had expected in the beginning.
Anyways, I've got some new conecpt stuff up for "Untitled" (:D) Be sure to check them out on the designated page. As for programming stuff done today - that was a total nothing. I spent the day downloading samples to use for tracking songs in the new format! :)
I changed the music format I will be using for Monkotata. Instead of using MIDI music, I will be using IT music. The IT format is similar to the MOD format. They are both music in which the artists are called "Trackers" (for those of you who didn't know). I am using an addon library for allegro which plays the files. It is called DUMB. I would like to send a shoutout to entheh who was a great help while I was having trouble installing. He even helped me install allegro correctly. (Yes, apparantly I didn't have it installed completely and correctly!) :) How awesome!
On another note, I keep wavering back on fourth on the idea that I might want to make Monkotata a side-scroller game instead of a puzzle-type game. I haven't really pinned down which I will do. If I do end up making it a side scroller, it will take a lot longer to finish. Also, if I decide to go the sidescroller way and fail, I can just revert to making it into a puzzle game :) *sigh* Oh well. These are just ideas floating around in my head. Either way, whatever type of game it turns out to be, it will use the same character: a robotic-type character, or a person in a robotic-type suit.
Right now it doesn't really matter which I choose, because the core engine for gameplay has not even started yet. :)
So basically, for right now, the type of game it will become is still something I have to decide upon. I think I might be inching towards trying a sidescroller. The characters and ideas I have in my head for a sidescroller game could be very awesome. It is a big task, however. I'll have to weigh all the different aspects in my head over the next few days.
Well, at least it will have quality music that sounds the same on all computers! :)
I started, and finished a whole new part of the game: buttons! If you take a look at the only screenshot available for Monkotata, you will notice that the 'buttons' look really plain and boring. Also, on the code side, it was very jumbled, and a lot of stuff was hardcoded within the actual program to make those buttons work.
With the new button class I have created I don't need to hard code much anymore! Everything works as part of the class. I an now use any size bitmap for the actual button. It supports two frames for each button on for when the mouse is over the button, and one for when the mouse is not over the button. It can automatically tell the program whether the mouse is over, off, or clicking on the button through a single function call. Pretty nifty!
The class works perfectly find and is actually 100% complete at this moment. The only thing I need to do is draw new graphics for the buttons :) My test graphics were not very impressive. I think I will be working on some more dev stuff for the game. I still need to create a suitable title screen! Lots of things to do.
Check out a screen capture of the new buttons.
It's 2:43am while I am writing this post. I stayed up all night tonight working on Monkotata. It took a long time, but I finally completed the main core of the high scores functions. I can't recall how many times I thought I had it finally working yet to realize there were more bugs present.
I was actually able to do it with a single pure-string and char-array, instead of lots of pointers pointing from who knows where to some allocation in memory. Confusing? It was to me. Anyways, it's a lot more refined now with much less pointless code. As of right now it can load/save and add entries to the high score roster. When an entry is inserted, it will automatically move down all the previous entries (like a high score thing should). It saves the information to a file which can be loaded whenever it needs to be.
The wonderful thing about the whole thing is that it can register the spaces now! I may go back and patch up SpaceyShooter since it cannot handle entries spaces in them. I don't know how hard that would be to do. I think I may be able to simply replace the header file directly, and recompile.
I still need to make the whole thing look pretty. All it does right now is list the scores in a simple font in the upper left hand corner of the screen. I don't really care if it's ugly right now. I'm just happy that it works. Happy and tired.
Time to rest up. I have the whole day ahead of me tomorrow to work on something else!
Since I had all of the night to myself, I decided to do some more work on Monkotata. Instead of baffling my mind any further with the high score code, I decided to do something a little graphical. I couldn't really continue on with the game without it. I created some mock-up images of what the game should somewhat look like during gameplay! Take a look at them on the Monkotata page. You'll notice that some of the art in it is from the old version of Monkotata! :) I got a little lazy towards the end, but it gets the point across.
Enjoy the visuals!
I've been cracking down on the high scores code for a while now. I'm still stuck with a few bugs. Because I have everything contained within its own header file, I'm having a little bit of trouble. Some values do not like to stay what they are because they are pointers. File i/o is such a pain because it cannot use pure strings, or pure char arrays. It must be a char pointer. How aggravating. Oh well. Anyways, I am almost done with the high score code. I have the i/o portion working somewhat. It will save the file perfectly, however, it does not like to load the file. It's having trouble for some reason with the cin.getline() function.
I'll figure out what it is soon. As for now, I will just use it how it works: the names cannot conatin any whitespace. I'll have to fix that though - because it is very annoying not being able to handle them.
That's about it for today. I've just worked on the high score code and nothing else. That would also mean there are no pictures for you to view either.
I fixed glitch in the animated cursor system. I made a stupid error in one of my for loops that would add just one more frame of animation that did not exit. That is a very bad thing. Every time it would try to access that frame, instead of crashing, the game would just blit jargon to the screen, usually in the bottom right hand corner of the screen. At first, I thought my animated title screen was very buggy, but it was not. I'm glad I was able to track down a bug in what I wrote so fast. I mean, the program worked fine -- it was just a glitch that I had to find somewhere in the code. That's tough, when you get no errors on compile.
Other than that, I started working on a high score mecahnism for the game. It is using some minimal code from the high score engine from
SpaceyShooter. A lot of things will be altered however. I noticed there was one major flaw with the high schore mechanism for SS. You couldn't enter a name with spaces. I'm pretty sure I can smash that bug and make whitespace work in high score entries.
I also hope to make it a little more flashy, and graphically appealing (instead of just a black screen with text). It will have to go through many developmental stages because I'm not even really sure what kind of 'theme' the graphics for the game will be made of. Lot's of developmental and concept work at this stage, you know? A huge thinking process, but at the same time I am writing the little 'gears' which I am able to do without much of the core game required. It's pretty nifty, actually. I can use most of these functions and headers that I am writing in future games. I'm sure I can even port some of them over to AE once I feel that I am up to the task of completing such a complicated game!
That's about all on the programming side. As for graphical or any other aspect, I have nothing for you. Use your imagination ;)
This is a very early morning post, but I figured I might as well post about what I have done so far. Even if it's something not too important, I would like to post about it. I don't want the news lagging for such long periods anymore. I know I say that all the time, and it never really happens, but that's how I feel.
Anyways, I just added in an animated custom mouse cursor. I whipped up a header file in a matter of minutes which will calculated everything needed to animate the cursor. It's pretty cool actually. I can use the same structure to animate the sprites which will be moving on the screen. The old way I used to do it in my other games would be to have lots of global variables here and there, and then some other variables to track all of the animation stuff. This way, I can just plop it in an appropriate header and change the values only when I have to. Also, this way, everything is totally cusomizable. I can change the values for which sprite to show, and also change the time interval between frames. Actually, now that I think of it - with this new method that I am using, I can change each individual time interval. For instance, instead of having only 5 seconds between each frame for a walk animation, lets say -- I could alternate the time interval between each individual frame within the walk animtion, making some frames stand longer than others. Did that make sense? I hope so.
Here is what my current animated mouse cursor looks like - frame by frame. It's pretty nasty. I will change it into something much cooler. I just wanted to give you something graphical on this post. I like doing that, so here you go:
That's about all for now. If I get some more work done in the day, I'll just add another post.
I haven't updated in so long! Sorry about that. I've been occupied with a lot of stuff lately.
Anyways, to get to the actual read-worthy information. As for the OpenGl work I have been doing: I've taken a step down from how much work I was doing on it. I stopped going crazy. That doesn't mean I'm not working on it any more -- it just means that I'm toning it down. Why, you might ask? Well, I toned it down in order to start a new project.
I know that I am starting too many things to actually finish, but this is the path I have taken, and so far it has been working very well. My project is a new game I will create using Allegro (once again). I hope that this game will be better than any of the games I have currently made.
The project name is
Monkotata. If you've visited the Team page you will notice that one of the 'unavailable' games is Monkotata. Well, I have decided to remake the game using allegro into a version which will be much better than the first. The first Monkotata was made using Macromedia flash. It was a very simple and primitive game. With allegro I hope to make it a much better quality game.

Here is a screenshot of the original Monkotata! Everything was animated, and there were tons of bugs. This was my first graphical game I had ever made. Now it is going to be coming back better than ever!
Give a quick visit to the
Monkotata page to get more information on the game!
You'll also notice that there are some changes to the site! I removed the Games and Other Programs pages. Instead, I just added a subsection on the menu to the left. Now you can simply select whichever game or program from the menu, instead of having to access a sub-page and then pick the game or program you wish to view.
*whew* Big update for today. Enjoy the new content!