things to make sure of before releasing the game

Started by AnasAbdin, Wed 23/11/2011 06:54:16

Previous topic - Next topic

AnasAbdin

hello all,
I hope my topic is in the right place!

as most of you already know, Anastroanut is being born soon (sorry no specific date yet). Since I'm still new to AGS, I was going over the Global Script code and found debugging shortcuts (ctrl+s.... etc) that I didn't know about! and to be honest, if I didn't scan the global script that day I would have released the game with those shortcuts available! I did remove them.

So I wanted to ask, are there more things like that I'm unaware of? what else should I make sure of before releasing the game? -other than testing every single click everywhere-

Thanks.

Gilbert

The first thing is to read the Other Features/Distributing your game section of the manual.

Instead of removing the debugging codes from your scripts, a better choice is to use the #ifdef keyword in your codes. For example, the follow codes
Code: ags

#ifdef DEBUG
    Display("x = %d, y = %d", player.X, player.Y);
#endif

will not be compiled into your final game as long as you disable debug mode of the game prior to saving it for distribution. (For more information, see Scripting/Script language keywords/Constants of the manual.)

Also, all occurrences of the Debug() function used in your game will be disabled automatically when you disable debug mode.

The most important thing that you should remember is to really disable debug mode before distributing your game. A lot of authors forgot about this and had their games distributed with debug mode turned on, and so players could type the debug shortcuts to say get all the inventory items, teleport to another room and the like.

Daniel Eakins

Also check that the game's default settings in winsetup.exe are not too exotic. For example I usually test my 320x240 game in windowed mode with a 3x nearest-neighbour filter, but that isn't compatible with all monitors, so if I ever release something I'll make sure to put the default settings back at full screen with no filter on so as not to confuse the average user.
We all have our time machines, don't we?

NickyNyce

#3
I would imagine you have had people test the game too. Even when you think everything is perfect, having another few sets of eyes to look at your game and give advise and test for bugs is always a good idea.

Also....I learned the hard way about making a copy of my game The Visitor. I thought I had backed it up and saved the compiled folder...(head smack)...after breaking the game by fiddling with things, I realized the compiled folder was no help to me if I needed to open the game inside the editor again. The Visitor was released a bit premature, but thank god I had the most updated version already uploaded to mediafire.

Just a couple things to think about so others dont make the same mistake I did. In fact, if anyone can tell me the exact folder I should save as a backup would help for my next project.

NickyNyce

Snarky

And check the spelling, too. Even just exporting the text and running it through a spell checker would catch a lot of mistakes that make it into released games.

Khris

Quote from: Daniel Eakins on Wed 23/11/2011 14:38:48For example I usually test my 320x240 game in windowed mode with a 3x nearest-neighbour filter, but that isn't compatible with all monitors, so if I ever release something I'll make sure to put the default settings back at full screen with no filter on so as not to confuse the average user.

That's actually not too great; Vista and 7 won't display a 320 game at fullscreen without using a filter and people keep posting here because they couldn't get the game to run because of that.
When in doubt, use the x2 filter for a 320 game; most monitors, graphics cards and OSs should be able to display 640x4X0 without problems.

AnasAbdin

Thank you all for your advice, I really appreciate it.
Khris, I am very concerned with the issue of running the game in full screen in other computers... This is worrying me and at a point was going to stop me from releasing Anastronaut.

The game is 640x480 16bit. What is the best thing to do in that case?
Also, I still do have problems running this game full screen in my own PC. I know this is a local-setting problem that I need to deal with my own monitor etc etc.. << I hope :s

I have Windows 7, just installed DX9 to see if it should work.. I have also changed the color settings to 16bit so AGS would run in window mode.

My PC is dual core something damn I forgot hehe
- 4 GB Ram
- 2 GB vga

.....elp :<

Ghost

Use windowed mode and a x2 filter. That'll give you a 1280x720 window, and that should look okay on the majority of computers (I doubt that there are many people still running on 800x600!).
Just make sure to mention (in a readme) that these settings can be changed, and that this may or may not work depending on the graphics card. Yes, many people do not read the readme, but they all should, and you yourself have then done all that's possible.

Snarky

Dave Gilbert recently said that 16-bit games can be problematic in Windows 7 under DirectDraw, so for that reason I'd recommend 32-bit.

Gilbert

Quote from: Ghost on Thu 24/11/2011 09:41:16
Use windowed mode and a x2 filter. That'll give you a 1280x720 window, and that should look okay on the majority of computers (I doubt that there are many people still running on 800x600!).

Well... That's actually not ok. I use a 17" CRT at home and my desktop is set to 1024x768. Also, the system I use in the office uses a crappy 15" LCD panel, whose maximum (native) resolution is 1024x768.

AnasAbdin

Quote from: Iceboty V7000a on Thu 24/11/2011 15:22:26Well... That's actually not ok.

I don't think I'll release Anastronaut unless I make sure it works in full screen somewhere in this universe....

Ghost

Quote from: Iceboty V7000a on Thu 24/11/2011 15:22:26
Well... That's actually not ok. I use a 17" CRT at home and my desktop is set to 1024x768. Also, the system I use in the office uses a crappy 15" LCD panel, whose maximum (native) resolution is 1024x768.

But wouldn't windowed mode make it much easier to quit from the game and then check the readme and adjust accordingly? I'd prefer that to having a messed-up fullscreen where you may be forced to GUESS that Ctrl-Q will save your day.

Gilbert

What I meant, was not that I'm against windowed mode. Instead, I prefer games to be distributed in windowed mode for the reason you pointed out, since the horrible varieties of display aspect ratios and resolutions different system could have nowadays just mess every thing up.
What I was against, was this:
Quote from: Ghost on Thu 24/11/2011 09:41:16
... a x2 filter. That'll give you a 1280x720 window, and that should look okay on the majority of computers (I doubt that there are many people still running on 800x600!).
If the horizontal resolution of a game is already 640+, don't bother setting a x2 filter as the default, as I already pointed out it does not look okay on the majority of computers. In fact, AFAIK the engine refuses to create a window that is larger than the desktop resolution, so this simply won't work.

AnasAbdin

#13
Please, a few more questions [on the same issue]

I'd like to give the players as many options as possible, so:
(I know there's a 'downgrade to 16bit' option in 32bit games)


1. If I built two different .EXE files (16 and 32 bits)... would this affect the Audio.vox and Speech.vox files? Which files would be directly affected. I'm asking this because when I run a 32bit game on my 16bit settings it won't show anything. And if I changed my settings to 32bit is shows all.

2. Are the multiple options from question 1 considered 'good practice'?

3. Anastronaut is originally 640x480 16bit. The game had been tested on many different computers. Many of them had no problems whatsoever running in full screen mode. Others -Windows 7- had to run it in window mode... so I know there's no problem with AGS itself, it could be choosing the correct settings or installing the video card properly... the question is: is there any kind of text [manual maybe] where this issue is well explained for potential consumers? Like something to include in a readme file before starting to complain about this issue?


SMF spam blocked by CleanTalk