paul evans

Posts Tagged ‘paul evans’

Let me introduce you to Gameduino

2011/07/11

What is a Gameduino? It is an Arduino based gaming device that is a mixture between a science experiment and a classic gaming micro. It provides the kind of platform I grew up with (Oric-1, Acorn Electron, ZX Spectrum, C64, etc.) but with modern touches (USB, VGA, coprocessor).

I supported the Gameduino Kickstarter project and my reward was recently sent to me by the creator of the project, James Bowman. The community around this device so far is small but friendly. It includes electronics and programmers buffs from all kinds of backgrounds.

The Kit

One of the things that struck me when I first opened the box was how exposed everything seems! At some point I would like to either buy a case or mod something to hold the device; but as I have just moved from the UK to the Austin area in to a little apartment, I do not have the tools to fashion something myself just yet.

Here you can see the interfaces of the board. The ArduinoUno has a connection for USB and another for power. The Gameduino board provides a VGA connection and audio jack. The final board is a Joystick shield from SparkFun.

I put a pen in shot to give a sense of scale to the pictures.

The boards communicate to each other via pins and slots which can be seen in the picture above. The shields are designed in such a way that plugging things in the correct way feels natural. On my kit, the audio jack and USB are stacked directly in a way that makes it impossible to push the board all the way home; however, the pins are long enough that it does not matter.

After I constructed the device, the next thing I wanted to do was sit on the sofa with it and play on the television. After asking a few questions on the Gameduino answers forum I decided to try and use sixteen feet of VGA, USB and audio cable. I skipped buying a power supply as my television has a USB port – so I could buy a USB extension cable that is cheaper, less bulky and more generally useful.

Despite the length of the cable and low power draw of Gameduino, it works nicely (well for me anyway!) over that distance. So when playing the Gameduino, it only needs to be connected to the television – though granted via three cables. During development I use the laptop USB for both power and data transfer, while the TV acts as my screen.

Above you can see the boot screen of the Gameduino (which is on the right side of the Kinect under the television). It also plays a nice chord on startup.

Specifications

ArduinoUno (source)

Processor	ATmega328 8-bit microcontroller
Clock Speed	16 Mhz
Flash Memory	32KB – 0.5KB used by boot loader
SRAM	2KB
EEPROM	1KB

Gameduino (source)

Resolution	400×300 – Compatible with any standard VGA monitor (800×600 @ 72Hz)
Color	512 colors, processed internally at 15-bit precision
Background graphics	512×512 pixel character background. 256 characters, each with independent 4 color palette. Pixel smooth X-Y scroll (wraparound)
Foreground graphics	Sprites are 16×16 pixels with per-pixel transparency. Each can use 256, 16 or 4 colors. Four-way rotate and flip. 96 sprites per scan-line, 1536 texels per line. Pixel perfect sprite collision detection.
Audio	Stereo. 12-bit frequency synthesizer. 64 independent voices 10-8000 Hz. Per-voice sine wave or white noise. Sample playback channel.
Memory	32 KB – addresses are 15 bit, last bit indicates read or write (via SPI interface)
Coprocessor	J1 Forth CPU. 16-bit internal bus, 8-bit memory interface. 50 MIPS. Direct access to entire Gameduino memory. Executes code from set 256 byte range. Machine instructions very close to Forth. Single-cycle 16×16 bit multiply, plus barrel shifter. Fast, efficient stack machine.

Why

I wanted to get back to basics a little bit. My favorite language these days is C# but for a long time it was C++.

I believe constraints can force creativity in some interesting ways. Necessity is the mother of invention after all. The Gameduino is constrained with its specification, though has many interesting quirks I look forward to learning about. For example, the co-processor needs instructions in Forth!

Practicing skills and learning new things is always more interesting when trying to accomplish something rather than just going through exercises. I plan to have a little game of my own running on it in time. I have not got that far yet, but below is a sneak peak.

Jan Boon has written an excellent emulator “gdemu” that provides a pretty good simulation of the hardware that has been allowed me to develop in Visual Studio without deploying to the Gameduino each time. I forked it on google code, but as I am also teaching myself git and git flow I imported that over to github.

