Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Feb 2008
Offline Last Active Today, 06:27 PM

Posts I've Made

In Topic: Where did you attend college and where are you at now?

10 August 2014 - 09:39 PM

EDIT: Retracted. I took a cue from your post and filled in the blanks. My apologies.

In Topic: Make file unreadable by an external program

29 July 2014 - 08:52 AM

Chris hit it on the head, the question is: why? The answer to your question entirely depends on your answer to that question.

In Topic: How to exit the game gracefully?

18 July 2014 - 07:56 AM

There are a number of approaches. The best approach is one that suits the context. The biggest complexity is how to handle saving data. If players will not wish to manage their own saved games, or are otherwise restricted from doing so, then it's reasonable to auto-save the game when exiting in most circumstances. If automatically saving the game is not a reasonable option, then a prompt might be a solid choice.


After reading this, one approach I considered to avoid cases of accidentally exiting the game would be to impose a time on the interaction of instructing the game to exit itself. Rather than allowing the player to tap/click the exit button, and then implementing something like a timer, make the exit button a 'hold button.' The player would be required to depress the button for a minimum length of time, such as 1.5 seconds. The interface device would then provide visual (and possibly auditory) feedback to indicate the progress toward exiting the game. This minimises the risk of accidentally hitting the wrong button, and diminishes the likelihood of exiting without thinking. Simultaneously it provides feedback to the player and does not require the player to wait, inactive, while a timer expires. Implemented well, it should be a satisfying interaction.

In Topic: FileSystem Cross-Platform

21 April 2014 - 10:32 PM

Hi Alundra,


KulSeran raises some good points, and it would certainly be worth looking into the examples he's provided. I've built a framework in C# (using Mono) so that I can deploy games across different platforms. In doing so I have dealt with, at least, a subset of this problem. I haven't provided access to all File IO methods, but I have created a limited interface that has served my purposes.


My approach has been to employ a number of handlers for file operations, each being extended with platform-specific implementation. I've been primarily interested in simple IO, reading and writing with path conversion, but the approach might be applicable to your problem too. Firstly, I have a number of base classes.

public class AssetIOHandler...
public class StorageIOHandler...
public class FileSystemHandler...
public class SystemPathValidator...

The first handles input-only from the asset file structure. In the case of Android this would include bundled assets, for example. The second handles read and write access to storage, useful for writing save and configuration data. The third handles checking for existence, directory operations, etc. This seems to be the crux of your question. The fourth takes in a generic file-path (in my case using the Windows standard), and converts it to a platform-specific file path.


Currently instances of these classes are maintained in a static class that automatically handles converting paths before sending them to IO or Directory methods, checks for illegal states, etc. It could easily be handled through your application or game class or wrapped in an IOHandler class instance, however, if you'd rather avoid statics/globals. This approach allows me to define default behaviour, even if that's throwing an exception, and cleanly build the functionality for each platform without impacting on the interface or employing too many preprocessor directives. I simply then set the correct functionality when the game is launched prior to any IO operations.

In Topic: Why a "Game" class?

06 April 2014 - 08:24 AM

Using a game class has a number of other potential advantages. Firstly, it can allow you to benefit from inheritance and polymorphism. If you're utilising an underlying framework, that framework might provide a Game class which can be extended, thereby handling much of the lower-level stuff. Certainly this can be handled using a number of separate systems, but there's certainly scope for conveniently handling timing values and calls to update the input system through a base class.


In the same way, you can benefit from polymorphism. In the Heron Framework, which I've developed and used for a number of years, there are multiple extensions to the game class that provide more specific functionality and, more importantly, there are different versions for different platforms. Once again, there are other ways to approach these issues but this is one convenient one.


There's also the possibility to consider scope for multiple 'games.' In Heron, there's a 'GameMode' class which provides the functionality of a game loop but is managed by a game. This effectively allows multiple 'Game'-type classes to be created, loaded, unloaded and run. In this manner separate components can be loaded separately and unloaded when not required, though this is usually handled in other ways. More often, I use this class to create a single game class in a portable library.


A final way in which multiple 'Games' might be employed are in tools. While not games, a number of the tools I have created employ Game classes to manage components that utilise the graphic device and may also employ the input system or content pipeline. In such cases it is beneficial to separate the game from the remainder of the application, and also sometimes necessary to create multiple games and run them simultaneously.


These are some of the reasons I, personally, choose to use game classes. Like rip-off, I also have an aversion to globals. That said, there are many other valid approaches to the problem, such as utilising a graph of systems and components.