Messages

[Edit:]

Sorry about falling off the radar there. Finals at school kind of took precedence.

I'm trying to figure out what the current state of affairs is now though. I know there are some bugs in the build code right now, and I am more than happy to help track them down. It seems Gurok has already caught on to the fact that AGS.Editor.Utilities.GetDirectoryFileList isn't returning the values I thought it was, which is leading to some of the incorrect paths in the hard-linking code (however, I would suggest against using hard-coded directory separators, and instead use Path.DirectorySeparatorChar Path.GetFileName).

Actually, the Editor simply does not copy engine binary to Compiled folder anymore (where it makes game with legacy compiler), hence the game is attached to empty file, or whichever file existed there previously.

I'll take a look at this. It might make sense to delete the Compiled folder when changing this setting, and of course the legacy code should still be copying the engine EXE as it was previously.

I really do not like the inconsistency between Linux and Windows builder classes. Linux builder takes every file from Compiled folder, while Windows one requires to have their names hard-coded. They should work same way. I'd say that probably even builder interface should be changed, because the copying/link of files is a universal operation.

I'm really not sure what you mean by this. Neither the BuildTargetDataFile class nor the BuildTargetWindows class reference any hard-coded paths or file names. As for copying/linking being a "universal" process, I suppose that I could add to the BuildTargetBase class to force the build targets to provide file name, file source path, file destination path, and destination mode (link or copy) for all required build files. Currently both Windows and Linux are parsing the Compiled directory's files directly, so it is only necessary to reference exact file names for platform-specific handling (which is currently only done by the Linux class as Windows doesn't require any platform-specific files). Assuming that the build targets could default some of these parameters, then I could perhaps see some merit to this.

Edit: I do see where the Windows build target is copying/linking the exact files referenced by the previously existing code, whereas Linux is just copying/linking any file from the Compiled directory. This is an inconsistency. Personally I feel that linking any arbitrary files the user has placed in the Compiled directory is a good feature for the end-user. This would allow game devs to put a single README file in the Compiled directory and have it perpetuated to the various platform folders (on build).

I mean that the list of game files should probably be provided by external user.

The entire purpose of having platform-specific classes is to provide the list of platform-specific files, and the platform-specific methods, to allow building that platform. I'm not sure how much further abstracted it could get than described above to where the build target classes tell the base class what files they need, where they need them, and whether to link or copy them.

If a dialog (or indeed other items i imagine) exceed the maximum allowed length then the new data writer throws "Can't resolve import dMyDialogWithALongName" but the old compiler gives the correct error message about the length.

Yes, it's probably worth running back through for error messages that weren't implemented. I was pulling source from dozens of different places, utility classes, subclasses, direct memory access, and so forth, so some of the error messages fell by the wayside as I was sorting out what was necessary to getting the data file in the correct format. These error messages could be nullified by removal of limits, but I should make sure that they respect any limits that still exist in the engine (where the compiled data file is read back in).

Today I realized that in the tile-based platformer demo code, the comments actually indicate the exact logical inverse of what the code is doing. This aside from the bugs I've had to fix in the code (allowing the player to fly irreversibly off the top of the screen, and a rounding error resulting in negative zero) really just strengthens my distaste for the program. Inconsistent indentation styles, inconsistent use of operators, inconsistent and occasionally incorrect code documentation, obfuscating a simple operation like rounding a number by using bitwise operators and not explaining why... With this kind of "quality" demo, it's easy to see why people love GameMaker so much.

Well I am just starting on the degree program. I mean, I'm taking this at the same time as I'm taking an intro to programming course. The latter of which I completed all the coursework for nearly a month ago and just have to take the final (because they wouldn't let me test out of it).

Most of my classmates have no experience whatsoever with programming or game design. The program does also include classes in Java and C++ (and I think C# too), and I know a lot of students further along in the program are using Unity or Unreal, so I'm sure one of the courses covers using those as well.

Palette cycling is still a popular reason for using an 8-bit palette, but is there any reason to continue supporting 16-bit color depth? I doubt any modern system will show a noticeable (negative) difference running in 32-bit color mode vs. 16-bit color, and 16-bit mode has obvious drawbacks (as already mentioned).

[does not]

So apparently GameMaker does not support compound bitwise operators (specifically, '&='), but it doesn't complain about them either. It just sends you on a wild debugging goose chase trying to figure out why nothing is working. Of course, this is only after being bullied into selling out on my own code and defaulting to a prebuilt tile-based demo system, but I at least had to try and clean up the horrific code they're distributing as "proper". Oh GameMaker, how do I loathe thee? Let me count the ways...

[NOTE:]

Sorry it's taken me so long to post this, but here's an AGS 3.3.2 APK. This is based on the master branch of the repository, so should be considered a stable build. This also includes rebuilt Lua libraries, so the APK is notably about 2 MB larger versus previous versions. I'm not sure why the rebuilt libraries are so much larger; I've been investigating how JJS previously built the Lua static libraries (see related issue #211).

NOTE: I changed the package name for this APK from com.bigbluecup.android.launcher to com.bigbluecup.android.gamelauncher, so it will appear as a new app with the same name. I did this because I would like to start pushing these APKs over the Google Play store but someone has uploaded an unpublished APK with the original name. I have not been able to track down who did this, but if anyone who has access to a Google Play Developer account could just double check, I would like to go back to the original package name.

Well considering I'm designing a platformer, it's pretty essential to know when things are colliding with each other.

[Edit:]

When I constructed the list of views for the ViewsWriter class I forgot that views preserve their ID if they are deleted. All it needs is a check if the view is null:

Code: csharp

            public void WriteViews(IViewFolder folder, Game game)
            {
                if (writer == null)
                {
                    throw new CompileError("Could not write views: Invalid stream (NULL)");
                }
                foreach (View view in views)
                {
                    if (view == null) continue; // views are not always sequential, so we may have some null entries
                    short numLoops = (short)view.Loops.Count;
                    /* ... */
                }
            }

In BuildTargetDataFile I forgot to check if for the legacy compiler flag (here, NativeProxy.CreateGameEXE checks it properly).

Code: csharp

        public override bool Build(CompileMessages errors, bool forceRebuild)
        {
            if (!base.Build(errors, forceRebuild)) return false;
            Factory.AGSEditor.SetMODMusicFlag();
            DeleteAnyExistingSplitResourceFiles();
            if (Factory.AGSEditor.Preferences.UseLegacyCompiler) Factory.NativeProxy.CompileGameToDTAFile(Factory.AGSEditor.CurrentGame, AGSEditor.COMPILED_DTA_FILE_NAME);
            else DataFileWriter.SaveThisGameToFile(AGSEditor.COMPILED_DTA_FILE_NAME, Factory.AGSEditor.CurrentGame);
            /* ... */
        }

I can submit commits for these shortly.

Edit: Fixed with commits 029461e and 8117631.

Edit (again): This also points out that the WriteViews function is taking an IViewFolder as a parameter but it always writes the root folder. This parameter was an artifact of a previous version, but there's no reason that it couldn't be implemented (but that's for another time).

I'm taking an Intro to Game Design class as part of my degree program, and for our final exam we're meant to make a game using GameMaker.

My biggest issue so far is that the way it handles collisions doesn't make any sense at all.

Actually most of GML doesn't make sense either, but that's become a minor annoyance in comparison to the collision system. Getting the simplest of tasks to work properly in this program is nigh on impossible. The editor is specifically designed to showcase (and almost enforce) the drag-n-drop system, but testing for collisions using that is essentially saying that you don't want your game to work.

I'm honestly beginning to wonder if the people who designed this program had video game developers in mind. I don't think it was created for making video games.

That's intentional, nothing to worry about (It also takes some heavy trickery to disable the Alt-X shortcut. Not that someone would WANT to do that )

Heavy trickery? You mean like:

Code: ags

game.abort_key = -1;

I mean, that is some pretty hardcore, advanced-level coding right there.

[What version of AGS are you using, and how is the array defined?]

My array entries haven't been initialized, but on game_start I'm running that function above, and it's still producing a null entry when I ask the game to display the contents of PotentialCabinet[0].  The array is correctly defined, and I've never had this trouble with importing integers from a text or dat file.

Perhaps I wasn't clear. What version of AGS are you using, and how is the array defined? This is important to answering your question. The way in which your array is "correctly defined" is entirely dependent on which version of AGS you are using. If you want help with this question, we need to know this information.

[that]

It tells me that PotentialCabinet[0] is a null pointer.  What am I doing incorrectly?

If it's telling you that, then it means your array entries haven't been initialized. What version of AGS are you using, and how is PotentialCabinet defined?

[Edit:]

That doesn't match what I'm getting at all. I'll test it on a different computer this afternoon.

Edit: It occurred to me that the problem may lie in the fact that I never did anything to ensure that the EXE was deleted when upgrading to 3.4.0.2. This would explain the erroneous EXE, but I'm looking into the other issues.

[Edit:]

I made a test build with possible fixes for both the hard linking errors and the Linux engines not running.

https://bitbucket.org/monkey0506/ags/downloads/3.4.0.2-test.rar

Could you please try this out and see if it resolves anything?

I forgot that the "mklink" program requires being run as an administrator. From what I read on Stack Overflow, I think this should raise a UAC prompt to elevate the task if not running as an administrator.

As for the Linux script, I've attempted to set it as executable for everyone instead of just the user group.

With the error that it can't find the game data files, could you confirm that you have "ac2game.dta" in the same directory as "ags32"? If you're having hard linking issues then it's possible it didn't link that file properly, but you could also try copying Compiled/YOURGAMENAME.000 to Compiled/Linux/data/ac2game.dta (shouldn't be necessary once the hard linking issues are sorted out).

Edit: The missing resource files in the Windows file was actually my fault. I failed to recognize that the folder name was included when using a filemask in Utilities.GetDirectoryFileList.

[only thing]

Glad you got it working!

the only thing that I still have to figure out in your post is as follow:

I'll also mention that using a name like "Update_Runtoolbar" when you're changing other things like the player's animation speed is a very bad idea, which is why I renamed the function.

I am a lover of perfectionism too, but i could not call this current function abcdefg() and to check if the player HasExplicitTint ?

You can, of course, name functions whatever you want, but this really comes down the the programming idiom that your function names should represent some type of contract with the user (whether it's yourself (now), yourself (a year from now), or someone else entirely). With a name like "Update_Runtoolbar" this implies that the only thing the function is doing is updating the graphics on the toolbar. This could lead to serious confusion or cause "bugs" which could be difficult to track down. The way you have it set up, the toolbar's graphic is directly tied to the player's stamina, which is fine and it makes sense to do it this way, but the logical connection is that the toolbar reflects the stamina, not the other way around.

Since the toolbar reflects the stamina, then the user is far more likely to expect the toolbar to change when the stamina changes than to expect the stamina to change because the toolbar changed. So if you tell the user "I'm going to update the stamina" and the toolbar graphic is also updated, there's no breech of contract here because those things bear this logical relationship. However, if you tell the user "I'm going to update the toolbar graphic" and you start changing the player's stamina variable, player's animation speed, and/or any other side effects, then you have essentially broken the contract that the user thought they were making.

This is the core of what I was saying about the function name: If your function has side effects other than what the function name says it is going to do, they must be obvious (or at least have an obvious correlation). If you have a function with no side effects (e.g., the function just checks things, it doesn't change anything) then it is less important to explain the nuances of the function (e.g., naming a function "abcdefg" and checking player.HasExplicitTint doesn't change anything, so it's less dangerous than a function named "abcdefg" that changes the player's tint, scaling, and view). If in doubt, don't hesitate to make your function names long to explain what the function is for -- a function called "UpdateStaminaAndRunToolbar" is even more explicit in what it's doing and makes it totally clear to the user).

At the end of the day, it's up to you to decide what you name your functions, but as someone with more than a decade of programming experience, I can assure you that when you come back to this code in a year or two, your future self will greatly appreciate the few extra seconds you spent typing out the more elaborate/explicit names.

[and]

I was going to comment on this before, but I forgot.

The logic in this code is simply broken. What you are doing is this:

* If player is in run mode and moving, increase run_counter
* If player is not in run mode or is not moving or both, decrease run_counter
* If run_counter is greater than 240 (player has been actively running for at least 240 game loops, e.g., 6 seconds without stopping):
|-- * reset run_counter immediately to 0
|-- * then check if run_counter is less than or equal to 5 (always true, since you know that it's 0)
|-- |-- * if it is (it always is), then update gRunToolbar.BackgroundGraphic
* If player is not moving or is in walk mode or both, increase recover_counter
* If player is moving or is not in walk mode or both, decrease recover_counter
* If recover_counter is greater than 240 (player has been standing still or in walk mode for at least 240 game loops, e.g., 6 seconds):
|-- * reset recover_counter immediately to 0
|-- * then check if recover_counter is less than or equal to 5 (always true, since you know that it's 0)
|-- |-- * if it is (it always is), then update gRunToolbar.BackgroundGraphic and player.AnimationSpeed

The problem (as I see it) is that you're treating the loss of energy and the recovery of energy as two separate, totally unrelated things. Here's what I would do instead:

* Use a single variable for player's energy, say "playerStamina" (initialize to 6 seconds).
* Use a separate variable to delay energy recovery, say "playerRecoverDelay" (initialize to 1 second).
* If player is in run mode and moving and stamina is not completely depleted:
|-- * Decrease playerStamina.
|-- * Reset playerRecoverDelay to 1 second.
|-- * Set toolbar graphic to 57.
|-- * Set player.AnimationSpeed to 5.
* Otherwise (player is not in run mode or player is not moving or player stamina is depleted):
|-- * Reset player.AnimationSpeed to 3.
|-- * If playerStamina is 0 (energy is completely depleted), set toolbar graphic to 58.
|-- * If playerRecoverDelay is greater than 0, decrease playerRecoverDelay.
|-- * Otherwise (playerRecoverDelay is less than or equal to 0):
|-- |-- * If player has not fully recovered their stamina (playerStamina is less than 6 seconds):
|-- |-- |-- * Increase playerStamina.
|-- |-- |-- * Make sure toolbar graphic is set to 57 (in case energy was totally depleted).
|-- |-- * Otherwise (player has fully recovered their stamina):
|-- |-- |-- * Reset playerRecoverDelay to 1 second.
|-- |-- |-- * Set toolbar graphic to 56.

Planning out what you're going to do before you start typing code can help you see and prevent logic errors like you currently have in your code (e.g., checking the value of a variable you just set!).

Here's what it would look like in code:

Code: ags

#define PLAYER_STAMINA_MAX (GetGameSpeed() * 6) // 6 seconds, regardless of game speed
#define PLAYER_RECOVER_DELAY GetGameSpeed() // 1 second, regardless of game speed
#define PLAYER_WALK_SPEED 3 // player's walking animation speed
#define PLAYER_RUN_SPEED 5 // player's running animation speed

int playerStamina; // player's remaining energy
int playerRecoverDelay; // time remaining (in game loops) until player begins recovering energy
bool ModeRun; // NOTE: You haven't shown where this is updated

function game_start() // NOTE: I use game_start to initialize my variables since I'm calling GetGameSpeed()
{
  playerStamina = PLAYER_STAMINA_MAX;
  playerRecoverDelay = PLAYER_RECOVER_DELAY;
}

function UpdateStamina() // renamed to clarify what this does
{
  if ((ModeRun) && (player.Moving) && (playerStamina > 0)) // player is actively running
  {
    playerStamina--; // lose energy
    playerRecoverDelay = PLAYER_RECOVER_DELAY; // reset this if player starts running after recovery has started
    gRunToolbar.BackgroundGraphic = 57; // update toolbar graphic
    player.AnimationSpeed = 5; // update animation speed
  }
  else // player is NOT running OR player's stamina is totally depleted
  {
    player.AnimationSpeed = 3;
    if (playerStamina == 0) gRunToolbar.BackgroundGraphic = 58; // energy is completely depleted, update toolbar graphic
    if (playerRecoverDelay > 0) playerRecoverDelay--; // player is waiting to recover energy
    else if (playerStamina < PLAYER_STAMINA_MAX) // energy recovery has begun
    {
      playerStamina++; // increase energy
      gRunToolbar.BackgroundGraphic = 57; // make sure toolbar graphic is updated (in case player energy WAS depleted)
    }
    else // energy is fully recovered
    {
      playerRecoverDelay = PLAYER_RECOVER_DELAY; // reset delay for next recovery
      gRunToolbar.BackgroundGraphic = 56; // update toolbar graphic
    }
  }
}

This might require some tweaking to get this working exactly the way you want, but this actually keeps the loss and recovery of energy tied to the same variable, and the "delay" variable is just used as an additional timer to force the player to wait a bit before they start gaining energy back. I'll also mention that using a name like "Update_Runtoolbar" when you're changing other things like the player's animation speed is a very bad idea, which is why I renamed the function.

I tested the compiled files this outputs on Linux Mint 17 and it ran fine for me. What permissions does it show for the file?

I'm looking into the hard link code as well.

Actually, yes. I've heard that before. Sorry! iOS doesn't allow any external assemblies, so the stub would have to be built into the iOS port of the engine to be able to load properly.

Of course someone needs to provide a new build of this, but I just wanted to point out that the Steam plugin has an open-source stub (which also needs to be built for iOS, but it can be built). I've never built anything for iOS or even really used Mac OS, but I have a virtual box running OS X Yosemite with XCode installed. I've been meaning to take a look at it (among all the other things on my plate).

In the mean time you could check System.OS, though that would break if a real replacement were used in place of the stub.