Week Eleven / Day Four

Sorry about having no update yesterday. I didn't get much tangible work done, however I got the final four level designs started, and completed them today. Here is a shot of all of them:



Here is the beginning of the implementation of the first on these four, seen on the upper left in the photo above:




It's slow going, because it isn't just a matter of putting the planets where I want them and being done. I build the levels piece by piece, and play it as I go. A lot of fine tuning goes into the positions and the masses of planets to give the right feel and motion for play. It's tough, but this level is about 3/4 complete, and there are only three left to go.

However, I'm taking my GRE on Monday, and I have to devote as much time as I can to that over the next three days, so Chromovis is going on a slight hiatus. I keep making small tweaks, such as an introduction screen I implemented today, so I'm putting a definite complete date as next Friday. Then begins the app approval process. Wish me luck.

Week Eleven / Day Two

I finished the level with the spinners from yesterday:





There is some very big news coming. Like, 'I-might-be-finished-tomorrow-October-6th' big news. Then, it is directly onto the next project. Things are flying all the sudden, and I gotta keep up.

See ya soon.

Week Eleven / Day One

These week numbers are getting rather large. Too large.

Got another level done today, as well as the design for the next completed and the actual level started. Here they are, respectively:


This is the first level to use a moving planet.



Also, I told Lennon what I was looking for in terms of music for the game, and asked if he could throw something together. As I expected, he was pretty into the idea and gave me a sample (?) of the work last night. Quite honestly, I'd say it's almost perfect. He got the vibe I was going for, and it has a feel that fits Chromovis quite well.

There will be a few bigger updates in the next couple days. Just stick around.

Week Ten / Day Four

I got two levels done today:

The first:


The second:


Still working on a name, still need to do music.

Announcements are coming, as well as a new home...

Names...

...are very hard to pick.

Week Ten / Day Three

Got two more levels done today despite feeling like hell.

Here is the first:



The two white planets that don't look like they line up with the three below the blue are orbiting, and the player must dodge them while moving towards the goal.

The second:



Here the player starts in the middle of six orbiting planets (three pairs of two, where each two are on the same orbit traveling in opposite directions). They must time their moves through the planets, stopping on the brakes. While it may be possible to take a shortcut, it's risky.

This brings me up to fifteen completed levels so far, with nine of those being levels that basically just teach the player something, five reinforcing those techniques, and one regular level. I have a few more teaching levels to create reinforcement levels for, and then it is on to making more regular levels. More tomorrow.

Week Ten / Day Two

Off day. Just got some level corrections done and tweaked some things. I fixed the tip text:



I also changed the gameplay border so that it matches the color of your ship, and created a new texture for the gameplay buttons that highlights the current opposite color:



Subtle changes, but every clue helps the player.