I have started to get used to the processing based environment provided for Arduino. Projects are called sketches and basically include all the c/c++ source and header files in a folder. It is an IDE that provides a way to compile and upload your program, plus serial monitor which is helpful for sending debug messages. I do not think there is a way of stepping through code on the device without more hardware though.

My aim is to try some test driven development with the Gameduino now I have explored it a little. Ideally I would like my own project to be built and deployed to the device via a single line on the command line or a double click of an icon… I am not there yet though.

If anyone has any Gameduino projects to share or has worked on similar devices, please say something in the comments. It would be nice to know that people are reading this!

The "Micro Talk" format

Every participant is given ten minutes to talk. A time keeper near the front of the stage flashes up cards when the speaker is near the end of their session so they can wrap up the talk. There is also a longer message for when a speaker goes over that limit.

There are variations where the time limit is less strict. Sometimes there is a defined period of time for Q&A that may be filled. I recall as part of my Bachelors degree we had strict time limits and a QA for presentations on projects; so those from an academic background may be familiar with this style already.

Ten minutes is time enough to cover a large subject at a very high level or a very specific topic in detail. This forces focus and sets the pace for all the talks.

For the speaker ten minutes should be relatively easy to fill about something they know about. If anything, reducing things down to ten minutes may be an issue.

For the audience ten minute bite-sized chunks of content should be digestible even if it is something individual members have little interest in.

Creative Day 2011 at Lionhead Studios

A similar format was used for Creative Day at Lionhead Studios. We did not use the term “micro talks” but that is what the format was at the core (though without the very strict time keeping). Everyone who participated was given a short time to introduce their project and demonstrate it. Some ran under and some ran over but every presentation got part or all of the audience interested. Each team was given a couple of days of studio time to complete their own project (and as much of their own time as they wanted of course).

The Lionhead event has been quite well covered in the industry press. The project I worked on was one of the lower profile ones that just gets a mention in Edge. I worked with developer Pete Coward and musician Kai Chi Chan on a reimplementation of Populous in HTML5, which used a multiplayer server implemented using node.js. Our proof of concept was implemented in a few days.

The demo itself had a few technical problems due to us trying to improvise a wireless network. It got a bit overwhelmed by a cinema full of developers trying to connect to it with laptops, iPads and mobile phones… but overall the presentation was well received and the multiplayer capability was demonstrated. We kept things going long enough to show Peter drowning little people by lowering some land in to the ocean, which got a good laugh.

It was an emotionally charged experience presenting to all the talent of the studio – especially considering some of the mind blowing things that were demoed before we were up. Keep in mind that most of the people presenting were not at all used to being in the public eye. In the relatively safe environment of that cinema full of colleagues, everyone shone. Every single presentation had something interesting to give and add to the day. People really got to know each other better that day.

If IGDA Guildford ever gets going again – meetings in this format should happen. There are enough people working there to support it!

IGDA Austin Micro Talks (2011-06-25)

My first IGDA Austin meeting was in the micro talk format and provided a great introduction for me to some of the people in the chapter. The talks took place in a television studio and were recorded – so should end up on YouTube at some point in the future. See the austingamedevs.org website for further details.

John Henderson acted as master of ceremonies, introducing each speaker and announcing breaks between the speakers. At the end of the breaks he took the opportunity to introduce some of the volunteers around the hall that were running the event.

Jon Jones opened up the evening with a talk about making yourself more attractive on the job market by differentiating yourself. His example used a character artist portfolio with a few stereotypes that got laughs from the audience. The drive of the talk was to be a little different by thinking creatively and to actively network. Many of his own career advances had come from networking and he said that he pushed himself to get out there. He made special note to try not and make enemies, as you never know how that will come back to bite you later.

Denis Loubet made a presentation about how much luck there is involved in creating a profitable iPhone game. He made his presentation without aid of slides. The message I took away from that was that it was better to prototype an idea and ship early before investing too much, as you can never be quite sure where lightening will strike. Rovio made a few games before their success with Angry Birds.

