SuperSpriteSurface is a set of classes for REALbasic that provides an improved alternative to the built in SpriteSurface control. SuperSpriteSurface uses OpenGL 2D functions to offload the graphics processing to your computer’s video card. Now that REAL has officially deprecated the built in SpriteSurface control, this is quite a boon to the community. 2.0 also adds Windows compatibility.
Experience is the difference between a project taking months or days. With the first version of the engine finished, it was time to make a game with real gameplay. I had spent years learning the mechanics of game architecture without going past a simple game like Pong. At around the same time I had created the Java game engine I was working part-time in television production. One of the projects was a hockey related mascot animation. This project fell through and went very wrong. It was one of those things that seem right at the time but was not meant to be.
With a significant number of the 3D models already created and some of the animation already done, it made sense to salvage this project and turn it into a game. Using animals eliminates the sexism and racial problems that often occur in modern games so this was a win-win situation for me. The animation was improved and set outdoors and a polar bear was made to accompany the elk. The intro was animated and rendered. At this point it was around summer 2003, and I had created the basic treatment for the game that would become WildLands Hockey. Things were stating to take shape: all the final goals were planned and documented. Gameplay was flashed out along with look and feel.
The second version of my engine, which now included network support, was completed a month before the uDevGames Contest deadline, along with a simple Pong game. Thus, the final stage of game design and development for WildLands Hockey began. Game character graphics were created with animated cycles for the skating elk and head turns for the bear. The idea was to keep this game small as my web space was rapidly being used up.
Some size experimentation was done with the characters and puck to see what looked and felt right. The character graphics were rendered in Lightwave 3D with a sprite plug-in. The time clock and game timer were first, then the goalies were added and their motion created, which would simulate inertia and momentum. They only move on one axis and their motion was the basis for all the other character motion. The goalie motion was later changed to be based on the player motion. This simplified things and allowed for less data to be transmitted in a network game. With the goalie done it was on to the puck. At this point I decided to start with the in-game sound design as I would be in those locations of the code. So, puck related sounds were edited and prepped. Various sample rates were used to get the best sound and size ratio; as most of the sounds were low quality it was somewhat of a challenge to get them to sound halfway decent.
If you do not know much about the importance of sound then take a tip from those in film. Sound is essential—people tolerate bad picture but not bad sound. Do the best with what you have but never skimp on sound. The great sound on the C64 and Amiga is part of what makes these systems so legendary. The sound systems in my first and second engines were also spatial and velocity based. This further enhances player experience by simulating the audio environment. Fast actions trigger louder sounds, and sounds play through stereo speakers on the side of the screen where they occur.
The puck actions were mapped temporarily to the keyboard to create and fine tune its motion boundaries and reaction in the game. Interactions with the boards, goalie, and net were finished along with most of the gameplay states. This made sense here as the puck is the focal point of the game. Its actions drive the states.
With the puck completed, the players were last. I approached this with multi-player in mind initially, as I wanted to triage the seemingly more complex parts first so that the 2004 contest would not be missed. Player motion was designed and implemented first, then player interaction with the boards and other places on the rink. Puck and player interaction was done, then stick and puck interaction. I spent a good portion of time making all these simple details work the way I felt they should. I wanted it to feel right. These simple little details combine into the complex gameplay that can either be fun and interesting or tedious and boring. Later beta testing with complete strangers would determine if I had something worth playing. Shooting was then added, and lastly player-to-player collision.
With the multi-player game completed, the client server network game state system from version two of the engine was updated, adjusted, and tested to work with WildLands Hockey. The nice part about code reuse is that not only do you avoid the tedium of doing something over but you know that it will work. The network gameplay required some minor adjustment and went quite smoothly. It is not perfect but some things were just beyond my capabilities.
Given the need to communicate with text and numbers, fonts and localization can be an issue when your game is meant for worldwide distribution. A system was required to handle generating and displaying text in the game. In keeping with the sports theme a matrix system was designed. This allowed me to program text and numerals on the fly and display them without having to worry about fonts, cross-platform text or other languages. The matrix system is based on the kind you see at a hockey arena (or used to). I had spent two years in TV working at hockey games so I had more than enough time to study this and create my own version. I even put in crawls and scrolls like you see in the credits screen.
Experimentations began as to what codec would provide the best quality and least amount of size with full screen playback ability on most systems. Animation can really suffer from the wrong kind of compression—all of the beautiful time-consuming details can be wiped out or blurred beyond comprehension with the wrong compressor or settings. After much experimentation QuickTime H261 (similar to MPEG1) was used, as it was the best for all requirements.
I called on friends, family and whoever to get the network and other alpha testing done. Some minor tweaks and bug fixes later, I submitted it to the REALbasic games list for beta testing. The general consensus was that the game was way too hard to play. One of the developers on the list informed me that developers usually find their own games too easy to play. He said you should make the game far too easy for yourself to make it accessible for your perspective players. I took this advice and made the AI easier but also adjustable to keep it harder for advanced players. I also made the players skate faster and their sticks bigger to make getting the puck easier. With some other issues fixed and time running out things were not perfect but I was pleased with them. There comes a point when you need to just release your art, as it is never really done. Also, while the input of beta testers is invaluable you probably will not be able to get all the requests in. The best is to compromise on those large changes that may not be feasible.
Before starting the original development, I went out for lunch with a friend and former coworker who is also a programmer. His background is in networks and security, mostly on Unix. When I told him about the game I going to do he asked if I was going to have a network multi-player mode. Up to this point I never even thought about something like that. I had never done network programming before, even though I was a network admin in my time in the IT work force, and knew what it was all about. Out of ignorance I said I would make things multi-player over the network—how hard could it be right?! With his network programming background and some of his help I could get up to speed and do what needed to be done fairly quickly. This was early Fall 2003, when it became apparent that a version two of the engine would need to be created for full network game play. The game would not be completed for the uDevGames 2003 Contest. I had more than enough experience as a programmer working on large projects to know this. I had not entered yet so it was not a problem; things could wait until next year.
The sprite surface control in REALbasic was not designed for network multi play. In fact some said that creating a real-time 2D network game like this just could not be done. I was already too far into it to listen to that—it had to work. I came up with a multi-threaded model that would work around this. However, in order for things to work across all platforms I needed to use an experimental version of REALbasic. At this time Real Software was redoing the whole thread model across REALbasic. This, along with some other issues and projects that needed to be finished, placed my second version of the engine and WildLands Hockey on the back burner for some months, until the newer version allowed me to finish it.
If game programming is a black art then network game development is a 33rd degree black art shrouded in the deepest of mysteries. Finding information on it proved to be very hard. Most books simply show you how to set up a socket and send packets back and forth. Network game development is so much more than that. I got help from Aaron on the network communication system, which is an extended UDP socket that would fulfill all the communication requirements for a game. The work developing an interface menu and internal game system to connect two hosts was also a big job. There was much to think about. My solution was to look at other games and pick what I liked and what was also simple and feasible for a person with small resources. At this time my head was really starting to hurt with all the intricacies of network game design; single local game design really looked very simple now in comparison.
In late summer of 2004 everything was ready with the new version of REALbasic and so was I. It was back to version two of the engine to create at least a basic working network engine for 2D games. The latest version of REALbasic also had the bonus of a remote debugger, making things much easier. I looked at all the resources I could on network game design and what I could not find was done by trial and error. By the end of September 2004 I had a working network game that was like Pong running in version two of the engine. Network connection, sync, packet loss, lag, prediction and all the other network related issues I had faced were mostly solved. I placed this engine on the web with its complete docs and a basic network game programming theory paper I wrote, in the hopes that it may be useful to someone else facing the huge proposition of creating a network real-time game. In retrospect if I had known the work involved I may have never tried this. Ignorance is probably responsible for more things out there that we could imagine.
The sound designer dropped out with no work completed. This is to be expected when your project does not pay and paying work comes in. I decided to do the sound design myself. This is why there are no sound design credits and some gaps where the sound designer credits were to be. I spent a great deal of time scouring the web and elsewhere for free and royalty-free sound effects. I managed to get an adequate selection of lower to medium quality sound effects that would suffice for the game and intro.
Pixel level collision was too sensitive for player-to-player collision and felt wrong. I came up with a distance-based system that makes the game player interaction less touchy and more real.
The AI for single player mode was the last thing to be created. AI is not my cup of tea and some design flaws reared their ugly heads. I had spent so much time on the multi-player mode that not much forethought went in to the single player mode. I was able to crank something out with a few kludges that was actually better than I had expected it to be but far from perfect.
With the audio designer dropping out my work load became much greater than I had planned. Thus some of the polish suffered. I was not able to get an in-game user controls section and it was a late add in the start up screen. As well I never had the time to make a better user guide in the game, or at least an HTML file, as opposed to just text.
The WildLands Hockey project was a big learning experience that put all my skills and years of experience to the test. I wanted to finish a commercial grade game (circa 1990) before I hit 30. I didn’t quite make it, though I was close. Many of the game’s features and design were made for me. I wanted to make things the way I would like them to be. There are such things as cool features not getting in the way of the game. So many games are created with glitz first, but to me the worst of all is making it so real it gets in the way of the gameplay. Some examples of this are the game intro. Sure I worked really hard on this, but it will only play the first time the game is played; after that you must select it from the menu. An intro is cool the first few times, but after fifty it can get irritating when you just want to play. Mine also has a click to allow you to exit it. This common courtesy I feel goes a long way to providing an environment that a player will want to return to.
WildLands Hockey is client server based; each frame in the gameplay is stored in a state that can be transmitted in a packet for network play. This same design can allow for replays very easily. While this is a cool real feature I felt it just hinders gameplay. I worked for two years in TV for a local hockey team and most of that time I ran VTR and did replays so I am sympathetic to this cause. However, while real players and officials need that time, computers and computer players do not, so it can appear to just get in the way especially when the game is only three minutes stop time. You don’t want to spend more time on extras than on gameplay. If people want reality then they can get their skates on instead of playing my game. I feel game developers need to offer their players more fun than reality.
I hope the simplicity of this game will appeal to people even where hockey is not played—this is one chance you take when your game may have a more regional appeal. I certainly learned a lot about myself and game development on this project. Somewhere along the way this project did become work. It is something I am proud of and something bigger than myself that I can leave behind for others. Who knows, maybe this game will some day end up in a Mac or PC emulator similar to the C64 collection I have that reminds me of the many of hours of entertainment I had back in the 80’s and provides inspiration for today.
After being around since the VIC-20 and working in IT, including networks, database admin, and as a member of a few large and small development teams, I have seen a lot over the past many years. I’m beginning to feel like a dinosaur. I’m losing interest in much of modern computing as I look back on the golden age with increasing fondness. This was probably obvious as my game was not much different than what you would have found in an arcade many years ago. In all this time I have never even tried any 3D programming due to a lack of interest, but as that is where it all seems to be going I’ll either have to get with it or do something else. I may eventually do more games and maybe salvage my Java engine to the mobile world, but who knows what the future holds. For years I have wanted to finish a larger game project and now that it is completed it is a bittersweet accomplishment. Some of the magic is lost once the mystery is gone.
* Developer: Kevin Dromereski
* Genre: Arcade
* Team Members: 1
* Development Tools: REALbasic, MBS plug-in
* Animation & Graphics: Lightwave 3D 7.5, Photoshop
* Video & Sound: Sony Vegas, Digital Media Workshop, SoundEdit
* Hardware: 12” iBook G3 800MHz, Custom-built Dual 1.8GHz PC (Windows XP)
Bio
Kevin Dromereski has a computer programming analyst diploma and a system engineer certification. He has worked in most capacities of information technology including software development, database admin, network admin and secure ecommerce web design and setup in both large and small companies. Over the past few years he has been running his own company, living in poverty to focus on more fun and creative endeavors. These include television, film, stage and digital media content creation.
Not really. I do submit bug reports and occasionally post to the developer mailing list but that’s all. I used to be more active in the REALbasic early years.
Coldstone is divided into two parts: the editor and the compiler. The editor lets you manage the different parts of your game and put them together to create the story and gameplay. The compiler then takes all this stuff and creates a stand-alone application on either Mac Classic, Mac OS X or Windows. The editor is almost 100% REALbasic code but the compiler and the resulting applications are 100% C++. This allows for fast and professional games. We used Metrowerks CodeWarrior to develop the engine core.
Photoshop, 3D Studio Max and Graphic Converter.
First, the sprite engine supports multiple layers and sprites of any size. This lets you create any type of world you want by placing several different pictures here and there, or you can use one big picture for a whole map (like in Baldur’s Gate). The sprite engine (and editor) doesn’t make any distinction between an animation and a still picture (with little exceptions). This means that you can use the very cool (yet powerful) animation editor to create an animation and just add it in the map, in any layer you want. Second, the engine is true 32-bit color, which means that translucency effects are possible with picture formats that support alpha masks such as PNG. Also, all the game “windows,” like the shop interface for example, are rendered by the sprite engine to make them platform independent.
There is no limit. You can have an 800×800 character but it may be hard to control on screen. As for frames, it’s unlimited and really up to you. You could let your game take 200MB RAM if you wanted to.
Once again, RAM requirements are your only true world limitation in Coldstone. However, if you want to be able to edit a 1000×1000 map in the Coldstone Map Editor, you may have to give some more memory to the application. RAM really is the only limit you have. Give it more RAM and it will give you the power you need to create that 5000×5000 map you always dreamed of!
The developer can decide at which resolution and color depth the game will run.
Coldstone allows enhancement to the game but not to the engine itself. A Coldstone developer has the option to enable plug-in support for their game. So hopefully a good community of plug-in developers will also grow. Things like creating a new renderer or new battle engine through a C++ plug-in aren’t possible though.
When you create a Coldstone game, you have to specify a creator code. If a developer creates a sequel to their game and gives it the same creator code, the saved game would be compatible between the two games.
There is no real physics engine in Coldstone. You could easily fake physics with the animation editor and its keyframe animation abilities though.
The combat system core is hard-coded but the gameplay isn’t. While you can’t recreate the AD&D combat system, you can be very creative in your opponents’ look and behavior. PoG, the game we are developing with Coldstone, is a good example of this. We have standard rush-at-the-enemy monsters, but we also have original ones like earth elementals that summon earth columns from down under you (and that hurts!). The spell system is also very open and opens a wide range of new possibilities to the game designer.
Theoretically, the magic system in Coldstone works with spell points. You could, however, use the event system to script yourself a new kind of magic system. Who said that it must be called “magic” anyway? You could create a futuristic game and call those “Bionic super powers” or something neat like that. The nature of these spells or bionic powers is all yours to create! Coldstone is bundled with a user-friendly spell editor.
Coldstone offers the developer the ability to create “global keydown events,” which are basically events that are fired when the player presses a certain key. At this point, the only limitation is the event system.
No.
It creates a stand-alone application for Mac OS Classic, Mac OS X, Windows 95/98, and Windows ME/2000.
REALbasic seamlessly did most of the work for the editor. REALbasic has some nasty Mac OS X bugs so I had to code a couple of workarounds, as well as modifying the interface and the help system to fit Mac OS X standards. The compiler of Coldstone is, however, pure C++. Again, it wasn’t that much work since it has been designed from the start to compile on Mac OS, Mac OS X and Windows.
Ambrosia has the online infrastructure required to support such a product. They have a very good web board system that will let the Coldstone developers exchange tips and tricks, as well as a good archiving system so that the Coldstone community will have a place to download up-to-date add-on files for Coldstone and upload their creations. This will also let people of various professions (musicians, 3D artists, etc.) meet and create cool new games. Beside this, Ambrosia has a cool and helpful staff, not to mention their marketing potential in the Macintosh gaming market.
Such details are unsure at the moment.
Again, this is not set in stone but the developer will probably be required to display the (very nice) Coldstone badge somewhere in their product.
coldstone06.jpg
They both let you create RPGs but the difference lies on the creation freedom level. RPG Maker lets you create an RPG within a fixed frame. That makes it easy to use because the creator can concentrate on the content rather than the packaging. While Coldstone offers very good tools to let the user shape their own worlds, it also provides them with the ability to modify the container: game interface, menus, even a plug-in system that you can enable to let other developers write add-ons to your game. To make things simple for beginners, Coldstone comes with a game wizard that creates a fully working game frame for you to modify. Coldstone comes up with a default medieval set but allows you to modify it at will or start from scratch and create your very own style. You can have your very first game up in minutes.
The goal was to make an engine that is appealing for both the wannabe game developers and professionals that want to quickly create outstanding cross-platform games. Coldstone is like Mac OS X — a powerful core wrapped in a beautiful user-friendly interface. Coldstone also comes with more than 10,000 graphics and animation files to help beginners create professional-looking games. There will be some low-quality games produced with it of course, but those will help the Coldstone community by providing game examples rather than hurt it, I think.