I also found a sound to play during the intro, when the studio name (I'm working on this) comes up. It's pretty cool, and everyone will get to see it when I put a video together soon showcasing development, that is once I've gotten music in. I'm still playing around with ideas (simple ones), and hopefully will have something decided upon soon.

The level building is extremely tedious, and without a true level editor basically lacks gratification. I can't wait to start coding again.

Week Ten / Day One

I almost have everything from the list I created last week completed. This morning I added the 'Thanks for Playing' style banner at the end, which just replaces the 'Next Level' option at the end of the final stage. It needs some tuning, but it also has placeholder text for when I figure out a studio name (this needs to happen soon) and can polish it all up. Also, the memory leaks I had last weak apparently were erroneous, as I cannot replicate them, and the only leaks I get now are from an Apple library regarding the display. I have a feeling it believes I'm not releasing the view I am given to render to, but that happens towards the end. The leak is just a blip in time, and leaks a very small amount of memory, and is within an Apple library, so I don't think I need to worry too much.

I played around with GarageBand a bit today. I need some music, and I haven't quite decided on what I'm going to do yet. I thought I had something neat with the synth tool, but apparently I don't know what I'm doing with GarageBand, as the sounds made when recording are clearly different than when just playing around with the instruments. Also, after a few recordings and subsequent undos, GarageBand apparently ran out of memory and complained I had too many tracks to handle, despite there being none. Fantastic. Seems like some garbage thrown together with audacity, the teli and anti-bass is going to have to do:


Maybe playing Gauntlet would help...


I did get some level stuff straightened out today. Here is the newer version of one of the levels mixed in with the tutorials:



It plays decent, gets the point across about dead planets, teaches the player about timing and is aesthetically pleasing. I suppose a puzzle game level can't ask for much more.

I have a few small things to do, like fix the play button artwork (it's a little off) and the tip text (the border is funky since I changed the text size), but other than that I believe it is down to music and levels. While creating each level I'm also trying to draw up a final plan for the number of levels and the 'meta' idea of each. Each new concept taught only needs a level or two to solidify, so I'm trying to balance that with combining multiple concepts together. I said earlier that my game is hard, but I would like to modify what I said. When a level is good, the game is hard. The nature of the beast of these planetary equations is that the systems are stable when everything is in smooth motion, or at least one of the bodies is in motion. Once you start reversing forces (or fine tuning their magnitudes as I hate to admit I've done), things get quirky. The levels that require rhythm and smooth gameplay are the hardest, yet they are also the most satisfying to complete and feel right. I'm trying to find a happy medium, and it's proving to be quite difficult, but the show must go on.

As I near the end of the development of Chromovis, I'm torn. While I am proud of what I have completed, it isn't quite what I envisioned. Perhaps I have more secrets to unlock and something will click, but right now Chromovis hasn't lived up to what I thought it could, nor do I think it will. It doesn't play quite how I wanted, and it isn't the complete package I imagined my first game would be. However, I need to remember that this project was just to serve as a stepping stone. Every developer has to create their first game, and this isn't even what I wanted to do at the beginning, it was simply the result of a compromise with myself in regards to the timeframe available. My original game idea still crosses my mind everyday, and desperately needs to be put into a playable prototype. I think upon the completion of Chromovis and once I get my research squared away I'm going to start fresh with two projects. The first is on the technology I need to develop in order to create the next game proper, with a respectable engine. I'm drawn more and more towards tool development as I read about jobs in the industry, and I feel writing a much more robust and customizable engine with complimentary tools is the next logical step. The second is to bang together a demo of the next project. I feel like an idiot, because I had a few of the parts built but scrapped them when I started to modify my tornado simulator. I suppose it would be better to go back and start fresh regardless. With regards to Chromovis, if I could be done by Friday, it would be a great feeling, albeit not what I expected.

No matter, this is only the beginning.

Week Nine / Day Five

Hello devoted readers, just a half day update today as I have alternative obligations.

I didn't quite feel like working on levels right away this morning, so I looked over my list of changes that still needed to be made. I started off working on getting the user defaults to work on iOS 4. I managed to crash the simulator:



There are supposed to be icons there, which required a reset of the simulator to fix; oops. Luckily, I can only get it to crash while debugging, and even so it is under specific conditions that it's happening, so hopefully it shouldn't cause any problems on the release. I did get user defaults working though, so now high scores and the player name should remain between play sessions. Sweet.

I also decided to do some updates with the 'About' section to create a proper credits section, as at the very least I needed to list the files I used from free-sound.org as well as their creators. After playing with the text size and location, I've got the following:




I think I may want to animate something along the right side now that I've freed up the extra room. We shall see.

I also played around with the art a bit today, as the play interface buttons are driving me nuts with their lack of any design. The planets also needed something a little different, so I just threw a picture of the moon over the gradient planet texture and turned the alpha way down, and got the version you see below. Also, I've always had the border around the play field, however it needed some adjustments, as it was too flat. Here are those changes with what I had as of yesterday for comparison:



I'm going to need to create an alternative texture for the opposite color, because the big 'O' there (no runtime pun intended) looks like crap in my opinion. Just a placeholder though. I also did some level tuning work as well, so things are going smoothly. Hopefully someone sees my post regarding the debug crash on the apple developer forums, as I'd like to know what the deal is with that. I also did some memory testing. Apparently the sound manager is full of leaks, which needs to be taken care of, but doesn't worry me too much as it is a small amount of code that wasn't release ready anyway. There also seems to be a leak associated with a vector when a level is first loaded, so that needs to be taken care of as well. I think that is it for this week. Enjoy your weekends, see you all (any?) on Monday.

Week Nine / Day Four

Had to babysit earlier today, as well as make a grocery run, so while I didn't get a full day in I still made some decent progress. I'm going to come right out and say it, building levels the way I have to build levels does sort of suck. It's slow, tedious, and doesn't really inspire creativity, as instead of being able to just throw planets around and try stuff it's the level designers equivalent of data entry. However, this is the path I've chosen and I am sticking to it.

I got three levels done today, all of which fit into the tutorial section. I don't think I'm going to actually call the tutorials, tutorials. I'd rather them just be easy levels which are meant to teach. That way I can incrementally increase the difficulty of the levels dispersed amongst them. Otherwise, I would end up laying a ton of information on the player all at once and then expect them to start playing knowing everything; rather, I'll introduce a concept and give the player a few opportunities to play around with what they've learned. Here are two of the levels:




There first requires the player to switch back and forth between the planets, moving up the middle to reach the goal. The second requires them to approach the red, stop, move towards green and then down towards blue without hitting the dead planets.

I added a crash animation, or rather I made it so the ship shrinks when you crash into a planet. It's quite simple, but works. The visual cue complementing the audio explosion seems to fit.



Another neat thing I added today was a 'skin' over the ship that rotates based on the velocity of the ship. There is a cutaway on the skin so that you see the old ship texture beneath it, which gives the ship a twirly top look as its moving around. I don't like static things, and this was a simple solution to give my ship some life:




I made a few adjustments to some other levels, either to make the hints clearer or to try and get them to play a bit smoother or more intuitively. I also did some necessary cleanup of the application bundle. I had lots of old textures still being packaged with everything and mixed around in folders, multiple copies hanging, etc. It makes it easier for me to work when I'm at peace with the organization. The code is a spaghetti mess, but I'd say for my first game it isn't all that bad.

That about rounds up today. I'm not exactly getting as far as I wanted to this week, but things are getting chipped off the list. If tomorrow can be a banging day that should give me a good vibe for starting next week. Also, mixing code changes and updates with level building helps keep things interesting. On that note, Good Night, and Good Luck.

Week Nine / Day Three

Today went fairly well, as I got a few small things that were bugging me taken care of. A few of these were issues my stepdad had. First of all, he said the buttons were too hard to see, so now instead of just outlines in the corners they are filled in. In my opinion it doesn't look very good and needs some playing with to fit better, but I suppose it does make for an easier gaming experience, although it doesn't look tron-ish anymore. He also said I should have something that signified what the opposite color currently is. For instance if the ship is red, blue should be highlighted in some way to give the player a small reminder. This should also help players become comfortable with the controls while they are still learning the game.

He also mentioned that the level tip should show up again when a level is restarted, either intentionally or after a crash. Since it is only two simple clicks to clear the tip and start the level, and really shouldn't be too much of a burden. There was also nothing that told you what to do after you crashed. A simple touch anywhere on the screen resets the level, but I hadn't explained that to the player. Also, I wanted the player's zoom settings to stay the same when a level was restarted. These are all implemented now.

I also took the time today to recreate the logo. If anyone hadn't noticed, the logo I made last time actually has a bit of a problem. The yellow circle is bigger than the other circles:


So I fixed it and made the following:



While I could not for the life of me get the impression effect on the colors again, I am fairly happy with how it looks. It sort of amazes me to think that a couple months ago this was my logo:



I believe that's the majority of todays work. I would post some more screenshots but we have a pretty heavy thunderstorm rolling over right now and I have everything shutdown and unplugged, so I'll get some more up tomorrow. In the meantime, happy coding.

Week Nine / Day Two

Not a whole lot to update today. My stepdad played my game yesterday, starting at the beginning of the tutorials and through the first couple levels, as a complete neophyte in order to judge the game's accessibility. Overall he really likes it, he just thought some things were a little unclear and that the levels I had were a bit too hard. He also said that the game seemed to play too fast. This seems reasonable, considering I've been building levels for myself, and I've had hours of practice at the timing of swinging the ship around planets and such. Therefore, I had to figure out a way to make the game a bit easier.

After some more tuning today I realized that if you proportionally change the masses of the ship and the planets, the motions and radii of orbits stay the same, but the ship slows down, therefore making my levels still playable while being able to adjust the speed. Now when the game loads, it loads the levels in but doubles the list, creating a harder version of each level that increases the masses. Not only does this solve my problem of the game being too hard, I now get two levels out of every one I make. Technically I only need 10 levels for release now, because from those I'll have 20. Score.

I added another play element, as well as figured out a new launcher structure that can be built out of planets. Observe the screenshot below:



First is the black planet in the middle of the green planets, or a 'brake'. If the ship is currently colored it will pass through the brake as it weren't there. However, if the ship is neutral is will reach the brake and come to a halt. This comes in handy in a number of cases, particularly in the example above. The array of green planets, or collectively a 'spinner' as I'm calling them, are all rotating around the brake at the same speed, which basically just moves the gap along (think the circles of ghosts in the ghost houses in Super Mario World that you had to jump through). Once inside the spinner, and stopped thanks to the brake, the player can than wait for the spinner to align the gap towards the goal, and switch the the color opposite the spinner, in this case yellow, and the repulsive force of the spinners planets will squeeze the ship out through the hole. I imagine levels built up with a few of these, where the player may need to shoot between multiple spinners to reach the goal.

Overall today went well, and each day I learn more about the quirks of my engine and the neat things I can do with it. I can introduce these concepts to the player in simple form early on and progressively build them up to more advanced levels. Seems I lied, there was a decent amount to write about today. Let's see what tomorrow holds; happy coding.

One last note, depending on the success of Chromovis and my life over the next couple months, there is a good chance a 2.0 could be released before the end of next summer. A lot of the tools I want to build come from things I learned I did wrong with Chromovis, so it should be fairly obvious that they would be tailored quite well to a rewrite of the game. While the game plays well in its current form, there is so much I'd do different in hindsight, and I'd still really like a level builder. If the level builder was built as a debug version of the game engine from the beginning it would simplify the entire process and be much cleaner. Also, level loading and storing, as well as the high score system all could use a rewrite, and I'd love network integration. All in due time I suppose.

Week Nine / Day One

Another tiny hiatus from development work, but I was tasked with driving my cousin's car from Las Vegas to the Poconos. She is in the Navy and is being stationed in Virginia, and wasn't up to making the drive solo, so I flew out early in the month and did some of the harder driving back. It was an awesome trip and a great experience, and I can't wait to do it again soon, albeit on my own. However, it is time to dive back into development and get Chromovis finished.

When I started this morning I made the following list, which I'm pretty sure is the major work left to do:
- Final ship and planet artwork
- Animation for ship destruction
- Music
- Complete 'About' section with proper credits
- Add some sort of 'Thanks for Playing' banner with update plans at the end of the last level
- Add a parameter to the level loader and inputs to allow camera zoom to be tailored to each level
- Fix User Defaults for iOS 4
- Tune gameplay
- 20 full levels
- Create game/studio website and press release

There really isn't that much. One thing I'm not sure I'm going to be able to do before the initial release is test on any other hardware, which is bothersome but I'm not too worried. My phone is the lowest version anyone should be trying to play on (standard 3G), and it runs great. As long as it doesn't run too quick on the 3GS or the 4G, everything should be fine. Getting user defaults to work for iOS 4 might be a bit of a pain, but it is one of those things I'm going to have to learn eventually, might as well get it working now.

The longest part of this list is building 20 good levels, with tuned gameplay. Luckily when messing around with the parameters for Kepler's equation of planetary motion I found a sweet spot (which, for the interested when dealing with units of distance in the double digits seems to be a universal gravitational constant of .01 with masses of both bodies being around 30-50) that tailors pretty well to a smooth enjoyable gaming experience.

I moved the tutorials around a bit, and added some more. They are now divided into two sets, the first of which simply introduces gameplay concepts, including the dead planets seen below which I added today:



You can also see the corresponding level input file to get an idea of what actually comprises a created level. The second set of tutorials teaches the player a few of the basic moves that can be done with the ship when trying to solve puzzles. That way the player gets a feel for how to play, and is then introduced to the mechanics which gives way to more advanced abilities.

As you may have figured out, the level builder is not on that list above, and that's because I don't think I'll be finishing it before initial release. To just get a basic set of 20 levels out shouldn't be too difficult, and it was going to be quite rough as it is, definitely not something I would want to release in its current form. Depending on the reaction the game gets from players I'll decide whether it will be worth completing.

On that note, I began working on levels today as well. The first is called 'Line Rider', as the player needs to zig zag their orbit down a line of planets towards the goal. The second is called 'Kepler's Gauntlet', a mix of planets orbiting in and out of each other that the player must traverse in order to reach the goal. You can see shots of each respectively below:



The last thing that needs to be done is getting a website together. Right from the get go I would like to support players via a website, listing bug fixes, version changes, future projects and maybe high score lists a little later on. At the minimum I need something that will launch alongside the game to give myself a bit of a professional online presence.

I'm pretty sure that is it for today. I think this week will be mostly about tuning and getting levels created, as I think I can finish everything else besides the website in another week. Things are getting close, so keep with me.

Week Eight / Day Three

Today was almost bad. Actually, at one point today was bad.

When I started this morning I had two big problems, massive flickering in the rendering and crashing when the program was executed outside of visual studio. Well, long story short I solved both problems. I almost didn't though. As I was digging and digging I could not figure out why the flickering was occurring. I had double buffering, though I tried a whole other implementation of OpenGL that relied more on glut than on a windows provided rendering space, but to no avail. Same exact flickering. Well it turns out it was flickering because I implemented the flickering. Yeah. Rendering is supposed to go outside of the frame lock, only lock the animation updates. Otherwise massive flickering occurs. It makes sense, but it just didn't even cross my mind before.

The other problem was completely my fault as well. It turns out the directory I was working in had the files I needed to execute outside of visual studio, however it was an older version of the file, and therefore was crashing upon execution. Stupid.

Lessons learned I suppose, but I really could have saved myself a few headaches. Also, error and exception handling is at the top of my 'need-to-practice' (as in do, not learn via repetition) list now. Anyway, seen below is a screenshot of where I'm currently at. I've at least made everything round as well. Circular collision detection doesn't visually make sense with boxes flying around. Adios.

Heh, according to fraps it's running at over 2000fps. Score.

Week Eight / Day Two

Today went fairly well. I wasn't able to work the entire day as I had to get my car inspected (passed!), but I did manage to take care of the next step, which is file I/O from within visual studio. All is not 100% though, as it seems I have a bit of a problem when not running within visual studio's debugger. However, I can run from within visual studio, so it is probably just some file access quirk regarding the working directory (I have no file checking, sorry Dr. Liston). It's all about the quick and dirty right now, just getting stuff to work, so being able to load levels is a big enough step for me. I also quickly threw together the code to handle some keyboard input, so 1-4 handles changing the colors of the ship.

As I had mentioned in an earlier post, my engine's runtime is not decoupled from the speed of the graphics capabilities of the system. Therefore, the faster it renders, the faster the game plays. Which means the first time I tested changing the ships color, it freaked out pretty good. It's ugly, but I implemented a simple frame lock to force updates at 60 fps. Right now it flickers like crazy. I think there is some smoothing or buffering going on with the iPhone that I'm not getting on the PC, and so far trying to just enable double buffering with a buffer swap at the end of scene rendering has left me stranded. So as it stands I can load levels and control the ship, but in all honesty it looks like crap. Here's to tomorrow.

Week Eight / Day One

I don't have anything to update today, as I didn't get anything done yesterday or today. My car is way over due for inspection and the last two days have been dedicated to taking care of that. It has new (bled) brakes, a new tire, and no more loud exhaust. My inspection appointment is tomorrow, so hopefully all goes well with that and I can get back on course here.

Bugger.

Week Seven / Day Five

I was on babysitting duty this morning, and my girlfriend leaves for college tomorrow, so not too much got done today. What I did get done though was the bare-bones of the engine loading up and rendering in a Windows OpenGL window. What you see below in the Windows GL screen is the same as the iPhone screenshot, just without any textures and an expanded viewport.



The blue shapes (#336699 in hex, or close to that, which is my most commonly used color in design I do for anything) are the polygons which lay under the textures, and the white blocks are the shapes that make up each letter of the text textures. Doesn't look like much, but it's quite the leap forward. Once I get file i/o straightened out I'll be able to load levels I've already built, and save new ones, that being the point of all this. Once I have file i/o working I'll start the mouse and keyboard interaction, as well as the extensions that need to be made to the engine to allow realtime creation of planets and such.

One of the 'hitches' with the code right now is the fact that rendering speed is dependent solely on the host systems ability to update. This means the whole thing is built to run specifically on the iPhone, and runs way too quickly on my pc. While this isn't too big of a problem, as I'll be able to delay the play rendering to make it work, this is poor poor design. All of the rendering and updating should be fixed and finely controlled, not just adapted to its environment as I'm doing now. While given the nature of my game this won't cause too many headaches on the devices I plan to release on, it is something that seriously needs to be considered from the design standpoint for the next engine.

I really need to start writing this all down.

Week Seven / Day Four

Ah, Windows.

I did a lot of complaining back in the day about Windows, and I will admit I was quite the Linux zealot at one point. I still prefer Linux as it provides the user with the 'closest to the metal' experience, but with Windows 7 I've come to really enjoy the Windows experience again. Also, Visual Studio 2010 is fairly straightforward. As you'll be able to see in the screenshot below I'm using C++ Express 2010 as my copy of Pro was being a pain. Just as with any piece of software there is a learning curve with VS, but it is practically trivial. I do miss some things from XCode, like the code completion. Perhaps it's available via an extension, but not out of the box. I will say Visual Studio is much cleaner than XCode though. As much as I appreciate the polish of OSX, sometimes the extra 'bubbliness' on everything is just distracting. As I've stuck with the default Windows theme for years, my affinity towards simple, clean lines should be obvious. The only complaint I have about my Windows box is this god forsaken water pump. I'm not sure if a tight line is putting air bubbles through the pump, or it needs a cleaning, or its just dieing, but the constant woosh and wish sounds are enough to drive a man crazy.

Now, onto what I actually got done today. My first inclination towards diving into porting my engine over to Windows was to compile my code with a Windows implementation of OpenGL ES. Only problem, as I found out, is that there is no implementation of OpenGL ES for Windows. Bugger. While there are simulators, this just adds another layer of complexity I'd really prefer not to deal with. I wanted to write code, compile it, and run it natively, simple as that. Well, after prodding around trying to look for a solution, such as a few third-party libraries and wrappers which convert ES code to normal GL, I started to consider what were the differences between my ES code, and regular GL code. It turns, for what I actually needed, there was none at all. As ES is basically a tuned subset of GL, everything I needed was already a part of OpenGL, and I realized I should be able to run my code against the regular GL libraries. A few tests after getting everything linked up in VS proved this to be true. Zing. So, as I finished today I was merging engine code into a new Visual Studio project, stripping out the unnecessary bits, as well as the iPhone bits (such as sound, which touches both of these areas). What you see below is a 1024 x 768 window which will hold the level builder environment. The box in the middle is 480 x 320 to simulate the viewing window on the iPhone. From here I need to brush up on mouse and keyboard interaction in OpenGL to start creating the level builder menus and options.

Unfortunately tomorrow is Friday and I've got a busy weekend coming up, however next week starts a new segment of my life with what I'm hoping are some productive changes to my lifestyle, so from this point on development should start to steamroll pretty smoothly. I also took a gander at the OpenPandora scene today, just to see where things were at. The Pandora is another device which uses ES, so it may end up being my first port or mobile experience outside of the iPhone. A direct port of Chromovis would be quite a feat, and would require a lot of cleanup, but designing my next engine with two pieces of hardware in mind might provide the requirements/incentive for proper abstraction. For now, we'll just have to wait and see. In the mean time, happy coding.

Week Seven / Day Three

Genesis 1:3 "And the Lord said, let there be sound"

Perhaps I have the biblical scripture slightly skewed, but I believe it is something to that effect. Sound implementation today went swimmingly, and is fully operational within Chromovis. Just as I had planned I was able to implement it as an extension of the resource manager. I can load and play sounds and background music through one line calls in the application engine and everything is handled via the resource manager. While I don't have a full set of tools just yet, such as being able to fade sounds in and out, or stopping play altogether, the basic framework is there and I've got placeholder sound effects for each item in the game that requires them.

Thanks to the developer of Tactica I learned about thefreesoundproject, a very cleanly interfaced database of sound clips released under the Creative Commons Sampling License, or in English stuff I can use without licensing nonsense. I hope one day I can contribute free (as in beer) technologies or materials in a similar manner as so many have provided me over the years.

I got quite lucky in my implementation of sound with Chromovis. Actually, I shouldn't say I got lucky, as the 'luck' came from a good modular application design. Because the gamestate and rendering engines make their connections via the application engine, any event that takes place in my game passes through the application engine. While most of the work of the resource manager is given by the rendering engine, the application engine also has access. This means that any event requiring a sound has some point of existence within the application engine, which already has easy access to the resource manager. Adding the sound effects was a simple a matter of adding a single line of code for each sound in the right spot.

I will still say I got lucky though, as this has been another learning experience in terms of the wrong way to do things. While the conditionals for different events exist in the application engine, they shouldn't exist in such a hard format. An event handling engine on the backend applied to each separate module would allow for cleaner, more abstract overall engine work flow. More on this later. In the meantime, I believe tomorrow might be time for some good old fashioned Windows development, as I need to start porting the engine over to Windows to build the level builder. Not only is this easiest in terms of OpenGL, as I can just reuse the old OpenGL framework from the game's original implementation, but in the event I release the level builder I believe this will appeal to the largest audience initially. That is, until (if?) the Linux and Mac ports get done.

Side note, I just found out today an Atlas Shrugged movie is already in post-production and slated for release next year. Yes

Week Seven / Day Two

Not too much to update today, the only real feature added was the zooming effect seen in the screenshots below:

Pretty self-explanatory, (-) makes everything smaller while (+) makes it bigger, within a certain limit. While I've allowed zooming in beyond standard size, I'm not too sure I can think of a reason for doing so (other than increasing the difficulty due to visibility issues). It's one value to change so I may end up locking it down a bit more. I've actually found that playing at .8 times or so the standard scale makes for quite a different experience, and may actually be favorable to users for all play, rather than just getting a different perspective momentarily. Just have to see what my testers say I suppose.

As I said I would yesterday I started looking into sound, and fortunately it seems to be pretty straightforward. Just as textures are loaded at the beginning of application execution, sound files can be loaded and prepared at the same time. I believe my implementation will consist of an extension to the resource manager, that way I can make all the sound play calls from the root application engine module via the resource manager, which should keep things as clear as possible. Luckily in all my spaghetti stringing of code everything that warrants a sound has some representation in the application engine, so the rendering and gamestate engines can stay clueless. This will be tomorrow's job and I'm pretty sure I've got clear cut instructions for implementing, so it should be 100% by tomorrow evening.

I've started to think about what I'll use this blog for once the the game gets launched. I'm sure there will be bugs and fixes to make, so I'll describe my workings with them first and foremost. However, I think I'd also like to use this space to describe everything that is wrong with Chromovis. That isn't to say Chromovis is bad, as I'm quite proud of it, considering it's the largest solo (or group for that matter) project I've ever worked on. There is so much I've learned (a list which I would like to spell out upon completion) that has made it into this game, but more importantly what I've learned I shouldn't have done. I've complained about the handling of states quite a bit, so that is something that requires much more elaboration. I've also made quite a mess of the renderer in my opinion, so I'd like to pick it apart and plan for the next app better. My next game will not have the same depth as Chromovis, but will address different areas I need to learn about, such as procedural game flow and internet interaction. Regardless, all of the mistakes and downfalls of Chromovis will influence my next (simpler) game, and more importantly help me as I plan for my next BIG project. Stay tuned.