Back to Regular Expressions

So way back when I wrote this post, I mentioned I was working on a regular expression parser. I put that on the back burner for a while, but decided to revisit it this last week. I based my implementation on this article. I felt pretty pleased with myself once I got it working, though I'm still working on submatch tracking. Once that's done, I'll be able to use it to parse text based files like OBJ and PLY.

I feel like I should address why I'm not using any 3rd party engines or libraries. It's not exactly a wise choice for a game developer, especially for an indie. I don't really have a good reason beyond that I don't want to. I want to use this time as much for learning as for game development, and I enjoy tackling these sorts of problems. I like doing things my own way, and I get a certain kind of foolish pride out of knowing that all the code was written by me. Good choice or not, I'm going to stick to that.

Updated Concept Sketch

Well, I didn't end up spending much time sketching, but I did manage to whip up some better concept art for the basic robots. Considering all the dust on Mars, I'm pretty sure that this sort of robot would do really poorly on the planet. Fortunately, I'm much more concerned with making the robot adorable.

Considering how often I have little to nothing to write about in these posts, I've decided to try switching to weekly updates rather than daily. Hopefully this will mean longer, more interesting posts. So from now on, I'll be doing a post every Tuesday.

The Job Process

Finished up the revisions to pathfinding. I've been thinking about how to get the robots to automatically pick up and finish jobs, and this is the process I'm going to use.

1. Create job at location. Jobs have required resources and required labor.
2. Find the nearest available resources and create a hauling job for each one.
3. Find the nearest and most qualified robot to complete the job.
4. Once all resources have been gathered, signal the robot to come complete the task. 

In general, jobs may depend on other jobs being completed. Most will require at least one hauling job to move something from one place to another. The only part of that process I'm still shaky on is finding the best robot for a given job. For example, how far away does a well qualified robot have to be before it's better to just pick a nearby under qualified robot?

Variation

Still refactoring code, but making good progress. For one thing, there can now be multiple terrain types. The grid is now fully 3 dimensional. Pathfinding will now consider not only the tiles the bot is moving through, but the tiles it has to move over as well. Objects and units have been consolidated into a common type, and there can now be multiple objects on a single tile. Basically, all changes under the hood. It's not much, but here's a screenshot showing off multiple terrain types.

And On the Seventh Day, He Had a Hangover

Well, it's a little late for a 'morning' post, but here it is. I had a great time at my friends party. So great in fact, that I spent all of Sunday recovering from it. I did, however, get a lot done before the party. Unfortunately, that mostly involved refactoring, so no new screenshots. Still working toward getting some AI and having a better rendering pipeline. Made some changes to the way pathfinding is set up, which I'm hoping will be more efficient and flexible. That's all for now!

Architecting Robot Intelligences

TL;DL, it's going to take me a while to get real, interesting gameplay, so I'm putting last week's goal on hold. I'll still be working on it, but I'll focus on other things in my posts until I get a little further along.

Did some more work on fleshing out a rendering pipeline today. It's a little new for me. I'm familiar with graphics programming, but I've never had to set up a pipeline for it. The projects I've worked on either had someone else working on that or were too small to need a robust pipeline. It's an annoying problem because there is an absolute 'best' solution (fewest possible GL calls), but in practice, it's better just to settle for a 'good' solution.

As far as actual gameplay goes, I did a little work on that as well. You can use the menu to create build orders now, but I still have to write some AI to make the robots actually carry out those orders. And the more I think about it, the more I realize that that's going to take a while. Since orders can be scattered about the map arbitrarily, I need some way to determine which robot is closest and most qualified to carry out the order. In principle, there could be obstacles in the way (for example, a wall that you had built earlier), which means it's more complicated than just picking the closest robot.

I also need to somehow keep track of which robots are working on which jobs. The robot needs to know so it can work on the job, and the job has to somehow be marked as 'in progress' so that other robots don't take it. Additionally, resources are needed to complete jobs, so those have to be moved to the job site, meaning that I need to give the robots an inventory.

No post tomorrow, I'll be out with friends. And I think I'm going to start writing posts in the morning rather than before bed, so next post should be Sunday Monday morning.

Debugging: Hours of Hard Work Just to Break Even

Today I fleshed out the GUI system and made it usable. I added in a sub-menu to test it out; it should be easy enough to fill out the items as I need them. Aside from that, I got sidetracked with a handful of annoying bugs that took a while to track down. One was in my bitmap importer. It was turning some of my textures red. There was another with a small change I made to the input system. Turns out I just wasn't calling the function. The goal for tomorrow is to be able to order robots to be built. Not sure how long it'll take me to write AI for the bots to actually carry out those orders. I've been playing a little Dwarf Fortress in my spare time hoping that I might pick up some ideas on how to implement it. Additionally, I headed into the city and had a few beers with some people I know, because it's important to leave the house occasionally.

Uneventful

I'm trying to put together some kind of event system for the menus. It's making me miss C#. I love C++, but its pretty much terrible when it comes to event driven systems. The whole thing's proving to be a bit more tricky than I anticipated. I've never really thought in depth about how to make a good GUI from a programming perspective. Will continue working on it and have another post tomorrow.

What's On the Menu

Today I renovated the text renderer. Once drawing text was no longer a huge hassle, I started working on the GUI and now I finally have one! The buttons don't do anything yet, but they're there and they're being drawn. Here's a break down of what each button is for:

• Log - Opens up the mission log. This lists important events in the order they have occurred.
• Construct - Choose robots and/or buildings that you want built.
• Orders - Order your robots to perform certain tasks, like mining and paving roads.
• Stockpiles - Designate where resources and other items are to be stored.
• Mission - Checklist of mission goals.
• Robots - A list of all your robots and what they're doing.
• Jobs - A list of jobs in progress and which robots are working on them.
• Priorities - Order the importance of various tasks.
• Status - General status.

Obviously, those are all subject to change, as is the layout and sizing. Tomorrow I will work on getting the buttons to actually do things.

Slow and Steady

Didn't get a whole lot done today. Some, but not a lot. Slowly dissecting a giant main function into proper classes. Did some thinking about how I want to do the GUI. Worked on improving text rendering a little to make working on the GUI easier. Been making slow progress these past few days, but progress nonetheless.

All Work and No PLY

Whelp, I got sort of sidetracked today. I figured I'd work on writing some code to import models. I started an OBJ importer a while ago, but abandoned it. I worked on it briefly, but then decided to look into some other formats. I've written an FBX importer before. I'm not a fan of the format, for many reasons. I'm in no hurry to use it again any time soon. Additionally, I'm planning on using Blender for modeling. While Blender does have an FBX exporter, it doesn't officially support importing FBXs, which is inconvenient to say the least.

So I looked into STL and PLY. It didn't take long for me to dismiss STL, but I was quite taken with PLY. I started writing an importer. By the time I had nearly finished it, I had started thinking about how often I seem to write parsing code and decided it was about time I just wrote something that can handle regular expressions. By the time I had done a little of that, the day was spent.

I'm not sure how much more time I'll end up spending on those things. It may be a few days, or I may set it aside for a while and get back to focusing on the game. In any case, I'll leave you with an appropriate comic from XKCD.

Another Day, Another Blog Post

Not much of note happened today. I've mostly been refactoring code. Which is to say, I've been fairly productive but have little to show for it. My goal for the upcoming week is to have all these things happening:

• Player can create orders to build the Basic and Solar robots.
• Robots automatically carry out these orders.
• Solar robots gather energy from the sun.
• Other robots receive energy from Solar bots when they're running low.

Once I have that much, it should be easy to build more off of it. I also thought up some more possible resource types: hydrogen and carbon. Plastics are mostly made up of these two elements. Thus, these elements would go into 'fast' robots (to complement silicon for 'smart' robots and iron for 'strong' robots). Hopefully tomorrow's post will be more interesting.

A* is Born

I finished up implementing A* today. There were a lot of bugs I had to work though, but it seems to be working now. There's still a minor bug left. Under certain conditions robots will go through an extra square. It's weird, but predictable and doesn't break anything so I'll look into it later.

For those familiar with A*, I'm using an unusual heuristic that I learned from one of my professes in college. The robots can only move to adjacent squares, diagonals included. The heuristic returns the shortest possible distance obeying those rules. It's cheaper than Euclidean distance, but more accurate than Manhattan or Chebyshev. Incidentally, because the robots can only take those kind of paths, the heuristic is also admissible (it'll never over estimate the distance).

I've also added a travel cost to each tile. This can be used to make tiles more difficult to travel through. For example, rocky terrain would have a higher cost than paved roads. Here's a picture of the pathfinding in action. The black tiles are walls, and the green tiles are the tiles considered by the algorithm. The robot is moving from left to right.

How Shall I Path to Thee, Let Me Count the Ways

Worked on pathfinding today. I'm a little disappointed in myself that it's taking me more than a day to implement A*, but in my defense, I was trying to be clever about it. I want the game world to be as close to Mars in size as possible. Obviously, I'm not going to be pathfinding for the whole planet at once. I plan to only simulate the area the player is focused on at any time, while approximating time passing in other areas. However, the more efficient I can make things, the larger the area I can surround the player with. For now though, I think I'm gonna strip it down and make things simple. I can complicate matters later.

So It Begins!

So after saving lots of money and quitting my job, it's finally time to begin making an indie game! An endeavor that will hopefully become my career. I'm excited and terrified, but hopeful.

For months I tossed around game ideas in my head, but I eventually settled on one: a game about terraforming Mars with self-replicating robots. The game will focus on resource management, and will play somewhat like Dwarf Fortress. The player's job is to plan and issue commands, which the robots carry out automatically.

I expect the project to start slowly. The first few weeks will be likely be dedicated entirely to research and design. I'd like to try for daily updates on this blog. I probably wont have much to say in the first few weeks, but I want to get in the habit.

I've done some brainstorming and research already. Today I started refining those ideas and fleshing out the details. Robot types, resource types, player goals and actions, etc. In particular, I'm also considering the 'big problems' of terraforming. The long term player goals that need to be met. These include things like raising the temperature, improving the atmosphere, shielding from radiation, etc. All large-scale actions will have multiple effects; some good and some bad. An important part of the gameplay will be balancing the effects of your decisions.