HSL Programming Patterns
What are Programming Design Patterns in HSL?
When programmers create code, they often find themselves writing similar code over and over again. Programmers who program a lot, generally create libraries of re-usable code snippets that they can then copy/paste into new programs. This saves them from re-typing the same code over and over again. The concept of design patterns in programming is an outgrowth of this practice, but instead of storing code snippets, programming patterns record the pattern that describes how to create the code that solves a particular problem. Patterns are a way of communicating large concepts in a common language.
- A Pattern is not the code itself, but is instead the outline that describes all the pieces and how they interact.
- A Pattern sketches out all the major pieces that go into solving a specific, common problem.
- There may be more than one pattern to solve any one type of problem, though it is usually best to avoid this unless absolutely necessary.
Design patterns can be thought of like the patterns used by seamstresses when creating a new piece of clothing. Or like the architectural plans for building a house (though not as detailed). With a house, the painters all know and have mastered the patterns that allow them to paint successfully. They have a set number of ways to approach any painting problem. The same goes for hanging dry wall. They learn all the different ways (patterns) to accomplish their job in a variety of situations, and builders generally have common solutions to common problems. They know from experience what must be completed in what specific order and how they will go about doing it. Programmers do the same thing.
When programmers build our structures, we call them systems, utilities, libraries, databases, etc. Every time we create code, we are following a pattern, even if we don't even know exactly which programming pattern it may be. Design patterns help to standardize programming practices so that everyone will have a common ground upon which they can better understand what is being programmed. This is especially useful to managers who are not often in the thick of the code. If you tell a manager that you'll be using the "Observer Pattern", managers may then have a better idea of what the end product will do and how it will function.
For our needs, we must understand the patterns which are relevant to HeroEngine. There are particular implementations of well-known patterns, and new game-specific patterns can also be created depending on the need of each licensee. It is recommended to learn what patterns are and to learn about the existing patterns used in HeroEngine, so that it is not necessary to "re-invent the wheel" with new patterns, when existing ones may be used instead.
Common programming patterns
- Main page: Collections
A collection pattern involves the storage and retrieval of data. That data is stored temporarily or permanently somewhere on one or more persistant storage device/s. Different implementations of this pattern are optimized for specific purposes: large amounts of storage, low memory usage, quick access of the data, quick storage of the data, etc.
Because this is such a common thing, HSL needs to implement common methods of storage. GMs should not have to create their own collections. They should use an interface to a system that implements the appropriate Collection Pattern.
- Client Data System (stores data on the client)
- It allows for the retrieval of all data at once (not a single piece of data)
- It allows adding data one piece at a time
- Does it allow adding multiple pieces of data at a time?
- Server Data System (This doesn't yet exist)
- Need to create or determine if such a thing exists on the server side
The API Pattern implements a set of functions that stand between something that wants to operate on data that it doesn't own, with a system that owns that data. The API acts as a standard way to operate on the data without having to know how that data is stored, who owns the data and what needs to be done to do specific operations on that data. This allows everything that is behind the API to change, without the API itself changing.
- The language supports this by allowing Scripts to act as the only way to access and operate on data in a specific class.
- Special API scripts can be created for a specific class
- Fields in classes can be made private, which makes them only accessible to their API scripts
- All Patterns are implemented as part of other patterns, such as the Collection Pattern.
Object Oriented Pattern
- This is implemented by the language itself.
- Fields on Classes can be made private and accessible only from a single script
- Inheritance is supported through Class Glomming
- Polymorphism is supported (mostly) through Class inheritance and the API classes associated wtih them. The language will pick the right method in an API class even though two Classes' API's implement the same function name (if it can't, HSL will error).
- A world, such as Hero's Journey, typically exists as a bunch of data objects (nodes)
- Main page: Observer Pattern
When scripts want to "listen" for changes to data or events, they implement this pattern. The observer has a way to register to listen for a particular event. When that event happens, the observer is told by calling one of its functions.
- Event System (used to listen for changes to specific data)
- The Event System is told what events it needs to listen for (hard coded)
- Other scripts actually listen for the changes to the data and then tell the Event System
- Designers use the Event System to implement their own Observer Pattern.
- HSL supports listeners by allowing class fields to be given a specific script which will be called when data changes on that field.
- The Oracle Pattern uses the Observer Pattern Pattern and makes use of the Event System
- Main page: HSL Oracle Systems
This is an HSL implementation of the pattern. The Oracle System is a framework/pattern/required interfaces used to implement the Client Listening for data changes on the server, and potentially uploading data changes to the server.