The first game to be launched in this section is the ‘Draw Something’ game. We pick some ‘fantastic’ (some genuinely are, some are evidently not ;-)) examples of user drawn images from Draw Something.
The aim of the game is to be the first one to comment with the correct answer – and don’t forget, no cheating!! ;).
DPS David will decide the winner for each post and update the points table accordingly.
Have fun and good luck!! :).
Yesterday, all of the servers for the iPad game Chronicles of Merlin (CoM) mysteriously disappeared. It was around this time that the latest update for the game was released – whether this is a coincidence of not is not known, but it could provide one (albeit hard to understand) explanation for the disappearance.
CoM has been blighted by errors recently, and the release of version 1.35 of the game hopes to solve many issues. DPS Computing can verify the the ‘disappearing’ time for farm occupation has been fixed and the games stability seems to have improved somewhat.
However, one of the major bugs, the alliance crashing bug has still yet to be addressed (as far as we know, as it wasn’t mentioned in the developers comments regarding the update).
Altogether there have been around 12 bugs and errors that have been claimed to be fixed and although all bug fixes are welcome, it still seems like the game has some issues with regards to stability and crashing on the iPad.
Having said this, the recent update has addressed more issues than the last update and doesn’t seem to, so far, in testing have created any new errors as happened with the previous update.
The alliance bug still is the most pressing bug with the game and players will be hoping that this is top of the developers priorities for the next release.
In the previous article we discussed the iterative design model, which leads very nicely onto the topic of rapid application prototyping.
Rapid application prototyping is the main model used for iterative design. It is also the model that is most suited to iterative design. Rapid application prototyping is a dynamic method of software development, contrasting to the more linear waterfall model, which we have also discussed previously.
Rapid application prototyping will involve several iterations of the software development process, as with other iterative models. The production of prototypes is not intended to be fully representative of the final system. In fact the final system may be very different from the prototypes. The focus isn’t so much on the prototype itself, but what we learn from the prototypes.
A prototype is a representation of an idea or a system (or part thereof). It may be a full mock up of the system. Equally it may just focus on one or two features of the system.
Prototypes are a very useful tool, especially when working for a customer or company which doesn’t have a lot of technical expertise and experience. Non-technical customers find it hard to understand complex design documents, technical specifications and modelling diagrams. However, they find it much easier to see and interact with something – such as a prototype.
There are two types of prototype – throw away and evolutionary. Throw away prototypes are, as the name suggests, “thrown away” after they have been developed, tested by users and then evaluated. The next prototype is then created based on the results obtained from the evaluation. With an evolutionary prototype the same steps are followed, but the prototype isn’t thrown away. The results and knowledge gained from the evaluation are reincorporated into an updated design which is then used to update and improve the prototype.
The ultimate aim of rapid application prototyping is to create the best system possible, over as many iterations as it is possible to fit within the defined project time.
The benefits of prototyping can be very large – it might make it obvious that the final system would not function correctly or not be fit for purpose. It may indicate that certain planned functionality isn’t possible on the target operating system or company network environment. It’s better to find out these things sooner rather than later!
Further to our previous article on the Waterfall Model, we will now discuss interactive systems design using an iterative model.
The iterative design model is a fairly new model when compared to the waterfall model, however it is growing in popularity for a number of reasons. Firstly, what exactly is the iterative design model?
The iterative design model is a dynamic model of design that involves multiple iterations of the design process, rather than just one (such as in the Waterfall model). The iterative design model implies repeated design, implementation and evaluation of a system. An aspect which is often feature in and works well with iterative design is prototyping, in the form of rapid prototype development. Iterative design also lends itself to User Centred Design (UCD).
Rapid prototype development has multiple benefits and as many prototypes as can fit into the allocated project time should be created.
The first benefit of iterative design is that it allows initial design mistakes to be overcome. It is rare in any project that a design is right the first time – in fact, it is usually hard to know the exact requirements of a project before implementation has started. In a linear model, after the design stage is over, it’s over. There’s no going back and modifying the design during the implementation stage. Whether your design decisions were good or bad, you are stuck with them and this can impact the final system you create. With an iterative approach, this problem is solved (partly). You set out your requirements, design the system, produce a prototype and then evaluate the prototype. You can then use what you have learnt from that prototype to redesign the system and produce another prototype. The idea is that the system improves with each iteration.
Secondly, as previously mentioned, during the requirements phase of a project you are unlikely to know the exact requirements of the system. As you realise more requirements or changes to your requirements later during the iteration, you can make modifications to the design on the next iteration.
Another benefit is that, in many cases, you will be working for and with a non technical customer (and possibly non technical users). They may not necessarily understand complex design documents or technical specifications. However, they do understand prototypes that they can play with!! It’s a lot easier for them to test a prototype, see it in action, and see the implications of decisions made during the requirements and design phases.
One thing that does have to be noted though is, as with any other design model, this isn’t perfect. And you most certainly can’t make huge errors due to carelessness and expect their to be no implications. Sometimes, initial bad design decisions cannot be overcome due to design inertia – basically some decisions made in the early stages of the project can have such drastic consequences or be so fundamental that it cannot be changed significantly enough to negate the initial bad design decision.
Overall, the iterative design model is a good design model, that is currently underused. Some businesses have become aware of its potential and have started using it with their software products with some promising results. The iterative design model is likely to increase in popularity in the future, but there will also be a place for the Waterfall model as well.
When choosing a design model for a project it is always important to consider which design model best suits the project and the circumstances surrounding it. There isn’t one model that is good for every project – some models benefit some projects better than others!