Sara Jensen Schubert’s session was about using a spreadsheet to balance progression in an RPG. Consistency was highlighted as an imported factor in progression. Second to that was modeling enemy stats close to that of the player to make things easier to manage later on. It immediately reminded me of systems I had seen used around Lionhead that our tools supported. I think Sara and my friends back in the UK, Mike West and Kalev Tait – would have a good talk about their various ideas for balancing.

Fred Schmidt made the case for how awesome Austin is, the history of the area and how the creative industry fuels the economy. There needs to be more engagement across the educational, public and private sectors to better support the many small companies doing amazing things in the area.

Damion Schubert spoke about the power of innovation – where it is useful and when it should be reined in. Innovation can take many forms, from simplification of an idea to something completely new. An innovative game should be explainable in a sentence and have true resonance with the audience. Swing big, make sure the players get to use your innovation and support it through every other element of game play. Remember that an idea is only innovative if it is better, and that it should be less expensive than making a "me-too" product.

"From Startup to Survival" by Quoc Tran was an interesting study in what can make the difference between success and failure in a start up. It boiled down to focus, underdo the competition and release early. Remember that resources are limited and that if cash is a problem, ship sooner. The feedback generated and market position achieved by shipping sooner is more important than a complete feature set.

Carl Canga made a presentation about how important investing for retirement is. Despite the presentation slides not working, Carl went on to make a well rehearsed presentation. It was certainly a sobering talk for me and something I will make a priority as soon as my means allow it.

Conclusion

Presenting and demonstrating things in front of an audience even just for ten minutes may seem daunting but there is no doubt in my mind it is worth it. It is a great introduction to public speaking and one I personally intend to try again. I encourage you to try it out – either at your studio, an IGDA meeting or wherever you can.

The conversations during the breaks at events like these are also invaluable. It is a great way to make friends and eventually introduce people who can help each other out. Get yourself out there!

Never under estimate how important it is to communicate the knowledge you have to other people. What you write or present will never be useful to everyone – but even if you help a few people out, it is worth it. Why not try writing for #AltDevBlogADay?

About this article

I wrote this in Star Coffee in Round Rock, TX while slowly drinking an iced mocha. It is written from my own notes made in OneNote last night and some others that Danni (my wife) made. While writing this I’m listening to a Blue Grass jam session. I’ve only been in the Austin area for a few weeks – and although I am still adjusting to the baking hot weather it has been a good experience so far. I have no doubt that this place is another great creative hub.

This post was created for AltDevBlogADay: http://altdevblogaday.org/2011/06/25/micro-talks/

Tags:lionhead, micro talks, networking, paul evans, public speaking
Posted in Uncategorized | Leave a Comment »

The XmlSerializer class in C# is asymmetric

2011/06/11

C# coders choosing XmlSerializer for their game data beware. When using the DefaultValueAttribute on members of a class being later processed by XmlSerializer, a perfect copy of an object written may not be read back later. This post demonstrates the behavior.

XmlSerializer versus DefaultValueAttribute

The DefaultValue attribute is useful for giving hints to the user interface controls, particularly ones that inspect objects such as the PropertyGrid. It allows objects to be created using their default constructor then have their default value set later by the control responsible for it.

The XmlSerializer also takes this value in to consideration when writing an xml representation of the object. If the class member being serialized has a value that matches the value declared by the DefaultValue attribute it skips writing the value all together. Less written, less to read back – looks good.

XmlSerializer does not restore the value of DefaultValue to a member when reading an xml representation of an object, it uses the default as defined by the member type (null for classes, 0 for integers, etc.). This is the potential source of confusion; you cannot rely on the XmlSerializer to create perfect deep copies of your objects. It does not assume missing xml means “use the default value attribute”. XmlSerializer has implicitly set the expectation on your code to restore the default values from the attributes.

Demonstration

I have embedded commented code in the post below that demonstrates the above. I have also uploaded it to github.

// See Clue class to change demo behavior.
// Uncomment one of the fixes below to observe different behaviors.
// Search for FIX1 or FIX2 to see where the changes have been made.
//// #define FIX1  // Do *not* use DefaultValue attribute, taken in to account serializing but not de-serializing.
//// #define FIX2  // Set default value of variable to same as DefaultValue attribute during construction.

