Project Wellinghall: M3 design complete

While M3 planning was completed last week, parts of the plan had not been fully detailed in terms of the game mechanics or implementation.  That design work is now complete, as it most of the refactoring to use a proper logging mechanism.  The first phase including 3 refactoring work items and 1 new features.

The second phase is to put in some internal consistency checking to ensure a steady state is maintained (i.e. that no energy disappearing or materializing out of no where).  I want to get that done before I spend time on balance to ensure that balancing work isn’t wasted on buggy game mechanics.

The third phase is the balancing phase, which includes creating the scenario manager and 3 then 3 new features.  Before implementing those 3 new features, I wan to have the scenario manager in place so that I can effectively evaluate the impact of the new features to see if they are either overpowered or useless.

Project Wellinghall: M3 planning complete

I finished up the planning for M3 earlier this evening.  Most of the engineering tasks did get pushed from M3 into what had been the empty bucket of M4.  The one I did keep was to add a decent logging infrastructure and replace various statements to print to the console with proper logging.  Late in M2 I started to accumulate a lot of these print statements in my efforts to verify and debug the game mechanics, where in my work previous to that the print statement were only short lived,  so they didn’t cause problem.

Also included in M3 is the tool, which I mentioned previously here, that I’m lamely calling the scenario manager.  I anticipate the scenario manager will be of great help in getting a feel for what kind of game reality the individual game mechanics come together into.  Should that game reality seem wanting of the balance necessary to be fun, then the scenario manager will be very helpful in quickly determining how a tweak to a game mechanics effects the overall game reality.

At this point I’m just looking at the game reality in terms of whether it provides for a fun environment in which to design an automated combatant to duel another automated combatant.  For this to be fun for me, the designs for the top units should not follow a single attribute to extreme (i.e. being the biggest, the fastest, or the most enduring shouldn’t be the win button).  Also there should not be one unit design that can beat all comers in all scenarios at all starting distances.  Going a bit further I hoping that there won’t be one unit design that can beat all comers at a specific starting distance, but its possible that may not be doable.  At the same time I’m not trying for a rock, paper, scissor type balance where each unit design has a design it is strong against and one it is weak against.  I’m fine with some designs being generally better then many others, just so long as it isn’t better then all of the others all of the time.

Now I’m off to go survey what my existing logging options are in Python, so I can either pick one or rule out using a pre-existing one and get one with writing my own.

Project Wellinghall: M2 complete; M3 planning begins

I spent the day trying out numerous dueling scenarios to get a feel for how the game mechanics. After designing a succession of better units, I think there is likely room from improvement in the game mechanics. I’ve also decided that investing a lot of effort in tweaking the game mechanics with only the M2 feature set was not wise, as based on my experience today I think about half of the features I have planned for M3 really need to be implemented to get a more solid handle on how the game mechanics will play.

When I re-planned M2- M4 after re-designing the game mechanics at the end of M1, I left M4 empty and M3 had very little in it. Since that time, M3 has had a couple more features added to it in addition to a number of engineering tasks, while M4 has remained empty.

Currently, I’m thinking I’ll move the other half of the M3 features, which do not appear necessary to tweaking the game mechanics, off into M4. I also need to weigh the cost of the engineering tasks against their immediate benefit. Although a number of the engineering tasks will help with debugging and the time it takes to understand the impact of a tweak to the game mechanics, but I’m not sure the time saved will be offset by the cost in the short term (long term sure, but there may not be a long term for this project if the game mechanics prove fundamentally flawed).

So my next step is to generate SWAGs for the engineering tasks.

Project Wellinghall M2: Coding complete, now for some tweaking

I just crossed off my last work item for M2 of Project Wellinghall and then spent an hour playing around with the fruits of my labor. One thing that is clear is I need spend some time writing some code that generates a bunch of tables so I can get a better handle how all of the game mechanics interact. I have got a bunch of knobs and levers I can tweak in the game mechanics, but currently my view on how things change in response to a tweak is rather narrow as I currently only have one scenario and that pits two very similar combatants against each other. I’ve also got various numerous spreadsheets I’ve created manually as part of my game design process, but each table only deals with one aspect of the game mechanics, so I need create a tool to generate a wide variety of scenarios, get them executed, and then summarize the results into numerous cvs format tables for easy spreadsheet viewing.

At present I’m just trying to decide if creating that tool is work that remains in M2 or if it goes in M3. If it goes in M3, then I need to decide how much time to spend manually messing around with the features I have now before calling M2 done and moving on to M3.

