Mar 10

Project #3: IntelliWriter Update

A dictionary and 79 epubs walk into a bar…

IntelliWriter Logo

Word Suggestion Engine

This was the major theme of the first half of the work so far. After spending a few hours crawling the interwebs for someone who has done this in an open-source, information should be free, hack-the-planet kind of way, I gave up a decided I needed to do it myself. I took a hint from an old friend, Markov chains.  I needed an engine that when given a word, it would spit out a list of words that would most-likely come next. In this scenario, Markov chains basically say ignore everything but the word that comes before it and that works pretty well.

So! I grabbed a pile of almost 80 fiction books in epub format and wrote an analysis tool that calculates for any given word, what are the most likely words to come after it. Filter all those words with actual words from a fully resolved Open Office dictionary (which was a bit of a project on its own)…and done!

Here’s how we are looking so far:

IntelliWriter_update

Look good? I think it looks pretty good. The word recommendations are normally pretty close if not spot-on for this passage. There’s no tab-completion yet, which is really the linchpin to see if this little experiment is actually useful. Better get back to work!

The task list as it stands today, for posterity:

intelliwriter_taskudpate

 

Nov 08

Project #2: Mars Commander 32 (ahem) hour update

Mars Commander Bettererer

It’s fun!

Today on Project Update: a demo video! I have most of the Hub unit’s functionality completed as well as basic unit-to-unit connections. I use a mouse for the video below so you can see where I’m clicking, but the multi-touch testing seems to work just as well. I waited until I had just enough stuff implemented to see if it was fun (read: throwing new units and blowing them up) before doing an update. It’s fun! Well, I think it’s fun, but I am…biased.

Gameplay

To review, the screen is split in half with a player on the left (green) and a player on the right (blue). Ideally, this would be played on a tablet flat on a table with players facing each other. When first touching a Hub you’ll see an interface come up to select which unit to throw. The only units implemented right now are the Hub (top left) and the Bomb(bottom left). There’s also the Eye (top, second from the left) which is meant to expose areas of the field, but since there isn’t a fog-of-war yet, it doesn’t do much. After selecting a unit you’ll get to aim the throw and then launch the unit using a press-and-hold style. Each unit is connected to the unit that threw it with a string of little connectors.

In the interest of time, I disabled the cool-down after launching a Hub. Normally a Hub would not be able to launch another unit immediately after a launch and would have to wait about 30 seconds (you’ll see a short cool-down when you see the Hubs throw an Eye in the video).

Here’s how the task list is shaping up

Project2 Task List Update 2

Oct 01

Project #2: Mars Commander 12…err…17 Hour Update.

Mars Commander Betterer

A little over halfway into Project #2 and I have discovered two mistakes that will certainly blow my schedule.

Mistake #1: Framework, Engine, Game

Near the bottom of the technology stack is a game framework. This provides entities like textures, vectors, something that draws stuff, and the like. The engine stacks on top of that entities like sprites, physics, models, and other delicious goodies that hold up the eventual top layer that is game. Developers and designers can spend whole careers sitting comfortably in any one of those layers and a few (well, more these days with all the indies) live throughout.

MonoGame, the technology of choice for Mars Commander thus far, is a framework. I planned the work similar to Project #1 in that I would be building the game layer while naively ignoring the relatively minor but not insignificant engine I would need to build first.

Woops! My time log shows me about 16 hours in before realizing that putting the engine together sure is taking a significant chunk of my precious 24 hours. There’s not much I can do about this except to paddle out of the middle layer as fast as sanity will allow.

Mistake #2: Developing Touch with a Mouse

My initial interface design not only looked like a four year old drew it, but in current hindsight it made just about as much sense. As a painful reminder:

Commander Mockup

It is probably hard to tell…well, anything from the picture, but the intent was to have a control bar at the bottom of the screen that lights up with whatever controls are available for a selected unit in the playfield. I’ve essentially neutered and spat that magic that is a touchscreen and tried to turn it into a keyboard. A mortal sin if there ever was one. I need to apologize to all the super smart folks that gave us touch screens: SORRY, GUYS.

The NEW interface drops that stupid bar at the bottom of each player’s screen and puts all of the controls in the world on or near the unit selected. This will even allow for (gasp) multiple touches into the play area. Maybe even throwing from multiple units at the same time! Neat!

Regroup!

I feel I have about 80% of the engine components completed (sprites, touch handling, draw layers) which is enough to support a completed prototype so I’ll call those bits good for now. I’ve started implementing the interface for the HUD which should serve as a template for the rest of the units. I will definitely not make 24 hours on this kid, but it is more important to finish the thing at all then to throw it away just because the schedule slips.

She ain’t much to look at, but there’s a lot of good stuff behind all that orange:

Checkpoint screenshot

 

Aaaand in the interest of posterity, the task list as it stands today:

Checkpoint task list

Aaaaaaaaaaaand back to it…

Jul 19

Project #1: Eighty-Twenty

The last 20% of a project takes 80% of the effort. In the case of project #1, I have completed 19 hours with 5 hours remaining leaving me at the last potential 20%. The effort necessary here is not technical or even availability driven, it simply hard to prioritize and just do. It is an 80% of a spiritual effort that must be conquered in order to get past what marathon runners call “The Wall.”

Twenty-four hours is hardly a marathon. Who Goes First has shown me that, no matter how small the project, the spiritual wall is there. It is the design.

Do we shelve the git repo and put it on proverbial shelf? NO! Do we start something new and come back to it…”later”. NO! We take our laptop to the motorcycle rally and after 400 miles a day of iron-butt riding we pile up back-support pillows on the hotel bed, open the IDE, and finish the damn thing by the end of the week. I write this here and now as a promise forged in electrons to myself and to belief in a world where sanity may prevail.

 

(7/28/2014) UPDATE: Success!

Jun 28

Project #1: Who Goes First? 12 Hour Update

The Who Goes First? project hit 12.5 hours a few days ago which means it is time for a status report! The primary mechanics and flow are all completed and I have even had a few chances to try it out on some board gaming friends of mine. They had some minor feedback but all-in-all it looks to be something that isn’t insulting to the world at large.

It might look a little strange on an upright monitor since it is designed to be flat on a table with people sitting all around it, but you get the gist. The two major items left are a start screen (at least abstractly speaking) and audio. After that, the whole thing feels aesthetic flat so I’ll move on to trying to add some depth with the background and possible the foreground’s visual assets.

Construct2, by the way, is great! I feel like I have only scratched the surface on how to properly work within the tool. I’m sure I’m not doing state management in a reasonable way, but I must doing it partially alright since I’m not hating life this far into using it.

Who Goes First Construct2 Screenshot

Lastly, I spent a little time exporting the project to HTML5, Window 8, and Windows Phone 8 without much trouble. The next stop will be Android, Amazon, and…iOS, which I only preface with ellipsis because there are a bazillion (okay, four) different ways to get a Construct2 project onto Apple products. Also, not having an Apple product makes evaluating them difficult.

Next update should (hopefully) be a release!