Making a demo out of a full project

[Ats]

Hi. Today I was thinking about a good way to create a playable demo of my game. Here are my thoughts:

Option 1: Make a copy and trim it

• Copy the project
• Remove the unneeded parts
• Compile the demo

This is simple, but only the first time. If I update the game and want to update the demo as well, I'll have to redo everything again. A maintenance nightmare.

Option 2: The demo is hidden in the full game

• Set a demo boolean to true
• Modify the game so it takes that boolean into account
• Compile the demo

I like this approach, but it means distributing the entire game instead of a real demo, and I'm not too fond of that...

Option 3: Automatically trim the code before compilation
Even without modifying ZGameEditor, there could be a way to mark parts of the code as needed for the demo. Then I could run a bat script (or add that option to ZgeSublime) to automatically copy the project and remove the unneeded code before compiling the demo. It’s not the simplest option, but once it's set up, I would be able to update the full game and generate a new demo in seconds.

So I'm looking for a way to mark the necessary parts (or mark the unneeded parts instead).

Here's a template code:

Code: Select all

<?xml version="1.0" encoding="iso-8859-1" ?>
<ZApplication Name="App" Caption="ZGameEditor application" FileVersion="2">
  <OnLoaded>
    <ZExpression Name="code" Comment="code intro" DesignDisable="255" Expression="trace(&quot;Hello&quot;);"/>
  </OnLoaded>
</ZApplication>

I tried adding a custom XML attribute such as demo="255", but it gets deleted when editing the file in ZGameEditor.
That leaves me two options:

Using Comment
The first character of the element’s Comment could be used to mark whether it’s needed for the full game or the demo. My program would recognize that without touching ZGameEditor sourcecode.

Using DesignDisable
When checked, this option sets the value 255 for the element’s DesignDisable. Maybe I could use this. The problem is that once it’s set, the component is disabled in preview mode.
I tried changing the 255 to another value directly in the XML, say 1. This value is not deleted or converted back to 255 when returning to ZGameEditor, which is nice, but the component is still considered disabled in preview mode. I could use that, but it would require modifying ZGameEditor so that components are disabled only when the value is exactly 255, leaving 254 other possible values for custom use

All the components has the Comment and DesignDisable options so it could be quite handy.
What do you think? Or are there other, better, methods to do this?

[Ats]

I think I'm going with the comments. That way, I can set the tags I want without breaking the ZGE source code

Now I'm thinking about use cases. Do I need to tag DEMO on what is needed and remove the rest during compilation, or should I tag FULL and remove only those parts?

There are also cases where the code inside a ZExpression will be different between DEMO and FULL. For example, going to a "buy full game" state instead of "game over" state.

It's not as simple as I thought. I’ll get my hands dirty tomorrow.

[Kjell]

Hi Ats,

There's no easy & universal way to solve this. It really depends on your project and how it is structured. But a combination of option 2 & 3 should work?

Do I need to tag DEMO on what is needed and remove the rest during compilation, or should I tag FULL and remove only those parts?

Maybe both? Tag the components that you absolutely don't want in the demo version with "FULL", and tag the components that you don't want / need in the full version with "DEMO". That way you can probably avoid having to tag most components, and only tag what you (really) want to remove.

Perhaps you can do this recursively? So anything in ( for example ) a Group component labeled "FULL" will get removed in the demo version.

There are also cases where the code inside a ZExpression will be different between DEMO and FULL. For example, going to a "buy full game" state instead of "game over" state.

Exactly, having a global DEMO constant for that purpose is a good idea yes .. even if that means you end up with a bit of demo-version-code in your full version, and a bit of full-version-code in your demo version.

K

[VilleK]

If you have a DEMO constant (either a Constant component or a "const int DEMO = 1;" in a ZLibrary) and the write code like:

Code: Select all

if(DEMO) {
  // do some demo stuff
} else {
  // full version
}

Now if you set DEMO to 1 and build your executables from ZGE then the demo build of your game will only contain the "// do some demo stuff" part of the if-statement above. So there is no risk of any hacker turning the demo version into a full version if that is what you worry about.

[Ats]

Oh, incredible. That simplifies everything!
I didn’t know that compiling the EXE would only keep the accessible part of the code inside an if/else statement
Does it also skip integrating content such as Models and States that aren’t used when DEMO is set to 1, or should I continue working on my bat-trimmer?

[Kjell]

Hi Ats,

Does it also skip integrating content such as Models and States that aren’t used when DEMO is set to 1, or should I continue working on my bat-trimmer?

You need to trim those yourself. Attached is a simple example demonstrating this. Try building a standalone with DEMO set to 0 and another one with DEMO set to 1 .. both have the exact same file size.

K

[Ats]

All right. Then I'll make a program to do that, and I'll publish it here with a little "game". I intend it to be the most reusable possible for other projects.

[VilleK]

You need to trim those yourself. Attached is a simple example demonstrating this. Try building a standalone with DEMO set to 0 and another one with DEMO set to 1 .. both have the exact same file size.

Thanks for the example Kjell. I noticed that indeed the file sizes are identical regardless of DEMO is defined or not but I think that could be some zero padding because if I add more code in the if(DEMO) block then sizes will differ.

@Ats: You can also try the "Find unused components" in the Tools menu. In Kjells example it shows this when DEMO = 1. That could help you find the content to remove in demo version.

[Kjell]

Hej Ville,

I noticed that indeed the file sizes are identical regardless of DEMO is defined or not but I think that could be some zero padding because if I add more code in the if(DEMO) block then sizes will differ.

I know .. i wasn't trying to dispute your claim or something, the example was just to ( primarily ) show that the two bitmaps that don't get used in the demo version still get included in the demo executable.

But just to prove that automatic code removal does in fact work, the attached example does show a clear difference in file size

K

[Ats]

@VilleK, could you make the list of unused components selectable so we can copy/paste it?

Or even better, make it deletable: once the list is generated, we could select which components to delete or delete them all at once. Would that be possible?

And/Or add "Remove unused components" in the build options, under "Remove unused code"?
Or would that enter some kind of recursive loop of death?

[VilleK]

Good suggestion. I added such an option now.

Please try updated build: http://www.zgameeditor.org/files/ZGameEditor_beta.zip

[Ats]

Cool. That works very well
I'm modifying the steering example into a little game/demo in order to test all that!

[Kjell]

Just be aware that the "Find unused components" and the new "Remove unused components" features aren't iterative. So in the following project only DemoMaterial ( and its MaterialTexture child ) will get removed, but DemoBitmap won't ( since it's used by MaterialTexture ).



K

[Ats]

I'm not on my computer to try, but wouldn't that case be solved if Remove Unused Components was called twice?
So what about running it until there is nothing to remove before building?

[VilleK]

Just be aware that the "Find unused components" and the new "Remove unused components" features aren't iterative. So in the following project only DemoMaterial ( and its MaterialTexture child ) will get removed, but DemoBitmap won't ( since it's used by MaterialTexture ).

Good catch, I should change this.

@Ats: Have you tried using it on your main Omeganaut project file? It would be good to know that the new feature to remove components while building works on large projects.