I think I’ll spend tomorrow playing around with it and then see where to go from there.

Time for a colloborative game project

In my last post I mentioned that it was time for me to start working with other folks again, that I was posting my resume to various sites, that my expectations of finding a good position were low due to the current economic climate, and that I was going to wait until after I finished M2 of my current game project before actively looking at job postings.

During the last week, I couldn’t resist reviewing current job postings and the state of things is even worse then I thought. Additionally, the posting of my resume online has generated contacts (and spam) with recruiters but not from employers.

I figured that working with other folks again meant that I’d need to find position at a company, as my current project is both large in scope and radical in design, which makes it a hard sell in my opinion and I’m a craptacular salesmen. Thus, I see it as highly unlikely that I’d be able to recruit any partners for this particular project until its far enough along to sell itself and that is months off at best. I also can’t afford to hire an employee to work on the project.

That said it just dawned on me that I could collaborate with other folks on a new game project rather then my current one. A few days ago I decided to try my hand at writing some fantasy and science fiction, and in brainstorming for that effort I came up with a couple of ideas that I just realized would be well suited for a game that wouldn’t require hand crafted textures and fairly minimal amounts of models, animation, and landscape. So while these ideas could not be used to create a game without any artists being involved, as is the case with my current project, large off-shore teams generating content wouldn’t be required to complete a game either.

So my next step is to contact some folks to see if any have the interest and spare cycles to take on a side project like this. If not perhaps I can find some collaborators in the forums of game development websites.

Time to start working with other folks again

After some reflection on the last year of doing solo software development, I’ve come to the conclusion that working solo does not allow for maximum productivity, that maximum productivity can only be achieved when working as part of a group, that I a get a lot of satisfaction from being maximally productive, and thus it is time for me to start working with other folks again.

That said, over a decade of experience developing software as a member of groups of various size has also shown me that working as part of a group can also result in productivity significantly below that of working solo, that I find working at low productivity to be unsatisfactory, and thus I should not join just any group of folks developing software.

Economic times are pretty bleak at the moment, with rumors of Microsoft laying off a significant number of people and Google engaged in stealth layoffs, so it could be quite difficult to locate software development groups that are, highly productive, actually looking to employ more senior software engineers, and either don’t screen candidates using lists of acronyms and buzzwords or are screening for a list of acronyms and buzzwords that match up with my personal list of acronyms and buzzwords.

So the first step is to get my resume posted to about dozen tech job related websites and see if that generates any leads as a result of getting through the screening filters of a group that is actually looking to employ a senior software engineer.  While waiting I plan to finish up the second milestone of my current project, so I can get that finished up before I start dedicating a lot of time to searching for an appropriate position.  When the time comes for that I figure the first step will be take a look at the positions available that require Java and C# and determine which language has more open positions of interest (not just total number of positions Java wins there) compared to C++ to determine if I should be investing time into learning one of those languages and their associated libraries to expand my personal list of acronyms and buzzwords.  The other thing to look at are jobs in the gaming industry as perhaps learning libraries related to that is the way to go, as C/C++ are still the languages of choice for shrink wrapped console games (with a notable exception being XNA for the 360 since that requires verifiable .Net).

I’m confident in my ability to pick up any of these things, but I can’t learn them all instantly.  I’d be happy to spend a few unpaid months learning languages, libraries, and technologies required by by a great position if I knew it was still going to be there for me at the end my self-training period, but the job market doesn’t work that way so I’ll end up having to to speculatively choose where invest my time and how that time isn’t wasted.  With all of the choices available these days it would be pretty easy to pick the wrong areas to invest in.  For example a search on Indeed yields only 1,684 results for “Python Senior” versus 8,876 results for “C ++ Senior” and13,970 results for “Java Senior”, but of course when I started working with Python it was not to improve my marketability in the job market, but to provide for high productivity development of the game engine prototype I’m working on and Python has fulfilled that role quite nicely.

Personal preference for geometry coding

I started fiddling around with the rendering engine for Project Wellingham as my entry point to getting back into that code base, and in short order I realized that I really liked working with geometry related code and that I’d been missing such coding while I was working on Project Fangorn and my stock analysis software before that.  Although Project Fangorn was a strategy game, I had purposefully designed it to not make use of any geometry to keep it as simple as possible considering it was going to only have an HTML interface, so I didn’t get the same level of satisfaction working with those game mechanics as I do with game mechanics that utilize geometry.  Of course I didn’t actually realize it at the time and attributed most of my lack of satisfaction with working on that project to frustration with the limitations of Google AppEngine and in hindsight I can see now that I really should have tossed in the towel on that project back in early October.  Oh well, live and learn.

For those of you who read this blog regularly you may notice that the title has changed from “Josh Heitzman’s Impersonal Blog” to “Josh Hetizman’s Blog O’ Code”.  When I originally started this blog, it was because my wife didn’t want me putting up long posts about my work on shared blog about our activities, family visits, photos, etc., so I considered our shared blog to be for personal stuff and this one to be for work and technology related posts (i.e. impersonal).  At first I wasn’t going to post this as it didn’t seem consistent with the blog title, but then it occurred me that there was no reason I couldn’t just change the title.

Project Wellinghall back underway

As Project Fangorn, a light weight web-based strategy game, has been put into the deep freeze and I’ve taken some time off to do some game playing, it is time to dust off Project Wellinghall and get back to work in it.  I stopped worked on Project Wellinghall a bit over six months ago (5/22/2008 to be exact) when I started working on stock analysis software with this being my last post on the subject.  At the time I didn’t actually call it Project Wellinghall, but having a code name makes it easier to refer to, so I went ahead and gave it one retroactively.

I have no shortage of written game design, planning, and current progress documents relating to that project and specifically to M2, so I won’t have to wallow around trying to figure out where I left off; however, I do have over 50 pages to read to get back up to speed.

Time to make some tea!

Compile C and C++ (and Python) code for the Flash platform

Just discovered Adobe Alchemy, which allows C and C++ code to be compiled for the Adobe Flash platform. For me anyway, this shines new light on the Flash platform, as this allows apps to be developed for Flash in widely used general purpose programming languages, which in turn allow the re-use of existing libraries and the sharing of app specific code between the Flash platform and other platforms (like the desktop if you have a standalone client as well as flash client for your service).

This had me wondering if there is a Python equivalent as well, and although I couldn’t find one there is the experimental shedskin that complies Python into C++ and of course there is the PyPy project that can compile Python into C among other things (CLI, JavaScript, etc.). In the future PyPy may be extended to compile Python into AVM2 bytecode, but for now it looks like it would be a trip through C first.

Project Fangorn postmortem

Now that Project Fangorn is wrapped up and on ice, its time for the postmortem.

What went wrong:

• Didn’t feel like I was productive enough.
• Went off on a tangent developing a prototype space based architectural abstraction over Google AppEngine’s datastore and refactored prototype code to use it.

What went right:

• Produced space based architectural abstraction over Google AppEngine’s datastore that can be used in other projects.
• Produced tests for space based architectural abstraction than be used with other implementations.
• Produced server-side test framework and client-side test runner that can be used with other projects.

What to do differently next time:

• Make a task list with time/size estimates even when it isn’t necessary for coordination or reporting to others.
• When not working regular hours, meter time enough to get a reasonable estimate of how much time is actually being spent working per day / week / month. This require either finding or developing suitable metering app.
• Don’t develop prototypes for web applications on GAE, but rather do it just a basic web server setup. Although prototypes for specific technologies might need to scale, feature prototypes don’t need to scale.

During the course of the project I kept feeling like I was behind and not getting enough done, but I don’t actually know if that is the case or not. This arises from two factors. The first factor is that I’ve been working throughout the entirety of the day, but it hasn’t been non-stop work but rather intermittent (i.e. work for a while, go excercise and shower, work for a while, grab some chow and watch TV episode or two, work for a while, etc.). I also haven’t been taking weekends off, but just a day here and there (at Thanksgiving is the first time I can remember do no work for two consecutive days since I went to visit family on Labor Day), so I really have no idea if I’ve been working 30 hours a week or 70 hours a week. At one point I actually went looking for a simple app I could use to track time in a few buckets, but couldn’t locate anything that did what I was looking for. The second factor is that I didn’t break down the work into tasks with a size/time estimate, so I wasn’t getting the satisfaction that comes from checking off completed tasks nor did I really have a bearing on overall progress.

While the space based architectural abstraction over GAE’s datastore API will be useful on any other project I do on GAE, the tests for it will be useful creating other space based architectural abstractions, and the test infrastructure will be useful on any other Pylons project I do, I don’t believe it was appropriate to be developing these things during the course of developing a prototype for a web strategy game. I really should have just shutdown work on Project Fangorn and moved on to developing those things separately from it, as I had gotten enough experience with the limitation of GAE to know that there was a significant risk of it not being feasible to successfully operate Project Fangorn on GAE. Either, that or should have restarted Project Fangorn on another platform.