Could you show us some examples? [Of gameplay features]
[/QUOTE]
Gameplay specific features
[This is definitely a TL;DR post though there is lots to say since has a lot to it.]
These are some high-level descriptions of gameplay features. For specific code examples I’ll try to add more to the web site in the future. One feature that you can see right now is object-ids.
has essentially 4 different areas that have video game specific (or game benefiting) features and concepts:
Language
- concurrency (simultaneous / real-time tasks and logical flow of time and commands) at the language level without your brain melting. [This is pervasive throughout the language and probably the biggest game-changer - managing multiple things running around at the same time is pretty important in any real-time game.]
- (named game objects and concepts checked at compile-time)
- game focused library – common game routines and concepts like randomness
- tiny learning curve and simple yet powerful constructs that empower entire team (level designers, production, audio designers, animators, etc.) to author coder free gameplay and still preferred by the veteran coders for many tasks
- helps ensure gameplay does not become a performance bottleneck – it is easy to author tasks that are spread out across many frames
- designed to reduce common errors during traditional game development workflow - for example cod-e looks sufficiently different from C++ to ensure that people’s brains switch over if going back and forth from C++ and
- lots of other tiny details accumulated over 2 decades of use on actual games
Tools
- Skookum IDE focuses on Skookum strengths and allows easy integration with other tools in game development pipeline
- everything is designed for dynamic real-time modification during tweaking and debugging – make changes while the game is running on any platform
- IDE Console allows easy way to type in simple commands and snippets of logic to run on the game or editor in real-time – also known as the read-eval-print-loop (REPL); These code snippets are easy to swap, trade, modify and reuse
- IDE can accept command-line requests to perform actions in both the IDE or even the editor or running game
- compiler is crazy fast – the 1700 classes and 8000 script routines in Sleeping Dogs compiles in a few seconds
- simple version control – integrated and script file layout designed for scaling team and project
- scales for a team environment – especially more than one person working on the same area without bumping elbows
- compliments all development areas: in-game(simulation, user interface, settings), tool automation (world editor, build system), etc.
- modular design facilitating patches, add-ons, downloadable content (DLC) and user created content
Runtime
- optimized for AAA game performance in both speed and memory - for example string comparisons are shunned throughout the code base and a symbol mechanism - sort of like an enumerated type - is used instead
- scripts are compiled and runtime does not even need parser / compiler in ship / release version of game
- scripts can be dynamically loaded and unloaded as needed according to game progression, geography, etc. [This was critical on the open world game Sleeping Dogs – there were too many missions and ambient world behaviours to fit in memory.]
- systems are predictable / deterministic and allow a great deal of low-level control if needed
- Time is managed consistently in terms of game update frames rather than less predictable interrupts, etc. [You still often say something will take X seconds though internally that will be measured over however many update frames is needed.]
Philosophy
The guiding principle that is designed for games - while not exactly a feature - is a critical advantage.
- There are game features that Skookum can justify having that a general purpose language could not. Sometimes such features can be added in libraries though tend to be clunky and error prone compared to being built into the language. This is important for the future is well - there are plans for even more game specific features for future updates.
- Likewise Skookum specifically does not include features that are not needed for gameplay or that are better done at the low-level in the engine in C++. This keeps it much more focused and increases the signal-to-noise level so that we poor developers can store the already massive amounts of info that we need in our limited brains.
- The point of is to make it easier to create great games and get out of the way and not spend huge amounts of time mucking with the details. A motto for is: spend time on what rather than how.
[The details of these features will eventually be described in the online docs – which are currently in progress.]