Thursday, October 7, 2010

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.

Tuesday, October 5, 2010

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.

Monday, October 4, 2010

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.

Friday, October 1, 2010

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...

Wednesday, September 29, 2010

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.

Tuesday, September 28, 2010

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.

Monday, September 27, 2010

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.

Friday, September 24, 2010

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.

Thursday, September 23, 2010

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.

Wednesday, September 22, 2010

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.

Tuesday, September 21, 2010

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.

Monday, September 20, 2010

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.

Thursday, September 2, 2010

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.

Wednesday, September 1, 2010

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.

Tuesday, August 31, 2010

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.

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.

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.


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

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.

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.

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.

Thursday, August 19, 2010

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.

Wednesday, August 18, 2010

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.

Tuesday, August 17, 2010

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.

Monday, August 16, 2010

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.

Friday, August 13, 2010

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.


Thursday, August 12, 2010

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:

Wednesday, August 11, 2010

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.

Tuesday, August 10, 2010

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: