Randall's Dev Blog

Lumberbot (working title)

Sat, 11 Feb 2012 21:23:22 -0700

Here is a list of the features I plan on adding to my little “Lumberbot” game some of you may have seen. (If you follow my wife on G+ that is.)

For those of you who don’t here is a link to it: Lumberbot

Here is the link to the G+ post my wife made about it with her brief write up of how to ‘play’ with it: Lumberbot Discussion on G+

Now that that’s out of the way… Here is a list of things and notes about what I want to add to it in the order they happened to occur to me. Brace yourself, wall-o-text incoming.

Adding a map. It needs a background grid for having randomly seeded resources that the various ‘buildings’ that generate the bottom tier of materials will require. Rich soil for a farm, rich minerals or metals for a mine, etc. I’m currently planning on using tiles the size of the farms/mines for drawing the map but having the actual underlying grid size for the buildings being at 1/4 that size. (The size of a robot basically) Individual trees would probably be the size of the smaller underlying tile which would make for 16 per farm.
Farms would be an area on the map that is designated as such. To place a farm you would need to fully clear the area on which you want to place it and it will need to have soil. To change a crop you would need to stop planting and wait for all the plants to be harvested or there would be an option to clear the farm but doing so would make you lose all the plants you currently had growing in it. For now farm plots would all be of a fixed size but I may look at allowing larger sized plots later. Possibly as a tech upgrade of some sort.
Haulers would behave like the bots currently do in what I have now. They would own their own tasks and you would have to edit them to change where they went and what jobs they did. Buildings could toggle on allowing drop-offs or pick-ups. There should be some way to select all the haulers that have the building as a destination on their route. There might be an upgrade to allow the haulers to know before they even go to a building if there is anything at the building for them to do. (So they can just skip it right away without having to run over to it and then on to their next node)
A second class of ‘bot’ would consist of workers who would be assigned to buildings. It would be these bots who would say cut down trees and stack them to be hauled off and plant new ones. The production of a building would depend on the number and skill of the workers assigned to it.
Two classes of workers would exist. ”humans” who would gain skill over time but cost more in “upkeep” (pay) as they do and “bots” who would only gain skill via an upgrade but require less upkeep per upgrade than the humans. The cost of upgrading a robot might be fairly expensive compared to just training up a human but in the long run the robot would be cheaper due to it’s lower upkeep costs.
Haulers would also have two classes. Vehicles that would be driven by humans and automated robotic haulers. The vehicles would be cheaper to get but the combined upkeep of them with the human would be more expensive in the long run. The intent is that you would start with some vehicles and then once you could afford the automated ones you would swap the humans over to being workers and replace them. (or at least that’s my current thinking)
There would be upgrades that you could get that would serve as multipliers to the “skill” of the workers. Better drills would mean that your mining workers would be able to mine that much better for example.
In general, the more valuable an item or resource is the longer it will take to gather/make it.
If the upkeep cannot be afforded then the humans may quit and leave. If a skilled human quits you will have to train up a new hire to replace them. Robots on the other hand may break down and require more money to be spent on repairing them. There might be a small chance of catastrophic failure for the robots if their maintenance isn’t done which would result in the destruction of the robot. Some upgrades might increase this chance making it more risky to miss an upkeep payment for upgraded robots.

GWT Update

Thu, 09 Feb 2012 12:05:47 -0700

I’ve updated it with a few new features including a help page.

One of the shinier new features is the ability to export and import maps. I have a sample map you can import here.

In case you forgot, the link for this version of GWT is: http://thefool76.com/html5/gwt/

More mad webscience. This time it’s another version of...

Mon, 30 Jan 2012 12:42:08 -0700

More mad webscience. This time it’s another version of GWT.
Yes, I re-wrote this thing yet again using HTML5 for some added features.

For those of you who don’t know, the Gaming WebTop (GWT) is a project I’ve been mucking about with for more than a few years now. It’s intended to be a virtual web based gaming table for doing Pen and Paper RPG games.

This time, everything is currently client side. So any maps you save are only saved for the specific browser you are on. (So if you open a different browser or go to a different computer you won’t see the same saves.)

Printing maps seems to work reasonably well for all browsers* except for Opera. I strongly suggest closing all floating windows before printing though. In my tests the background image behind the map did not print so you won’t be wasting printer ink on that. You should only get the map and the grid overlay (if it’s toggled on).

http://thefool76.com/html5/gwt/

*When I say all browsers I really mean every browser except IE. Unless you have the latest version of IE this won’t work at all and even if you do I make no promises. I personally suggest using either Chrome or Firefox.

Social Media, where do YOU live?

Wed, 21 Sep 2011 07:46:44 -0600

Just a quick question that I’m spamming across social media sites. Mostly out of curiosity.

How many of you use more than one social media site with any regularity and if so, which ones?

For me it’s Facebook, G+, Twitter, and Tumblr.

A dwarf fortress story fort (Apexwhips II)

Thu, 08 Sep 2011 20:47:29 -0600

So a while ago I started a story fort in Dwarf Fortress but due to moving and other things I never finished it. I liked the premise but I don’t really want to return to the old version of the game I had started it in. So I’ve decided to restart it in the current version. Seven Dwarves, ten axes, and a forbidding landscape. Lets see if they live.

Diary of “Mandy” the Chief of Lebesbomrek (Apexwhips)

—- First Entry —-

I found a mostly blank recordbook in with the axes on the wagon so I have decided to use it to record a … well a record I suppose. After all keeping track of a fort’s history is traditionally the job of it’s leader. Though to call this place a fort seems a poor joke at best. God forsaken hellhole is more of an apt description but let me start at the begining, or at least as close to it as I dare write down.

First off, let me just mention that the names within this journal are not our real names. Not that it would matter much if they were as I fear we may just all die out here. Those who come across our rotted bones will probably have little care that we are all escaped convicts. That’s right, we are a pack of criminals. What we were in for little matters now and I’m not about to write it down in any case, lets just say we were all incarcerated for our crimes at the prison fort of Axegrind. Being part of the general hauler crew, we were not watched quite as closely as the more skilled laborers so we were able to escape our dismal fate using a plan I devised. It wasn’t a terribly complex plan, we simply deconstructed some key support beams on the guard house and then stole a supply cart in the resulting chaos.

We hitched up the first two animals we could find, a horse and water buffalo, to the cart and drove it out away from the fort as fast as we could. Would that we had paid more attention to the contents of the cart and would that we had been caught. A hammering would have been preferable to this fate. After the initial rush of escape had died down we took a look at what the cart we stole contained. Curse our luck it was a cart meant for the guards and contained nothing but a crated full of copper axes. No food, no drink and worst of all, no picks. We did have the foresight to each take some small amount of food with us in our escape and we prayed that would hold us till we got somewhere we could trade the axes for better provisions.

On the second day of our journy we entered a dead forest. It was the start of spring so the lack of leaves on the trees wasn’t unusual, but something just felt wrong about the place. We kept on though afraid that the guards from Axegrind would be after us. Now though I am sure they stopped chasing as soon as they realized where we were headed. No sane dwarf would want to be in this place. On the morning of our third day of freedom the wheel came off the cart. That in of itself wouldn’t have been so bad except that the cart promptly dropped to the ground with the distinct sound of splintering wood. When we lifted it up to inspect the damage, it was clear the axle of the cart had snapped through when it fell.

That was when the undead Buzzards attacked.

Texture Mix Machine Ver 0.1.5

Wed, 06 Jul 2011 16:56:00 -0600

New Features

Better support for including alt-textures - Pack creators can now include an alt_items.txt and/or alt_terrain.txt file in their pack. These files are just a simple list of alternative files for terrain and item tiles within the zip. Place each file on it’s own line. See the ones in the included simpletech.zip for examples.
Generic Block mode preview for alt-textures - Since I cannot really know what tile is meant for what in an alt texture sheet, I just load them all on a basic block model. (Block in the sample.mdl file) This means that the tiles in an alt-terrain.png don’t have to be in any particular order to still get a preview. (Mind you it also means that multi-tile textures and objects don’t get a custom model.)

Download

Texmix Version 0.1.4

Tue, 05 Jul 2011 15:20:00 -0600

Three new buttons were added at the top. They are in order:

Save Button - Saves your current mix.
Terrain Button - Switches to editing the terrain.png
Items Button - Switches to editing the gui/items.png

Pressing the ‘z’ key will now toggle zoom mode in which the current selected tile is zoomed to fill the picker.

Right clicking in the right hand picker will now preview tiles without doing the swap.

Download

Texture Mix Machine Ver. 0.1.2

Wed, 29 Jun 2011 17:55:00 -0600

New version up.

New Features

alt pack folder and alt terrain folder - Any pack (.zip) placed in the alts folder will be read by the pack regardless of the directory it is looking at. Additionally any .png in the alts/terrain folder will be read by
the pack as an alt of terrain.png. Packs in the alts folder will be prefixed with a * in the listing and files
in the alts/terrain folder will be prefixed with a +.
secondary model previewer tied to the right hand picker

Bug Fixes

Fixed an issue with the side of the large chest model using one of the back tiles instead of the side tile.

Download

Texture Mix Machine

Wed, 29 Jun 2011 09:54:39 -0600

I have a new version up. This one includes the ability to change packs from within the program as well as support for HD textures. It can even mix tiles between different pack resolutions resizing as needed.

Download

Texmix Alpha 0.1

Wed, 22 Jun 2011 17:56:42 -0600

I have the alpha version up and ready for it’s first public testing! *cheers*

Currently I only have a windows build done but it has been confirmed to run under Wine by my official test ferret. A linux build will be coming.

To use, just download it, unzip wherever and then run texmix.exe. It will default to using the default.zip pack I distributed with it and it will save to test.zip when you exit. For more information (Including how to specify other packs on the command line) check out the README.txt file.

You can downlaod it here: http://thefool76.com/minecraft/texmix_bin/Texmix.zip

This shot shows the now Fully Operational Batt… er Texture...

Tue, 21 Jun 2011 23:13:46 -0600

This shot shows the now Fully Operational Batt… er Texture mixer. In this shot you can see how I’ve replaced the smooth stone half-block with the bookshelf textures.

I now have it loading all it’s data from files, opening texture packs that you specify on the command line, and saving the resulting mixed terrain.png in a .zip for use in the game.

Stuff left to do before I release the very first Alpha version:

Finish the sample.mdl file. Currently I only have Grass, Dirt, Stone, Wood and StoneStep (Smooth halfblocks) defined
Finish the texture_index.txt (This describes what model to use for the preview when a tile is selected on the left hand picker.)

The Alpha will only work on two packs at a time and will require specifying both source packs and the name of the pack you want to save to on the command line. I’ll include more info about it when I release it.

After a little bit of bug fixing, I got the preview display to...

Wed, 08 Jun 2011 17:25:00 -0600

After a little bit of bug fixing, I got the preview display to play nice with my 2D GUI stuff. (Depth buffer testing + drawing on a 2D plane = Why is only my first GUI element drawing?)

This is also probably not that far off what the initial alpha build is going to look like. I’m picturing a scrolling ‘list’ of blocks across the top for previewing (just click on one to center it.) and then two textures open down below similar to how the web version works. I have other ideas for what the final interface is going to be, but this setup will suffice while I get the core functionality worked out.

I have the model loader working now. Those three blocks are...

Wed, 08 Jun 2011 13:32:00 -0600

I have the model loader working now. Those three blocks are being loaded off the sample file I linked in my last post. I think the next step now is to finish defining just how I want the user interface to look and what data structures I’m going to need to support tracking the Texture pack specific data.

Model File Rough Draft

Mon, 06 Jun 2011 21:38:00 -0600

Spent some time working on the model file concept and I have an initial rough draft for what it might look like.

http://thefool76.com/yummy/sample_mdl.txt

I’m going with the ‘tag’ based format because that would more easily convert over into a binary format later on. That and not using XML means not having to add an XML parser which I think would be using a sledgehammer to kill a fly. The rest of my logic and reasoning should be contained in my comments in the file.

If anyone has any suggestions or comments, let me know. I always appreciate constructive criticism. :)

Model Files

Mon, 06 Jun 2011 15:39:29 -0600

After doing the preview and getting the small spinning block, I did some thinking about exactly how I wanted to define the blocks and other elements. If the game consisted of just blocks it would be easy. Just have a single block class and then put whatever textures on that I need. However the game has more than a few non-block elements so I need a way of drawing those as well.

Additionally, I have the goal of re-using as much of this as possible. With that in mind I decided I needed a general purpose model definition file, preferably in plain text (at least to start with). Unlike Notch, I like being able to easily add stuff without having to re-compile. So when new stuff is added, all I would need to do to support it is edit a few text files. (As opposed to recompiling the entire program.) A side benefit to this is that it would also be easy to add support for any mods.

If I can get it to work like what is in my head, this model engine may turn out to be the single most useful thing I get out of this Texmix project, even more so than the GUI stuff. Now to see if I can’t come up with a good design for the file…

Just a little teaser showing one of the features that’s...

Mon, 06 Jun 2011 11:29:20 -0600

Just a little teaser showing one of the features that’s going to be part of the Texmix tool. A block previewer so you can see what the textures will look like in the game. The funny colors and arrows are there so I could be sure to get the same orientation on the textures as you see in the game. (Fun fact: The bottom texture on most blocks is actually mirrored.)

One of the first things I had to do was add support for loading...

Fri, 03 Jun 2011 12:18:18 -0600

One of the first things I had to do was add support for loading images from a zip file. This picture shows my successful first test of that.

Tenative Plan for this month

Fri, 03 Jun 2011 10:46:00 -0600

I have this month set aside for working on Minecraft related things. (texture packs, my story, etc.) However, I still want to continue working on my GUI stuff as I think I’m making real progress with that. So I have decided to combine the two.

I’m going to do a stand-alone version of my texture mixer using the GUI elements I’ve written. This should give me a nice test of my design as well as give me an excuse to continue to add more widgets as I need them.

It should also keep the GUI development more interesting as I won’t just be going down a list of widgets. Having a real program to test them in is a lot more fun than just a screen full of widgets with some hacked in testing commands.

A shot showing the new button widget in it’s three states....

Thu, 02 Jun 2011 15:09:16 -0600

A shot showing the new button widget in it’s three states. The widget is the gray rectangle at the bottom if it isn’t obvious. ;)

End of month accounting

Wed, 01 Jun 2011 09:00:00 -0600

Progress was made on the GUI elements this month. I still have a few lingering bugs in the last class I added so I will probably work on trying to get that fixed off and on till I have it sorted to my liking.

Here are the things I got done:

Base Gui Class - base class for all my GUI elements
Event Handler - base class for any object that needs to handle events from the gui.
Font - A simple tool for drawing text to the screen. Currently it uses a bitmap font image in a 16x16 grid
Texture - A simple wrapper for images/textures. Supports re-loading the image into graphics memory if needed.
Panel - A very simple object with a background color, background image, and optional solid fill border
FancyPanel - Constructs its border by chopping apart a base image. Allows for more interesting borders.
VLayout & HLayout - Positioning objects that will resize their contents dynamically.
TextPanel - A container for text. It does word wrap and will scroll if too much is added but it does not have a history. It is simply meant as a way of displaying text, not storing it.
Button - The first interactive element. It is supposed to support changing it’s graphic when the mouse moves over it and when a button is clicked while the mouse is over it. Still working out the bugs though.

Here is what I still have on my list of things I want for my GUI elements:

Draggables - Elements that can be dragged around the screen by the mouse. Comes in two flavors, sticky and non-stick. Sticky ones would ‘stick’ to the mouse cursor after a click and would require a second click to release them. Non-stick would require you to hold the button down.
Resizable Pannel - Basically a panel with a Draggable edge/corners. What edges/corners are allowable for grabbing for a drag would be configurable.
Window - A complex composite element with a title bar, some standard window buttons for closing/resizing and a draggable frame
ScrollBar - A composite element comes in two flavors, vertical and horizontal.
ScrollPanel - A panel with built in scroll bars that can be toggled on or off for scrolling oversized content.