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.

Week Seven / Day One

So, just as planned last Friday my first order of business today was cleaning up the level select screen. I'll just put the comparison up and then explain a few things:

The most obvious change is probably the colors. I wanted something that wasn't so dramatic, something that just blended a bit better. It may change, but I like it for now. The layout is the most important change made. What I had before was very barebones, and haphazardly created. Going into the creation I didn't know exactly what I would need, so I just kept adding things where they fit when I created them. However, I would say the layout now has a structure I can live with. Showing a list a levels rather than just the currently selected seems to give the whole thing a more solid feel as well.

The second task for today was adding level tips that are displayed at the beginning of each level. They are just another couple lines of input for each level, and the little window they are in scales nicely depending on the amount of text, with newlines being handled automatically.

What you see on the top is just a simple test, however the bottom is one of my tutorial levels as seen in the above screenshot of the level select screen. These will be the first levels the player goes through which introduce the basic concepts to the game. One problem I've realized as I've let others try the game is that the core mechanic doesn't seem to click right away, with a few claiming that it is just too hard. I'm hoping by introducing different scenarios and techniques piecewise every player will be able to become a Chromovis master.

Lastly, in accordance with the tip screen I added a 'halt' that occurs at the beginning of the level. When the user closes the tip screen, the game doesn't start right away, allowing them to survey their surroundings before beginning. Tomorrow I would like to add a 'Zoom Out' effect to let the player get a view of the entire playing field, as well as start looking into sound. I have a feeling I'm going to need to do a decent amount of reading about OpenAL, as well as a fair bit of work to get it intertwined with the engine, so it can't be put off any longer. After that is working decently I need to start the level builder, as I believe it is the last major hurdle for the whole project. After those two sections it comes down to final cleanup. But, that is still a few weeks away, so in the meantime, happy coding.

Week Six / Day Five - Chromovis

As an end of the week celebration to myself I worked on art for most of the day. I added some tweaks to the font atlas and the font rendering code so that the letters have some effects, as well as an outer border. It cleans the letters up and gives them a more 'production look'. Subtle, but something that I have been meaning to tidy up. I also would like to announce the name of my game: Chromovis. I've been referring to the game as Chromo since I started working on it, as the core game mechanic relied on color. However, I didn't have a good ending, so I just stuck with Chromo until it was time to make a logo, and I decided today it was time to make a logo. 'vis' is latin for force, therefore Chromovis means color force. With that comes the updated title screen:



After I had decided on a name, I started to look around for fonts to use. However, there are very few fonts that are completely free, available for commercial use. I was honestly blown away by this. I really hope someday a site comes around offering thousands of open fonts for anyone to use. In the mean time, I needed a solution that didn't cost the extravagant amounts being asked for licensing rights in a small game ($1k+ for ONE LOGO). What I did was take one of the free fonts, wrote Chromovis in the font in GIMP, and than edited over that font to get what you see. I think it came out well.

There are a few other changes, such as a (in my opinion) better icon logo that I use for the loading screen. Seen here are the new and old respectively:




I'll probably (i.e. will) end up changing it again, but for now it's cleaner than it was. The intro to the game also transitions into the main menu much smoother now, first fading from the loading screen, to a studio presents screen, and finally fading into the menu. I'm not a fan of the obnoxious watermark required by the software I used for my last capture, so I'll forgo the video this time.

That is about it for this week. There is still a lot to do, and I think Monday is going to involve more interface cleanup. I haven't begun to tackle the Level Select screen so that will probably get top priority. I have some changes I'd like to make the the top score saving to better suit updates once the game hits the app store, so that's another task to take care of. Needless to say I've got my work cut out for me, so stay tuned.

Week Six / Day Four

Whew, crazy day.

First of all, I didn't work all day, as my Dad and I did lunch and a movie this afternoon. Nevertheless, I still managed to get quite a bit done. Top Score lists are consistant across game sessions now. It turns out my understanding of how NSObjects work was incorrect. Every NS* type is a pointer, and I knew this, but for some reason it just hadn't clicked with me. Therefore, I was writing an array, changing it, and then writing the next set of values to it. However, when I stored this array I was only storing the pointer, therefore changing the values I had just set previously. But once I got that cleared up I tidied a few other parts of the NSUserDefault methods up and got it running smoothly.