namespace AsymmetricXmlSerializer
{
    using System;
    using System.ComponentModel;
    using System.Diagnostics;
    using System.IO;
    using System.Text;
    using System.Xml;
    using System.Xml.Serialization;

    /// <summary>
    /// Class to be serialized and demo point for asymmetric XmlSerializer behavior.
    /// </summary>
    [Serializable()]
    public class Clue
    {
        /// <summary>
        /// Comment out DefaultValue attribute and it will succeed.
        /// </summary>
        /// <remarks>Set variable to 'Nothing To See Here'to to work around.</remarks>
#if !FIX1
        [DefaultValue("Nothing To See Here")]
#endif
#if !FIX2
        public string text;
#else
        public string text = "Nothing To See Here";
#endif
    }

    /// <summary>
    /// Demo program for asymmetric XmlSerializer behavior with DefaultValueAttribute.
    /// </summary>
    internal sealed class Program
    {
        public static void Main(string[] args)
        {
            // If initial value is the same as DefaultValueAttribute for variable declaration,
            // it is not persisted by XmlSerializer.
            Clue clue = new Clue();
            clue.text = "Nothing To See Here";

            // Buffer for writing.
            StringBuilder buffer = new StringBuilder();

            // Don't need namespaces.
            XmlSerializerNamespaces no_namespaces = new XmlSerializerNamespaces();
            no_namespaces.Add(string.Empty, string.Empty);

            // Don't need xml declaration.
            XmlWriterSettings writer_settings = new XmlWriterSettings() { OmitXmlDeclaration = true };

            // Serialise the clue...
            XmlSerializer xml_serializer = new XmlSerializer(typeof(Clue));
            StringWriter string_writer = new StringWriter(buffer);
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
            {
                xml_serializer.Serialize(xml_writer, clue, no_namespaces);
            }

            string serialized = buffer.ToString();

            // Show serialised version of the clue...
            Console.WriteLine("Clue text value: {0}", clue.text);
            Console.WriteLine("Clue serialized: {0}", serialized);

            // Deserialise the clue...
            Clue clue_read;
            using (StringReader sr = new StringReader(serialized))
            {
                clue_read = (Clue)xml_serializer.Deserialize(sr);
            }

            // Show clue 2 on console
            // Reset and reuse write buffer.
            buffer.Length = 0;
            using (XmlWriter xml_writer = XmlWriter.Create(string_writer, writer_settings))
            {
                xml_serializer.Serialize(xml_writer, clue_read, no_namespaces);
            }

            string reserialized = buffer.ToString();
            Console.WriteLine("Read Clue text value: {0}", clue_read.text);
            Console.WriteLine("Read Clue serialized: {0}", reserialized);

            Debug.Assert(clue.text == clue_read.text, "Written & read clue's text should match");
        }
    }
}

/* NOTES
 * FIX1: Don't use DefaultValueAttribute.
 *
 * You would want to use DefaultValueAttribute to avoid persisting the
 * default value to the xml representation.
 * Although this does prevent the default value being persisted, on read the
 * DefaultValueAttribute is ignored so the value is never set to that of
 * the DefaultValueAttribute.
 * DefaultValueAttribute is also used for value hints for UI.
 * See: http://msdn.microsoft.com/en-us/library/2cws2s9d.aspx
 *
 *
 * FIX2: Use DefaultValueAttribute AND default value at construction.
 *
 * To use DefaultValueAttribute and have the object be recreated
 * properly when reading it back, you must to explicitly set the
 * default value during construction of the object being read.
 * Using this method means the xml is concise and the object
 * is accurately recreated.
 */

