Jessie+Hildebrandt

10/28/15 - I've diverted my attention for the past week or two towards creating art assets and working on more optimizations. Once of the bigger assets I created was the image. Taking inspiration from the Pokemon Mystery Dungeon games, I thought adding cloud shadows would help to indicate which parts of the dungeon are exposed to the outside world and help to develop some atmosphere. The implementation of the shadows was actually particularly tricky; because they have to be drawn on a section of the map that the base image won't necessarily evenly divide into, I had to come up with a peculiar solution involving drawing the cloud shadows in a Quad object that covers the open area below the dungeon, while constantly updating the Quad object's viewport to create the scrolling effect, with the image itself set to tile when drawn in a Quad that's larger than its native resolution. A screenshot of the (basically) finished results can be viewed. In addition to the cloud shadows, I also starting working on the placeholder spritesheets for the many NPCs that will populate the game's dungeons. My drawing abilities are very, very poor when it comes to characters, so all of the placeholders will be very simple until my artist can get to work on drawing up some better sprites. As far as optimisations go, I focused on simplifying my stencil functions, which up until now relied on per-pixel shaders that required a modern graphics card and a decent computer to run properly. Now that I've simplified the stencil functions to only use a single love.graphics.rectangle call, they are much faster and no longer need shaders to work.

10/16/15 - Another week spent working on optimizations. While I've been neglecting the AI pathfinding library, my work on optimization has been very successful. After rearranging the menubar sprite sheet into a more compact layout, I was able to finish implementing SpriteBatch support for it over the course of a couple of days. Implementing SpriteBatches for the menubar proved to be slightly more challenging than doing the same for the tilescape, mainly due to the menubar's less structured appearance. Thankfully, rearranging the sprite sheet allowed for me to sneak in a few more optimizations; namely drawing each row of icons as a single quad instead of drawing each icon individually. You can see the new sprite sheet for the menubar. In addition, the performance gains provided by cleaning up the menubar's draw code with a SpriteBatch increased the average FPS on my computer from around 630 FPS to around 680, which is almost a 10% increase in overall performance. I even squeezed in some extra code to add an easing animation to the selection highlight on the menubar, which makes navigating the menubar much more satisfying without any performance-related consequences; the SpriteBatch doesn't even have to be reconstructed every frame despite making constant changes to the highlight's position thanks to the [|SpriteBatch:set] function. With the game now running at almost 700 FPS on my computer's integrated graphics, I should have plenty of room to start adding some more features to the game without having to worry about optimizing for a while. While I'll continue to optimize here and there while I go along, performance shouldn't be a major concern for a while, which will allow me to start really getting to work on building the AI and implementing code for all of the different NPCs. Naturally, once the AI is fleshed out, the performance will take another hit, but this is expected, and is something that can be improved upon in the future.

10/05/15 - Once again, the pace of development is not where I would like it to be, as getting my optimization and hardware support to an acceptable level has proven to be a loftier goal than once imagined. I've been doing plenty of research alongside my work, though, and I've picked up on a lot of information regarding the miraculous workings of SpriteBatch objects and the potential downsides of using Canvases for lazier per-frame rendering. I've also learned that [|even amongst LOVE developers, Canvas support is not universal], so I ended up deciding that I should not completely rely on the use of a Canvas object at any point. Once I finally finished implementing SpriteBatch support into the tile library, I saw that not only was the drawing performance with SpriteBatches on par with that of Canvases, but that in certain places the FPS dipped with Canvases where it did not with SpriteBatches. After doing some more reading, I realized that using Canvases for rendering the world can have some serious repercussions. For example, if the resolution of the user's screen is a (relatively small) 1024x768 pixels, and the world is sized at about 3x4 screens, the Canvas on which the world would be drawn would have to be 3072x3072 pixels. At a relatively standard resolution of 1920x1080 the needed Canvas would have to be 5760x4320 pixels. Needless to say, this would use up an unbelievable amount of memory, and this image would need to be sent to the GPU //every frame//. Compare this to the SpriteBatch's advantage of having a single 2-3kB image staying in the GPU's memory persistently (keeping in mind the fact that you only need to update the related list of coordinates every time the world is changed) and it becomes obvious as to why SpriteBatches are a more suitable solution to our performance problem. So, after implementing SpriteBatches and ironing out a few kinks, I removed any and all code related to Canvases from the few places where they were used. This cleaned up the code quite a bit, and consolidating all of my tile textures into a single sprite sheet cleaned up the image resource folders, as well. I'm currently working on implementing SpriteBatch support for the in-game menubar, because it's in sore need of some optimization. The menubar, when drawn, calls the love.graphics.draw function up to 11 times due to the large amount of individual icons that are drawn to its surface when in use. What's worse, it's also currently being drawn in full even when it's closed and only partially visible. I've already done the work of creating a sprite sheet for it (this process consolidated a good 30-40 icon files into a single 700 byte image) and am in the process of writing the code for it. When disabling the old draw code for the menubar entirely, I notice an increase of around 30-40 FPS (which is about a 10% increase), so making it more economical to draw should give me quite a bit of extra wiggle room in regards to performance, especially on older machines. Once this is complete, the game should be performing adequately for its current level of complexity, and the load times should have improved slightly, as well; I've found that sprite sheets are much easier on load times than the process of loading 40+ individual files.

9/24/15 - These past two weeks have been particularly difficult ones regarding the development of the project. In order to get the game running on the older hardware of the school's computers, I would need to write the drawing code for the tile-based landscape to be able to use canvases only when they are supported by the graphics cards, meaning that I would need two different sets of code for drawing the tiles to the screen: one for drawing the tilescape to a canvas object once and then drawing the canvas to the screen, and another for drawing the tilescape directly to the screen every frame. While this was relatively simple to implement, I ran into massive performance issues. Drawing all 3000-4000 tiles to the screen every frame is an extremely costly operation, which is why I implemented canvas support in the first place. Drawing to a canvas and then saving the tilescape as a pre-rendered, single texture meant that you would only have to redraw the tilescape every time something changed. This change alone provided a ~%400 increase in performance, but sadly this cost-effective way of rendering the world would only be available on newer hardware with more advanced OpenGL support, and not on older hardware where optimization is needed the most. After weighing my options, I did some more digging and found out about SpriteBatch objects. SpriteBatch objects allow for more efficient drawing of images on the screen that need to be drawn many times every frame. Instead of sending the image being drawn to the GPU every time an object needs to be drawn, a single image (or one large image containing smaller images, known as a [|tileset or spritesheet]) is sent to the GPU with a list of coordinates telling it where each copy of the image needs to be drawn. If the image is a tileset or spritesheet, the coordinate list will also contain the size and location of each sprite or tile that needs to be drawn. This will greatly reduce the cost of drawing the tiles on any machine, and SpriteBatch objects only use very basic features of OpenGL, so the hardware support for them will be almost universal. When combined with canvases, the gains in performance should be phenomenal, and will create room for me to start implementing other features of the game without having to worry about their effect on overall performance. In order to compare my options, I've created a diagram showing a simple explanation of how the graphics pipeline would look if I implemented SpriteBatches, Canvases, both, or neither. You can take a look at it. Hopefully I can get started on the AI path finding when this is all behind me.

9/11/15 - This year, my Independent Study will, once again, revolve around the development of Dunge-O-Plunge. This week, I set up my development environment. I intended to use Emacs as my editor of choice, but I needed access to the AppData folder in order to install the extensions I required. Because the AppData folder is a system folder, and is inaccessible to user accounts on the school's computers, I had to set up a different editor. I unzipped and set up ZeroBrane Studio in order to use it for my development, which works better on the school computers because the entire program is portable, it's a dedicated Lua IDE, and it has built-in support for developing and debugging LOVE2D games. I wasn't used to the keybinds, however, so I looked up the documentation and wrote a configuration file to create an Emacs-like keybinding setup. (You can take a look at the configuration file to get a general idea of how long it took me to do this.) In addition, I've migrated the game's repository from the now defunct Gitorious to SourceForge on my own time. The project page is here, but most parts of it will be inaccessible until I open Dunge-O-Plunge up to the public. (While SourceForge is an excellent hosting solution, it's inaccessible on the school computers, so I'll be using a thumb drive in order to work on my code at school.) After setting everything up, my first attempts at getting Dunge-O-Plunge to run on the school's computers were unsuccessful. I implemented advanced rendering techniques over the summers such as the use of graphical canvases (technically called framebuffers) and stencil buffer shaders in order to improve the performance of the game. (This was a huge success, boosting the performance of the game on my computer by around 400%.) However, the school's computers lack support for these more modern features of OpenGL, so I'll need to give the game the ability to disable these features on older computers if necessary. By my next journal entry, I'm hoping to have gotten the game working on the school's computers and implemented AI path finding for the first time.


 * -- New School Year --**

1/15/15 - While the progress I've made for this week doesn't quite measure up to the amount of progress I'd made in the previous, I've still gotten some things done here and there, and I won't be one to argue that a little progress isn't as good as a lot. I've finished working the menubar assets into the game and formatting their identifiers, as well as worked a little more on the menubar "library." I didn't have time to touch on the code for handling the tiles, but I did spend some time weeding through concepts and art I jotted down with my co-developer/artist/girl that is a friend/business partner for discussion. I've also loaded the most recent working build of the game and all of the latest assets onto her computer so that she can work on refining and replacing some of the art and images in the game with improved versions. Speaking of art and images, I've finished digging up the old version of the overworld art from Gitorious, and I finished the side-by-side comparison of the old and new versions of the tiles. You can view it here:

12/22/14 - I've finally gotten the opportunity to get a lot done! I've reworked some of the open sourced libraries I'm using in the project and modified the credits and licenses accordingly to acknowledge my modifications from the originals, and I've also completely refactored the scripts that handle asset loading in correspondence with the new changes to the multithreaded loading library. All of the assets for the menubar have been assigned places in the resource table and given spots in the loading sequence. I've begun the initial steps towards creating the menubar, which I'm designing as a kind of library to be used in the main script controlling the game. The code managing the tiles in the overworld will also be moved into its own file in a library-esque format to minimize clutter in the main script file. Most of the time I spent working was adding in all of the assets for the menubar to the loading sequence and the resource table, so I don't have much more to write about. In my off time I'll be creating a side-by-side comparison of the old and new pixel art for the overworld terrain, as individual tiles and in the overworld as a whole. I should be uploading it in my next journal entry.

12/10/2014 - This week has left a bitter taste in my mouth; I was hoping to make up for the lack of progress made during the previous week by getting a lot accomplished this week, but I've been grounded off of the computer until last afternoon. Over the weekend I'm planning on accomplishing the completion of the menu bar and completed tile selection system, and draw up some more game design documents to make up for the work I've missed over the past few weeks. I've at least come up with several ideas to add depth and convenience to the merchanting/income system that I have planned, which will be how the player repays their initial Dungeon Startup loan, pay for maintenance, and build new facilities. I'll post several pictures of the complete set of documents for the income system at a later date, because they do a good job of detailing the system as well as showcasing my though process, but I don't have access to them at the time of writing this. In addition to coming up with these new ideas, I've also been practicing my art skills in order to create better pixel art for the game. This should help Briana as the art director because she won't have as many subpar placeholder assets to replace and she'll be able to better understand the kind of visual style that we're shooting for. Finally, I've been creating concept art for what I'd like dungeons to look like when rendered in-game, because I've been running into the issue of all the art being constrained to a tile system, creating for a very flat and boring look. This new concept art should give me an idea of how I need to approach drawing any entities in-game and help to give the world a better feeling of being "alive" and having depth to it. Like the aforementioned design documents, I should be uploading the new concept art in due time.

11/24/2014 - I haven't been able to accomplish much recently; mainly due to the recent release of the new Pokemon games that I have been sinking a lot of time into. Thankfully, I've at least managed to work on the project for a decent amount of time. The pixel art assets for the menu bar have all been completed and refined, and I've begin initial construction of the script that will control the menubar in-game. Everything here will be kept very modular for the purposes of organization and keeping source files short and readable. In addition, I've committed all of my previous changes to my local repository (to be pushed to Gitorious in due time) and I've started working on design documents for the construction and staff catalogues as well as the design of the traps and buildings that will be rendered in-game. Hopefully the menu bar and other pieces of the UI will be completed in due time.

11/13/2014 - This weekend I spent a lot of time working on pixel art and image resources for the game. I've designed and created around 30-40 different images and icons to be used on the menubar that will appear in the game, allowing for people to easily access many of the game functions without having to move their hands away from the keyboard. In addition, the Play button actually randomly generates a quick world and loads up the game now, with camera movement and (rather buggy) zooming. This in particular took a large amount of time, mostly because I wrote the camera library myself, but it's proven to be smooth and stable. The only problem is that the boundaries that the camera cannot scroll over do not scale properly when the camera is zoomed in, and I'm currently working on a way of calculating a way to determine the extent to which the user can zoom out without viewing the edge of the world. I've also been working on a mind map for the game with Briana. When we work some more content into it, I'll look into uploading it so that you can view it. My goals for this next week or so involve getting the menubar working in the game, programming in a simple tile selection system, and possibly programming in the "Make Path" tool that turns grass tiles into a path for the AI (to be added a ways into the future) to walk on.

10/27/2014 - Progress, progress, progress! After working on the game for about 16-17 hours throughout the weekend, I've managed to accomplish a lot. The entire resource loading system is now working at about half speed but it's now also multi-threaded so that the game doesn't freeze while loading or saving resources, which is vital to have for computers with low RPM harddrives. In addition, a lot of new sprite art has been done in GIMP and I've worked more on getting Briana's development setup for the game's art. In addition, I've programmed in a camera library that uses smoothed translations of the framebuffer to scroll throughout the world in a controllable, camera-like fashion. The tile system is almost done being written for the overworld; I'm starting with simple generation of a plain, a rock wall to dig your dungeon into, and a large solid slab of rock beyond the wall.

10/15/2014 - Welcome to Progress Recap 2: Electric Boogaloo! This past week (or two!) I've done most of my work in the spriting and design department, with a bit of programming on the side. I added a crude but effective system to load mods and modified game files from a folder but was disappointed in the crude way I had implemented it, so I removed it. I also changed the mods menu to display a simple "Coming Soon!" message in place of the buttons that do nothing. I've finished making the initial spritesheets for the overworld grass and stone tiles so that I can begin work on the overworld, and designed the spritesheets so that 4 different variants of each tile are available in one image file. Using variants of the tiles will greatly reduce or remove the effect of tiling, so that the terrain looks varied and natural instead of like a tiling pattern. I've also begun studying weighted heuristics in the hopes of gaining a better understanding of AI pathfinding algorithms so that I may write my own, but I'm having a very hard time grasping the core concepts for now.

09/30/14 - A decent amount of progress has been made this week. I've solved a problem in the loading sequence that caused the game to handle file versions improperly, added a skeletal version of the mods menu, and added a sorting algorithm so that the order of available resolutions is no longer dependent on the user's hardware; it is now sorted so that the beginning of the table contains the smallest resolution and the end of the table contains the biggest resolution, with other available resolutions sorted between them accordingly. With the menu system and the internal resource system nearing completion I should be able to begin coding the actual game itself. In preparation of this, I've been reading up on the A* pathfinding algorithm so that I'll be familiar with it when I go to implement it into the Hero AI. There are already several implementations of A* in Lua and even in LOVE2D. Because I didn't explain earlier, I'd like to elaborate on the LOVE2D game engine (the website of which you can visit here,) which is a fully Open Source game engine written in C++, designed for use by independent developers, hobbyists, and small development teams. LOVE2D games are multiplatform by nature, because the .love files containing the source of the game are compiled into bytecode and interpreted by the LOVE2D binaries, which are available on Windows, Linux, and Mac OS X. On Windows and Mac OS X, games can even be packaged as an executable file containing the required libraries to interpret and run the game as a standalone client, removing the need to install the engine beforehand. All LOVE2D games are written in a lightweight, powerful language called Lua, which happens to be one of the first programming languages I learned to program in. In this coming week, I plan to implement working mod support and resource replacement so that I can finish up the mods menu and begin working on the game.

Tell me more about the LOVE2D game engine.

09/16/14 - The project is making good progress; the UI is now resolution and aspect ratio-independent, allowing the game to run in any resolution supported by the monitor without stretching or visual artifacts. A table of resolutions supported by the monitor is defined as a variable that's available globally within the scope of the game. The options menu allows cycling through the list of available resolutions and overwrites the saved configuration file if an unsupported resolution has been stored in it. The resolution defaults to whatever the closest supported resolution is to the default of 640x480. The project is being hosted on Gitorious at this URL if you'd like to check out the source so far, but please don't distribute the address. The project is not publicly listed and will not be until after the crowd funding campaign. Progress has been relatively speedy thanks to the simplicity of LOVE2D, the game engine I'm currently using. In addition to the options menu, I've been working on setting up another repository for Briana, my lovely artist/girl that is a friend/business partner, to work on the game's art separately in. This coming week, I plan to get more done on the game's internal resource system and get many more placeholder image assets in place for Briana to work on. (Please note that the most recent changes haven't been pushed to Gitorious yet. Once I stack up a decent amount of commits I'll push the latest changes.)

09/12/14 - In the past week I've worked several hours on my independent project at home, making use of my Git development environment to gradually introduce changes and new features to the project. I'm currently working on the menu systems. The main menu (submenu selection menu) is done, as well as the credits menu. The options menu is what I'm currently working on, in addition to aspect-ratio-independent UI scaling, proper fullscreen handling, mouse support, and independent volume levels for different sound sources. This coming week, I plan to finish the options menu in its entirety and have multi-resolution support complete in full. I will also be looking into adding short animated sequences to the menu to represent each menu option.

What resources will you use for your independent project? Create an outline of what you intend to accomplish week-by-week.

09/04/14 - For my Independent Study I will be creating and developing a medium-large video game title. I believe that working on a sizable project (such as this one) independently will provide me with much valuable experience in my career field of choice. I'll be setting up a thumb drive with cross-platform executables so that I can access and work with the Git repository the project is stored on from school computers, and I'll be reporting my progress here in my learning journal. Changes made during the schoolday will be comitted to the local repository on the thumb drive, and if the code I'd been writing is still incomplete I will save it and take it home with me, where it will be merged from the thumb drive into my own local repository for me to work on later in the day. I will also be maintaining a builds repository containing built releases of the game, but this will happen later into the project, when the game is in a more complete state.