The second major accomplishment of the day was getting the player name entry screen implemented, which you can see down at the bottom of this post. I had originally set it up so that you entered the name entry screen just prior to level selection, but I realized this was just too tedious. iPhone games (especially ones such as mine), are meant to be quick to start and play. Having to enter your initials every time you play the game would lengthen the amount of time before the player can start playing, and that just won't do. What I've done instead is displayed the name on the level select screen where the player can edit it at their will. Also, similar to the high score list a player's initials will last across game sessions, so once the user enters their initials once (assuming no one changes their default name), they won't have to change it again. Mmm, convenience.

I had a bit of a heart stopper today. While I was implementing the initial entry screen, I was getting very odd memory errors. I narrowed it down to being a problem with building the sets of buttons parameters for registering a touch on the screen. However, the debugger wasn't telling me this, I was just getting more general malloc errors. In my mind this meant one thing; low memory. Needless to say I went on a mini optimizing spree. It turns out that I was still generating a bunch of textures that I wasn't using at the moment, so clearing them out freed some resources. I also moved the methods for building the parameters for all the buttons so they were only in memory when they were needed (that is, built and cleared in real time rather than just built once at initialization) without any noticeable slowdown. However, even after all this, the error was still there. Worse, it was reacting differently on the simulator and the device, which always makes things twice as difficult. After taking a breather and coming back, I realized I wasn't setting an iterator to the successive vector before moving through it; in English, that means a heart attack over one line of code. Therefore, something I would expect to give me a specific out of bounds error tied to a certain method (often times down to a specific line of code) instead gave me cryptic memory allocation errors. Frustrating, but just another lesson in never assuming anything from what errors you receive, because no two errors are truly the same.

That about wraps it up for today. I'm not too sure what I'll work on tomorrow, honestly. Perhaps I should start looking into sound? I've got most of the 'stitching' for the core of the game completed, so it's time to do some tidy work as well. For instance, the level select screen is a mess, and I have some ideas about making the interface flow a little better. If not sound, than perhaps starting some preliminary work for the level builder so I can actually start turning this into a real game! In the mean time, Good Night, and Good Luck.

Week Six / Day Three

I really should know better than to assume something will be easy to implement, because as I said yesterday it is never as easy as you assume it will be.

Now, this isn't as bad as I'm making it seem. I am much more comfortable working with Objective-C now than when I started work this morning. It is quite interesting how much you can do with such little code. I've never used a dynamically typed language before, but it does make a lot of tasks simpler. For instance, I'm setting up a big array to save all my high scores in. At the deepest point there is a score entry containing the name of the player and their score. I create an array with these two items. I then create an array to hold ten of these arrays, creating the top ten score list for the level. Last, I create an array to hold one of these arrays for each level. Now, in C++ that might be something like vector< vector< ScoreEntry > >, where ScoreEntry has to be defined as a struct. However, in Objective-C you just pass whatever object you want into the array. It's as easy as defining an array, pushing anything onto it, then just pushing that array onto the next level array, all with no type definitions. Now, the objects need to be formatted as NSObjects, which all other NS* data types are subclasses of (such as NSString and NSArray as I've already mentioned), which adds a bit of complexity, but the simplicity gained in the overall structure is worth it. Also, Objective-C's standard for methods is a bracket system. Where in c++ you would call obj1.foomethod(x), obj-c would be more like [obj1 foomethod:x]. Also, arguments get names, which at first is distracting but once it clicks it is actually quite useful. I'm not sure I'm ready to jump ship just yet, but it's nice to know I have a more solid background as I continue iPhone development.

Now, as to what I actually got accomplished today. I did get high score lists implemented into the engine, however I haven't gotten my NSUserDefaults framework working yet, so the lists aren't valid between play sessions. Also, I've put the level's top score at the bottom of the play screen, a la old arcade games. You can see these down at the bottom in the screenshots.

One thing I need to mention is how much of a slippery slope hard coding values into an engine is. As I said in earlier blog posts, my game is simple enough that I figured having some hard coded values and states would not be that big of a deal. Thankfully I had the foresight to implement a high-level rudimentary state machine, so I'm not working entirely with hard wired conditionals, however as I add small bits that span the menu, level select, and play environments, I am really wishing I had a more general interface builder and state machine. What I hadn't considered was child states, so that I could handle the Pause and Level Completion "states" as true states, and not hard wired conditionals and locks in the application engine. Rather than a smooth, easily manipulated organization I have a decent high-level setup with lots of little conditionals, along with each buttons' position hard-coded in. The plus side of this is that I've learned how not to go about things in the future. I've already got some plans started for the interface and state handler for the next game which should allow for much more rapid and clear development. I only wish I would have seen the light sooner.

