Zune Home -- Potentional Application Suite

[Tiptup300]

Okay, I believe I nailed down the core design guidelines for when desigining your program. I'll go over step by step what you'll have to think about when making apps, how you'll have to design/program your apps, and how to release your apps.

Design Considerations

- Since the zune only has 16mb of memory, this will restrict you in some form in Zune Home. The main application won't take much, but possibly about 1mb or so of information.

- The content system will work like this; each appmodule will be put into it's own folder which will be located in /ZuneHome/Appmodules/, all the content will be loaded into this directory (precompiled .xnbs only)

- 24 pixels of the top of the screen will always be unavailable to show the time and date and also to make it feel as though all the applications are just part of one big experience.

- A modifyed version of the ZuneBlade will be available. You'll have access to all it's functions. Note: this will take another 24px at the bottom of the screen. This is not required to be displayed, you can also hide this for slightly more space.

- All that will be provided to you will be:
-- SpriteBatch for drawing
-- ContentManager for loading content
-- StorageContainer for saving/loading saved content.
-- ZunePadInput for detecting input
-- Static Fonts class with preloaded fonts for any project to use.

- If an application is overall very useful and well built, it will be added to the main release of ZuneHome. GAMES WILL NOT BE ACCEPTED.

- The main interface's color scheme is mostly red, you may want to design you're apps around this color scheme. It's not required, but it would probably make it nicer to look at?

How your game's code will look and what you need.

using ...;

namespace ZuneHome
{
    public class Clock : AppModule
    {
        private Texture2D ClockTexture;

        /* IMPORTANT */
        private static AppInfo Info = new AppInfo("Clock", "Tiptup300"); // These two lines are REQUIRED
        public static AppInfo GetInfo() { return Info; }                 // They provide the main UI with the games information, without this line the app will not be recognized.
        /* IMPORTANT */

        public Clock(IServiceProvider services)
            : base(services)
        {

        }

        // This is where you load your content and start the application.
        public override void Initialize()
        {
            ClockTexture = Content.Load<Texture2D>("Content\ClockBG");
        }
         
        // Main update loop, notice the Input will need to be updated by the developer.
        public override void Update(GameTime gameTime)
        {
            Input.Update(gameTime);
            if (Input.IsPressed(ZuneInput.ZuneButtons.Back))
                Close();
        }

        // Main draw loop, the spritebatch will arrive being already began.
        public override void Draw(SpriteBatch batch)
        {
            batch.Draw(ClockTexture, Vector2.Zero, Color.White);
            batch.DrawString(Fonts.SegoeUI14pt, DateTime.Now.ToString(), new Vector2(100, 100), Color.Red);
        }

        // Dispose all your used things
        public override void Dispose()
        {
            ClockTexture.Dispose();
        }
    }
}

Note: You'll also need a 64x64 Texture named "Icon.xnb" in each appmodules directory.

What the user must do to add a module

First, you will pack your app into a folder with it's type name, the above will be "Clock"

So the folder will look something like this

ClockClock.cs
ClockIcon.xnb
ClockContentClockBG.xnb

The user will take this folder and put it into ZuneHome/AppModules/

Afterwards they will have to go through each content and set it to "Copy to Output Directory if Newer." Then deploy.

Develeopers and general users, please leave remarks on what you think of this!

[xjakehxbabehx]

i think this sounds very promising in the customization of the zune games for the user.
but i do suspect many people getting errors in installing the apps and you getting alot of "help me please" posts for the first few weeks =/

[Anachostic]

So this gets compiled into one assembly and I assume your controller class uses reflection to scan the classes in the assembly for valid "modules"?

It won't work for me since I'm coding VB. If you were scanning DLLs, I could have given you a DLL to load. (drawbacks to this approach don't need to be reiterated) So I'll just comment on the concept as I see it. Take it with a grain of salt since I don't see your whole vision and I only see the code you've provided.

What's the plan for developers to get started? Do you provide them an assembly that they add to their references and then they inherit from Appmodule? Do they develop a standalone version of the app then edit their main class to inherit from AppModule instead of Game? I see that ZuneBlade is globally available. While developing, do you use the ZuneBlade class(s) and just exclude them from the distribution to you? Ditto with other services.

The code so far looks like a variant of the game state pattern. It seems your AppModule class provides a Close() method to return to the main screen. Is there more that I don't see? A UML diagram would be perfect for this (and would freak out the non-programming readers).

I recognize that you're first to market, but I also predict there might be some early-adopter pains. Like I said, if it's C# only, I can't use it, but good luck in your project!

[Tiptup300]

Honestly, pretty much it's just a GameState style system. Just with a little bit more given to the developers to make development easier. Then they can just give the one folder, the end-users can just drag it onto the application, then it gets added to the list via reflection. It's not a complicated system, it's very simple, but it gets done what I wanted it to do.

[Anachostic]

Yeah, that's cool. I was just wondering if you'd given consideration as to how you would get them the "SDK". There's plenty to consider, especially when you get into versioning.

[Tiptup300]

The SDK will just be a release of ZuneHome, it will come with an example or two to show how apps are made.

[DiNoGames]

If you get this working, I guess it will be easy to make small apps for this concept...

Please let us now when you got your first examples running. (Or does the clock run already?)

[gaurdian]

This is just like my allmost 2 months old idea of making a zune "firmware" as a "game". See ---> http://www.zuneboards.com/forums/gam...-firmware.html. Btw, about the games, i think really small games could be fit in, like pong or something. Also, you should make a size limit for these apps (0.5 or 1 mb or something), and make it possible to chose for yourselve what apps you want.

[xjakehxbabehx]

please let the designer choose how to design his design:P
he already said no games, just apps, and he also said that they can use 15mb of memory

[gaurdian]

Sorry, i was just trying to make this kickass project even better

[Tiptup300]

People are allowed to make games and release them, I'm just never going to add them to the main build. Anyways, the current running version is running smoothly. I just have to make a Settings appmodule for the time.

The first release will have a Bookreader application made by me, Settings application which just sets things up on ZuneHome. Possibly another application from someone else.

[tourettespuppy]

Great! Glad it's doing well.

So do you plan to release different versions? What I mean is v1 has bookreader and messenger, while v2 has alarm clock and notepad. the user can choose which pack they feel fits their needs and add/ modify from there...

nevermind that's a lot of work. But like I said, great job!

[ShotgunSnipist]

Originally Posted by Tiptup300

People are allowed to make games and release them, I'm just never going to add them to the main build. Anyways, the current running version is running smoothly. I just have to make a Settings appmodule for the time.

The first release will have a Bookreader application made by me, Settings application which just sets things up on ZuneHome. Possibly another application from someone else.

That's excellent!
Could you see if you could put one of the two zune messangers on?
Those are what I really want.

[Tiptup300]

If you or the original creator wishes to port it...

[ShotgunSnipist]

Originally Posted by Tiptup300

If you or the original creator wishes to port it...

Since I have no idea what that means...
I'm really hoping someone does.

[DiNoGames]

It means that the already existing apps need to be adapted to work within Zune Home. And of course someone needs to adapt them, speak "port" them over...

[ShotgunSnipist]

Originally Posted by DiNoGames

It means that the already existing apps need to be adapted to work within Zune Home. And of course someone needs to adapt them, speak "port" them over...

Yeah...
That sounds like it could be a serious pain for programs that have multiple parts. But for the ones that just have game1.cs and some content... It seems like it could be pretty easy to do... Although I'm probably wrong.

[Lare2]

I like the idea. So basically this will be like a mini platform to unify little apps that make sense being grouped.

[gaurdian]

Originally Posted by ShotgunSnipist

Yeah...
That sounds like it could be a serious pain for programs that have multiple parts. But for the ones that just have game1.cs and some content... It seems like it could be pretty easy to do... Although I'm probably wrong.

Yep, you're wrong :P The devs just need to make sure that the top part of the screen is empty, and some code (see top post) is added. Dunno if there's anything more to it though, i'm not a programmer :P

[itsnotabigtruck]

Originally Posted by Tiptup300

Okay, I believe I nailed down the core design guidelines for when desigining your program. I'll go over step by step what you'll have to think about when making apps, how you'll have to design/program your apps, and how to release your apps.

--snip--

It might be a good idea to use an attribute instead of a mandatory static method. i.e., instead of requiring the developer to declare a static GetInfo() method and reflecting it, you should create an AppModuleAttribute, which would be declared like this:

[AppModule("Clock", "Tiptup300")]
public sealed class Clock : AppModule
{
(implementation goes here)
}

You can access that attribute with Attribute::GetCustomAttribute.

Also, instead of having the user drop the source and content files into the system before deployment, you could roll the content (using ResourceContentManager) and the source into a DLL and load that at runtime using Assembly::LoadFrom.

It would make sense to access the icon using an abstract method on AppModule instead of requiring the icon to have a magic name.

All of the above is my design opinion - you can take it or leave it (and it isn't that great).