(Cross posted from: http://altdevblogaday.org/2011/06/10/the-xmlserializer-class-in-c-is-asymmetric/ )

Tags:c-sharp, paul evans
Posted in Uncategorized | Leave a Comment »

(Audio Post) Round Table: DLC

2011/03/14

I decided to gather a few friends from around the studio to informally discuss downloadable content around a table over lunch. This is the first time I have tried anything like this so please keep that in mind! This is all personal opinion too, not that of our employer.

High level summary of what we discussed:

What is your favorite DLC & why?
Is DLC on the disk ethical?
Discussion around DLC pricing.
How can DLC effect game balance?
DLC and player status.

The voices you hear in order of appearance:

Paul Evans @PaulECoyote (Programmer).
David Addis (Programmer).
Kalev Tait @KalevTait (Designer).
Keith Judge @KeefJudge (Programmer).
Bryn Davies @LH_ClarkyCat (Designer).

Thanks to everyone who took part. Special thanks goes to my wife who spent some of her time over the weekend post-producing this. Should I try this again with any luck I will do a better job with the advice she has given me.

Update: The original audio files linked have been updated. Michael Taylor @stomp224 (Audio Designer) kindly offered to clean up the audio some more. Find him at http://www.stomp224.co.uk

As with Mike Acton’s audio posts, this comes with no warranty, transcription or satisfaction guarantee!

Orignally posted on #AltDevBlogADay.

Round Table: DLC (Part 1 of 2)

Round Table: DLC (Part 2 of 2)

Tags:Audio Post, Bryn Davies, David Addis, Discussion, DLC, Kalev Tait, Keith Judge, paul evans, Roundtable
Posted in Uncategorized | Leave a Comment »

Do or do not

2011/02/25

Assertion is a valuable tool that many languages provide, but recently I have come to think it is used too much and in the wrong places. I put forward the idea that asserts should not be found anywhere in the main body of your code. Permanently burying asserts deep inside your code could end up causing more problems than they seek to solve. Asserts embedded in methods are useful while debugging, but should rarely be committed to source control.

I extend this thought to other defensive practices like checking for nulls indiscriminately – even where there never should be one. Sanitization of external data is prudent and necessary, but once things are safely inside your own codebase you have control of the expected range of values and should be able to trust that.

What an assert does

An assert stops execution and flashes up a message when a condition fails. If there is a debugger attached then if it can it will direct the programmer to the source where the assert fired. Great for the programmer trying to track something down, rubbish for someone else who has to skip the message (perhaps many times) to do what they are trying to do.

Asserts disrupting workflow for other programmers and disciplines have been mitigated in a few ways. The following are some more common methods:

Builds with asserts turned off
Asserts with a concept of levels or categories that can be toggled
Assert instance toggle – it will appear once but as well as skip there’s an option to ignore

Crying wolf

Asserts that continually fire create too much noise; unless the game completely falls over then people start to not take any of them seriously. Just like compiler warnings there is a point where many eyes just glaze over the number and a number above zero becomes an excepted part of life… perhaps even becoming a joke.

Do or do not, there is no try

Yoda: 'Do, or do not! There is no try'.

Asserts show a lack of confidence of an operation being successful – so much so that a human being should be warned. It is a developer communicating with themselves and others that at some point something is in a state so dire that normal execution must be interrupted so someone can take a look. I do not believe having that kind of warning permanently buried and hidden is healthy. It is preferable to either formally test and handle the situation if it really is expected, or get to the real root of the problem and prevent that invalid state from ever occurring.

Sanitize the data once properly rather than repeatedly sanitizing the same data in the same way throughout the program just in case. Every time a conditional statement is encountered there is a computational cost associated with that. A code block could have its own setup and destruction costs – perhaps more so if exception handling is being used. This may seem like premature optimization but clear concise code is easier to digest for man, compiler and machine. After all the best kind of processing is the processing you can eliminate – look to improve your algorithm.

Asserts in the middle of a method after a long conditional block could indicate that the method could be broken in to smaller more focused testable methods. If possible architect so that a method will always succeed in some measure to allow callers to expect the same predictable outcome. If a function should always return a populated something, use a default something rather than null. For example use a valid bright pink texture for missing data and log the error rather than just returning null and forcing everything from that point on to check for nulls.

Silent but deadly

A badly written assert may cause a side effect as part of testing the condition perhaps without the programmer even realizing it. When an assert like that is disabled it causes different behavior between types of builds.

Worse is when an assert expects to be heeded in the same way as exception. Ignored or absent through compilation options, execution blunders on and states become corrupted, going on to cause unpredictable problems later. Perhaps that problem will even mask itself as an issue with a completely unrelated system. In the worst case corrupt data could be persisted, ruining a saved game.

Asserts encourage a codebase that constantly tries to correct itself rather than addressing the real problem. Methods no longer trust each other to fulfill their remit. Expectations of callers change from “I should only give it foo” to “I can give it foo, bar or nothing at all”. Those expectations can virally spread throughout the codebase causing more methods to second-guess each other and bloat.

The truth is out there

Earlier I stated that asserts in the main body of code shows a lack of confidence and are used to try to mitigate bad states. Used in the context of test functions they serve to communicate an expectation of success. The tests can be run independent of running the game or application itself and provided with sample of runtime data to consume. Instead of the same assertions being made in multiple places against the same method scattered across the codebase, an expectation for a specific scenario can be stated exactly once.

Asserted expectations can be gathered in a test suite to form a living document in code that provides examples of use that are easily found. Compile time can be quicker for coders because tests can be separated out in to different projects – run only during the testing phase of a change and on the build machine.

Conclusion

Asserts in the main body of your code clutter the logic and could be expressed more concisely elsewhere. Programming too defensively could blur the responsibility of what is being written. Do not always code “just in case” otherwise callers will start to rely on the defensive parts. Either set the expectation of a method to always sanitize (and perhaps hint at that extra processing in the name) or fail as gracefully and quickly as possible. Methods have to be able to trust each other. Many applications and games are closed systems that have predictable points of failure, only the input from the boundaries should be considered for sanitization. Failed asserts should be a point of immediate failure – though I would argue there are better ways of indicating failure.

Asserts are very useful for debugging, but be wary of the costs of permanently committing them to the main body of your source code. Logging error messages and substituting inert values can be far less obtrusive then relying on asserts breaking execution and popping up message boxes. It is outrageous for a tool that is supposed to run unattended to stop everything waiting for input, just fail and exit.

Asserts do belong in source control when used to formally test methods and when they clearly express specifications. This kind of living documentation created by asserts is a form of cover fire. If you cannot separate asserts in to formal test methods to create clear behavior specifications, try and gather them together close to where the bad state will first occur. Group them close as possible to where an errant call could first appear on the stack, rather than scattering the expectations around deep in the code. Let the developer see everything that is expected at a glance. Asserts should help avoid detective work after all!

There are many advantages to taking asserts scattered through your code and creating test suites from them – see my previous article Cover Fire for Coders.

Posts Tagged ‘paul evans’

Let me introduce you to Gameduino

The Kit

Specifications

ArduinoUno (source)

Gameduino (source)

Why

Next

Further Reading

Micro Talks

The "Micro Talk" format

Creative Day 2011 at Lionhead Studios

IGDA Austin Micro Talks (2011-06-25)

Conclusion

About this article

The XmlSerializer class in C# is asymmetric

XmlSerializer versus DefaultValueAttribute

Demonstration

(Audio Post) Round Table: DLC

Do or do not

What an assert does

Crying wolf

Do or do not, there is no try

Silent but deadly

The truth is out there

Conclusion

Further Reading

Disclaimer

Pages

Blogroll

Documents

Tweets

Paul Evans

Posts Tagged ‘paul evans’

Let me introduce you to Gameduino

The Kit

Specifications

ArduinoUno (source)

Gameduino (source)

Why

Next

Further Reading

Share this:

Like this:

Micro Talks

The "Micro Talk" format

Creative Day 2011 at Lionhead Studios

IGDA Austin Micro Talks (2011-06-25)

Conclusion

About this article

Share this:

Like this:

The XmlSerializer class in C# is asymmetric

XmlSerializer versus DefaultValueAttribute

Demonstration

Share this:

Like this:

(Audio Post) Round Table: DLC

Share this:

Like this:

Do or do not

What an assert does

Crying wolf

Do or do not, there is no try

Silent but deadly

The truth is out there

Conclusion

Further Reading

Share this:

Like this:

Disclaimer

Pages

Blogroll

Documents

Tweets