Week Six / Day Two

Today's post is slightly shorter than others, on account of me being pulled away from 'the office' all afternoon for landscaping duty.

I started work on the high score lists this morning. My goal is to have Top 10 lists associated with each level that can be accessed from the level select screen. Now, I figured I would basically just be able to do my level loading in reverse, using fstream, just as I've always done for outputting to a file. Unfortunately, it isn't that simple. I have a feeling that fstream is a little too 'dirty' for the iPhone's clean application bundle, and that direct write access needs to be done via approved methods only. Therefore, today began my first major lesson in Obj-C/Cocoa since I started my app development.

As I explained in an earlier post, despite the native language of the iPhone being Obj-C (from what I can tell, being the necessary language for integration of major iPhone technologies used in non-OpenGL apps), C++ execution is perfectly acceptable. Better yet, for OpenGL development C++ is preferred for all platform independent code, specifically for the future porting of the engines. The iPhone specific code for my game is only about 200 lines or so. Porting to something such as the android would require some tuning for handling the differences in touches between the two devices, and appropriately controlling the instantiation of each engine component. Other than that, it wouldn't be all that difficult. There were tutorials I had read that seem to foster a much more iPhone-centric view, but I think the benefits of an interface controlled engine are fairly obvious.

The point of all this was that I needed to learn some iPhone specific data management. While I was trying to avoid this, what I needed to learn was extremely simple. There are a few methods for going about data management. One I would like to learn eventually is SQLite, handling app data in a database style fashion. Not only does this lend to a much more powerful data/data-manipulation connection it would be a good way for me to get some database experience, as I've currently got zilch. However, what I am using is a data type known as NSUserDefaults. NSUserDefaults, from my understanding, is sort of an open book ready to filled with whatever values you want, and a key associated with said values (C++ Dictionary?). As the name describes they are generally associated with the Defaults of a program, such as user name and preferences, however everyone on the internet seems to suggest using them when implementing a high score list. I suppose I can't argue with that. So tonight I started to get a bit of a basic framework in for handling the saving and restoring of an NSUserDefault within my game. Since it is an OpenGL application is has a few modifications from the default app structure. It takes a few hops to get the data down deep enough to where I need it, but not a big deal really.

Tomorrow's work will begin with getting more than a string moved around. Apparently arrays are just as easy as strings (NSArray and NSString respectively), so an array of a levels scores along with a simple key should do the trick. Things don't always go as easily as you think they will, but with this step in the implementation they seem to have, so I'm counting on it continuing. Tomorrow should hold some more comprehensive updates, so stay posted.

Week Six / Day One

Last night driving home I was mulling over the fact that my game appeared too static. When you start a level, it's just there. Nothing is happening, and the whole scene appears dead. Now how to go about changing this? Something I've been considering for a while is moving planets, but I didn't how a clever idea of how to go about it. Would they move back and forth in lines, or better yet what about an orbit? One of the keys to my game though was that the planets didn't need to be updated, as this was one less headache to consider during optimizations. Planet updates added another layer of complexity, requiring extra work per frame updates. However, if I wanted to move in an orbit, all I really needed was an angle, a radius, and a center point. From here I could just increase the angle as I updated the planets' position, and I would have my orbit. Also, since I was already calculating the force between each planet and the ship, I wasn't adding any complexity to the runtime for the n planets, just 3 more lines of code, two of them simple trig calculations.

With that I had dynamic planets, and they added exactly what I wanted to the game. It was only a few extra values to include with the level input file and I was able to create planets which used other planets as their center points, effectively creating moons. In the screenshot at the bottom of the page you can see such an example. The green planet has a large swooping orbit, while the tiny green planet (or moon) orbits around the former. An initial test of over 20 planets seems to make little difference to frame rate. Any frame rate issues I have right now I believe are due to the fact that I still don't have the physics updates and render updates properly decoupled.

The second project of the day was to get scoring working, along with properly handling level completion, which can also be seen in the screenshot at the bottom. On the game screen, the top two numbers are the timer and the total number of color changes made thus far. In the level completion section, you can see the calculation of the score, which is just the product of the timer and the color changes. The scoring system is similar to golf, such that lower is better. You are trying to get the quickest time as well as the least amount of color changes. The number at the bottom of the screen is the distance to the goal. That way when the goal is out of the player's view there is still a method of tracking it.

