| Ruminations on Balancing a Simulation |
[Nov. 17th, 2009|08:45 am] |
Last night I sat down to balance the dynamics in the game "Strike!", described yesterday. I thought it'd be a simple task. I ended up pondering some stuff from mathematical modelling.
Let's start simply. Imagine we have two quantities, x and y, and the change in each one of them as time passes is dependent on the values that both of them hold. So, for instance, It could be that as one second passes, the value of x grows by half of y added to half of x.
dx/dt = x/2 + y/2
The thing with "d" in just means change in x as t changes. You'd get something similar with y, maybe:
dy/dt = 2x + y/4
This is a two-dimensional system (x and y), which is handy, as it means we can visualise it fairly easily. Now for various co-efficients of x and y in the simultaneous equations above, the behaviour of x and y, from various starting points, can take on a whole number of patterns.
This one below is called a spiral source:
Now if you imagine my game, a simulation of a railway company, and the fact that it has about 20 variables: x, y, z, a, b, c..... representing things like reputation, ticket sales, staff morale, union anger and so on, making it perhaps twenty-dimensional. I appear to have configured it so that it's a spiral source. Initially it veers slightly in the direction of profit, then careers off into certain corporate doom. There are things that can by done, user actions, that can make a small difference, but it's very much locked into the spiral pattern.
Ideally I need to alter it so that it looks more like this:
....only in a twenty dimensional configuration-space, so that the company is sustainable, but doesn't degrade to a fixed point.
EDIT: It occurs to me that the classic solution here would be to express the rules of the simulation as a matrix, take the eigenvalues and find a stable solution. I may just tweak it until it works instead :-) |
|
|
| Due tomorrow! Strike! |
[Nov. 16th, 2009|12:36 pm] |
Last Friday, things on the First Capital Connect commute that I take from St. Pancras to Streatham had gotten completely unreasonable. Half the trains were cancelled because the drivers were refusing to work overtime. I was pretty exasperated.
So - I had train journeys to and from Manchester this weekend - I took my Asus and made good use of the time:
I'll upload the finished thing tomorrow. It's nearly there - just need to make some tweaks to the balance, add some small randomness and flesh out a couple of the menu options. The game reminds me a little, bizarrely, of "Yellow River Kingdom", and was inspired by a game for the Atari 800 that I must have played 20 years ago and involved taking the part of the union and deciding on strikes etc. This one's the other way around :-) |
|
|
| Times Table Cards |
[Nov. 11th, 2009|06:34 pm] |
Just a quick additional post. My daughter is having some trouble with her times-tables, understanding the various concepts, and memorising the various results. She's a very tactile learner, so I had the idea that I could create some "playing-cards" to help her learn.
The three-times-tables are here, others to follow.
To use them, instruct your child to cover the back of the A4 sheets with Pritt-Stick (or whatever it's called elsewhere in the world) and fix to a sheet of thin cardboard. Then you can cut them out together.
|
|
|
| Maintainability (Part I) |
[Nov. 11th, 2009|01:19 pm] |
I tend to end up in roles where new work is being performed. Maybe a new department is being created, or an existing department is undergoing an overhaul, or a new IT system has been introduced. Generally, and particularly in the latter case, this involves the creation of ad-hoc databases or reports.
This sort of thing crops up with depressing regularity: Often, during the scoping phase for the system or process, no-one thought about getting sensible data out of the system for the purposes of reporting. This means that the question of data analysis only crops up a couple of days after "go-live", when, inevitably, a contractor (or an internal non-specialist) is dragged in to pull information from the back-end database. And it's needed *now*, which means that it matters little how the demand is met.
This brings me to the topic of maintainability. In situations where a manager has less technical knowledge than the guy in charge of the new reporting "solution", and doesn't follow industry standards on best practice, we see these sorts of things:
i) Mass of impenetrable Excel reports with indecipherable VBA spaghetti code providing half the functionality.
ii) Reports saved in 23 different locations across local hard drives and network shares, no central record of where or what they do.
iii) Reports using SQL script that points at a direct copy of the system backend. Of course, once version 2.0 of the software comes along, the backend database changes and tens of thousands of man-hours' worth of work becomes either useless or in need of serious overhaul.
iv) Vastly costly (time-wise) manual data-maintainance procedures which only one person understands, or worse, local bespoke scripts designed to do the job.
and consequently...
v) Single points of failure who cost a great deal of money to maintain (and even more to replace).
For now I'll ignore the classic system-killing direct-backend SQL query, as it's outside of the scope of this post. The upshot of all of this is that in a situation where a new system is being introduced, it's essential to understand how management information will be obtained, and factor the development work around this into the project plan.
In anything resembling a serious project, ideally some form of proper data-warehouse ought to be designed and introduced, and set up with ETL routines that can be recreated quickly when the source database(s) change, so that reporting functionality isn't affected. Obviously the whole thing should be meticulously documented while it is in the design stages.
A decent reporting tool (Business Objects, for instance) can then be introduced to allow managers to have on-demand access to standardised reports.
All of this sounds utterly obvious, but it's amazing how unusual it can be. In my second post on this subject, I'll take a look at what other people have written around the subject, and at how it fits into ITIL.
|
|
|
| Python for OpenOffice Draw |
[Nov. 10th, 2009|01:38 pm] |
In a recent post I mentioned that I was looking into exporting data from OpenOffice Draw into another format. I've had a look on the web, and I'm pretty amazed by how little has been written on this subject. The majority of extensions seem to be written in Java, and most tutorials are aimed at that language, or the internal BASIC.
So it seems like the web is crying out for a tutorial on using Python to write extensions for OpenOffice Draw. Well, if I can work it out, I'll write one. |
|
|
| Flowchart Interchange Format |
[Nov. 6th, 2009|01:50 pm] |
One of the shortcomings of OpenOffice Draw (another that can't be ascribed to the programmers) is that is doesn't export files to Word very easily. If you put together a flowchart (for instance), it loses all formatting and cohesion if you export it to Word via OpenOffice Writer.
I'm looking at ways of sorting this out, more as an exercise than as anything particularly immediately necessary. It is possible to export the file as a bitmap, then open it in Word, but that makes the file extremely heavyweight, and means that people with Word can't open the document and edit the flowchart.
I think the solution might be to export the file into an intermediate XML definition (of my own devising) using some Python code in Draw, then import the XML into Word using VBA. Now assuming that we write the import code in a rigorous and sensible way, this should give us a nice, attractive, flowchart rather than a horrible one that you get with the old method. It also means we've invented a graphics format in the meantime as a plus! More on this as it happens. |
|
|
| Newish IF Project |
[Nov. 5th, 2009|06:00 pm] |
While I was on holiday in Madeira earlier this year, I had what I think is a rather good idea for a new piece of Interactive Fiction (or a text-adventure to our 8-bit ancestors). The plot has to remain a secret for now, but I'm greatly enjoying writing it and I'm up to something like 130 rooms and as many items.
At the moment I don't know how long it'll take to finish, but it'll definitely take some beta-testing once it's done, so if anyone reading this would like to volunteer, I'd be very grateful! |
|
|
| Monster Panic Early Screenshot |
[Nov. 5th, 2009|02:08 pm] |
Recently I promised that I'd post a screenshot of the new "Monster Panic". So here it is:
There are still a few things missing - one aspect of the game is a timer. If you haven't finished a level before the timer runs down to zero, you die. The time-bar needs to be added in-between the score and the lives left. There are some other features I'm planning on adding: Springs and moving platforms. I'll see about those as soon as I get the time - they need to have coding added to the level-builder so we can design stages that incorporate them as major features of puzzles and so on.
Another point to note is that the graphics on screen in this shot represent a tiny subset of the stuff that is available and will make it into the final thing. But you'll have to download it when it's ready to see those!
One thing that did occur to me during the development of the game in python is that is would be technically straightforward to make the levels much larger than the area of the screen - to build large areas and let Jack (our hero) explore with the view scrolling around the larger level as a whole. One for Monster Panic 2? |
|
|
| OpenOffice Python Scripting |
[Nov. 4th, 2009|01:08 pm] |
Playing around with the Python functionality in OpenOffice today. After doing a "Find File" to work out where everything sits in the tree structure, I found this:
The section above adds a "Hello World" to the end of a document. I guess there's a guide to the internal API online, it'll be interesting to see how easily you can throw data around in "Calc", the spreadsheet.
I've been considering extending the Erlang-C (Queueing Theory - used for working out how long the waiting times will be if you're running a service with finite capacity) functions that I wrote for Resolver One to take in general queueing theory. Given that the two work in Python, it'd be easy to make them available for both platforms. |
|
|
| Monster Panic |
[Nov. 3rd, 2009|01:39 pm] |
Some time ago, I began working on a platform game called "Monster Panic". Wyc Tippins (![[info]](http://l-stat.livejournal.com/img/userinfo.gif) explodi) did some great graphics, and the code got pretty far before life got in the way and the project went into an extended holding pattern.
Well, I've finally got round to restarting the project. I have rewrittten most of the code in Python, using the PyGame library. It's going very well. I now have an extensible level design system, most of the (rudimentary) physics in place, and the music is nearly finished.
I spent Saturday morning tidying up the code and giving the main character the ability to dig holes with his pneumatic drill. Later in the day I downloaded MilkyTracker, and set about creating music for the game. I've not created MOD music in fourteen years, so the experience was something of a blast from the past.
One glaring omission at the moment is in the sound effects department. I'll be using SFXR, which I discovered by way of the "Ludum Dare" games-writing competition, to try and make some noises that are vaguely appropriate.
I'll post further updates as things progress. Next: Screenshots. |
|
|
| OpenOffice Draw |
[Nov. 3rd, 2009|09:19 am] |
From time to time it's necessary for me to draw up process maps - whether to work out exactly what a particular department are doing, or to put a new process in place, and I've always used Visio in the past. It has its faults, but it does the job well enough.
This time, however, I needed a visual tool quickly. I've used "Dia" in the past, and wasn't too impressed, so after a bit of a quick search on the internet, I decided to download OpenOffice. The first thing that struck me about it was the small download. At 150Mb I succeeded in downloading it on the third attempt on our throttled net connection.
The second impression that I got was the polish on the program nowadays. I used Open Office around five years ago and it really didn't look terribly hot (it also succeeded in mangling some Word documents, but that's hardly the fault of the Open Office guys, the standard's not exactly open). This new version, 3.1 really looks good.
Now my third impression - and this is the important one - is that I would use OpenOffice Draw over Visio in a flash. There are areas where it could be improved - for instance, changing the size of a font and turning on text wrapping are achieved through totally different menu options, which is pretty clunky and annoying, but for the most part it's a lovely experience and I'll be sticking with it rather than wasting £x of the organisation's money on a Visio license.
That said, if it comes time to draw up a database diagram, I'm not sure how well Draw will fare. I'll cross that bridge when I come to it. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
