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.
Tuesday, August 31, 2010
Friday, August 27, 2010
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.
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.
Thursday, August 26, 2010
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.
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.
Wednesday, August 25, 2010
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
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
Tuesday, August 24, 2010
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.
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.
Monday, August 23, 2010
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.
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.
Friday, August 20, 2010
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.
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.
Subscribe to:
Posts (Atom)