I also made a few small art changes, such as the new texture for planets. They also spin now, to add more 'life' to the scene. Again, none of the art is final, as it still hasn't 'clicked' with me. I must say though, each day I get more confidence in the completion of the game. I am getting closer to really having something that I would call a presentable game, and it's pretty exciting. There is still a lot of work to be done, but the motivation doesn't hurt.

Week Five / Day Four

If I keep having weeks like this one I'll be pro in no time.

So today I started off fixing the error I had with the level loading. It turns out that it wasn't necessarily my fault. For some reason if I create a file in vi and then import it into my project in XCode, I have no problems accessing it and using it. However, if I create a blank file within XCode, it doesn't work properly. It's as if there is garbage in the file. Perhaps XCode's blank files aren't actually blank. Annoying. Regardless, I figured out the bug and level loading works as expected now.

I also wanted to stress test a bit, so I created a file that had 16 planets. While 16 isn't that many, if it made noticeable differences in performance it would give me a benchmark as to how much I can push the engine. Luckily, it seemed to make practically no difference. Considering how lightweight my geometry is, and the fact the textures are more streamlined since I found out how to make color changes, I didn't expect it to make much of a difference. I'm hoping to support 100+ planets, but without a level builder it is extremely tedious to create a file with those sorts of parameters.

I cleaned up the menu system quite a bit, as you can see below the buttons are much slicker, and the interface has some cohesion to it. This is by no means final art, as the UI and game art really don't go together, but at least it looks more like a game.

What you see in the background is a starfield that scrolls behind the menus. The Intro, Main Menu, About, and Level Select screens all lay over top of it, so there is a smooth transition between each. You can see it in motion in the video at the bottom.

I've also got a pause menu implemented, which allows you to restart the current level or quit back to the main menu at anytime:

Simple stuff given the modularity of the engine, but a useful necessity none the less. As I said earlier I got color changing working with the lighting, so now everything has lighting effects as well as textures with adjustable colors. Now rather than a texture for each button, each planet, etc. I have a single greyscale one that gets adjusted based on what I need.

Before I finished today I added in the level end marks, which are currently marked by the purple planets seen in the pause menu screenshot. By having the end of the level be a planet (with a few extra parameters) it gets treated just like any other planet, and sucks you in once you are just close enough. While nothing happens yet, the next step is a menu for handling a level completion. I would also like to add a timer and the ability to keep track of color-changes for ranking the player at the end of each level, and thus being able to keep a high score list for each.

I believe that is all the changes for today. I did have a very peculiar error worth mentioning though. Usually when an iterator goes out of the bounds of its vector it results in a EXC_BAD_ACCESS error. However, I had a problem today where it seemed like an infinite loop just prior to the applications completion of launching. I had resized a vector one less than needed and therefore the iterator was out of bounds (as a result of sloppy access on my part). It wasn't too hard to pinpoint, but still interesting that there was no 'segfault'. I'm guessing this has something to do with the startup process of an app. Anyway, here is the first video demo of Project Chromo. I don't have any good capture software so I had to use some demo software, so excuse the watermark. In the meantime, happy coding.

Week Five / Day Three

This week seems to be rolling right along quite well, as today played out just about as smoothly as the last two days. Today's big goal was to get the basics of the level loader working, and to do that proper I had to implement some form of text rendering. Now, OpenGL has no built in way to render text, so there are a few ways of going about it. One of the tutorials I read through described using a glyph scripting language to 'build' fonts out of primitives. While this brings a lot of versatility in terms of fonts, the process was quite complicated and a bit more than I needed for my game (I also couldn't get all the different python libraries required installed correctly). The other method is to create a character map as a texture atlas and then pull individual characters out with the texture coordinates. This is the method I went with, and it works great. I haven't had a good challenge in a while where I had to implement an algorithm that took the place of brute force conditionals, and this was exactly what was needed for the character grabber. A 'slider' big enough to fit one character is moved along the texture based on the ascii values of the character. You insert a vector< string >, and each string is printed with a return at the end. The strings are parsed by character, each rendered from the coordinates found given the ascii value used by the slider. Unfortunately the map is rendered with white characters on a transparent background, so it won't show up here.

I also corrected the texture issue. I'm using a different method for loading pngs now that also allows me to load pvrs, so I've been able to mess around with compressed textures as well. They looked quite lossy, and the mipmaps were terrible, but in game you almost can't notice a difference. I still have a problem with updating my pngs in gimp and then loading them into the engine. After being manipulated a few times, the texture fails to load. I've been working around it for the time being, but hopefully I can get it straightened out.

I also got the texture color changing working. Turns out lighting has to be disabled or else the color is completely ignored. I'm hoping this just turns out to be a quirk with how I currently have lighting setup. The good thing is I can now adjust the alpha of a texture, which allows me to fade textures in and out. With this, I can now smoothly transition between screens and such, resulting in a much more professional 'feel' in the interface.

Lastly, once I had text working, I started on the implementation of the level selection. It isn't working perfectly just yet, as I can see the level names but it doesn't load anything other than the first, but I'm pretty sure it'll be a quick fix. I believe that's most of what I got done today. Things are rolling along well now, and I hope I can continue down the designing and tweaking path for a little while. In the mean time, here are some shots of where I got today. Names blocked out to protect the innocent:

Week Five / Day Two

Today went extremely well, and I'd say I've made one of the biggest one-day leaps in terms of tech demo to polished game with the work I got done. My intentions beginning the day were to work more on texturing, mainly to get placeholder graphics in for each place in the game that requires a texture. For the most part everything worked out just the way I needed, and I ended up with this as of 5 minutes ago:

What you see there are the main menu, level select screen, and an in-game shot respectively. I ended up just using static images for the buttons for the time being. Again, not something I agree with doing but I'm going to have to figure out a better solution for the level select, otherwise I'd have to make and load textures for every level, quite inefficient. The in-game stuff looks great in motion. I have that little ship over the colored ball right now, but I'm not too happy with it. The last thing I was working on today was getting it to properly rotate, so until that is done I won't be able to tell whether it's going to stay or not. Also, I added a background texture that moves based on a multiple of the ships movement, which gives it that distance effect 2D side scrollers use to make different background layers move at different speeds. My texture implementation is pretty ugly right now, and doesn't quite have all the features I need (specifically, color changing greyscale textures, so as not to need separate textures for each color of buttons, planets, etc.), so tomorrow once I'm satisfied with the ship and I have the rest of the placeholders setup, I'll be diving into that. I also have a bit of a bug currently. While the simulator runs fine, it seems the red and blue values of textures are getting swapped when running on the iPhone. Not a huge deal, but just an annoyance that needs to get ironed out. I posted up on idevgames about it, so hopefully I get some useful insight. Until tomorrow, happy coding.


EDIT: Almost forgot, I also created the app icon, or at least an initial design for one.

Week Five / Day One

Once again, back to your regularly scheduled program.

Full steam ahead today, as things are finally starting to shape up, at least on the backend. I now have a working 'menu' system in place. The application holds various states, and depending on the current state, the renderer, gamestate, and application engines all perform different tasks. The initial state is just 'blank', which each engine is set to while everything initializes. Once the renderer is loaded and ready to draw, each is thrown into an 'intro' state, where you would put studio information and such at the beginning of a game. This than leads into the main menu. Now granted, for the time being the menu is just basic primitives. But you can click on the buttons, move to the level select screen and back, and get into the test level through the menus. There is quite a bit of hard coded hacks in the background, so to see what is actually going on is a little nasty, but it is very clean from the user perspective.

In regards to the untidiness I started to consider how the menus could be done differently. Much the same as I plan to have my level editor create basic plaintext versions of the levels which are then loaded into the game, a much more abstract menu, or 'scene' object with an associated scene editor could be used for the UI. Each scene would have a background rendering (perhaps a static image, or maybe the engine running in realtime), buttons, and actions tied to those buttons. While this would be much cleaner and 1000x easier to expand, the simplicity of my current project's needs combined with the time needed to rewrite this engine to handle that sort of UI system isn't worth it. Normally this isn't something I agree with doing, but I suppose you can't have/build every feature you want, especially on your first project. Just more ideas for the second though, I suppose.

Textures are still looming over me, as I'm getting to the point where they are going to be necessary for the game to start looking like a real game, and not a simplistic example. I also need to be able to render font, as I want to procedurally draw all the text in the game, rather than have create static images for each block. For those interested, here is the menu: