Times, trials, and turbulence.
Monthly Archives: December 2007
BattleForge is moving along steadily, despite my dislike for writing GUI systems. With the development that was done today, the most tedious parts of the editor are (arguably) at a close. Thank goodness. 🙂
The Modes of the Trade
I decided early on that I would continue the trend of my last editor for Skirmish, and break the editor into several modes. Originally Map Settings and Ambient Settings were to be modes, but that felt a little excessive. Depending on what mode the user is in, the user’s actions and abilities to manipulate the environment are limited based on that mode. For example, inside of Tile Mode, the user has no risk of accidentally modifying props above certain tiles they are trying to edit. The modes are as follows:
Tile Mode: Tiles are the main building block of the game. These are square 32×32 images that can be stacked on each 32×32 grid location on the map. Each tile defines its own collision parameters versus the world, projectiles, and other objects. Tiles are placed/erased by means of selecting rectangular regions of the map to apply a tile to.
Prop Mode: Props are the objects in the world that are influenced in some manner by the physics engine. Dynamic props are directly simulated, and static props who can be damaged and (in most cases) destroyed. Props can be placed at an arbitrary X/Y coordinate, as well as an elevation from the ground.
Decal Mode: Decals are no more than static images that can be placed arbitrarily around the world. They have no physics or collision detection, and exist soley for decorative purposes.
Patch Mode: Patches are a new concept that hasn’t been discussed here yet, although you can see an example of a ‘ground patch’ here. A ‘patch’ is an arbitrary convex polygon with a specified texture and a ‘fade distance’. In the aforementioned image, the texture is grass, and the fade distance is how far from the polygon the texture will go before fading entirely back into the map’s ground texture. Right now only ‘ground patches’ exist, but this is planned to be expanded into allowing things like bodies of water, or toxic waste spills that can damage players.
Light Mode: Lighting is still a tentative subject. It hasn’t been decided whether the lighting in Skirmish will be static or dynamic, but per-tile lighting will be implemented in some form. This mode will allow for the placement of different types of lights, with varying styles (point light, spot-light, omni-light…) and colours, as well as the manipulation of existing lights.
Above you can see the icon-buttons for the five modes in action, as well as the recently implemented ImagePalette and Scrollbar GUI components. Both were (naturally :)) a pain to implement. However, with these done, the main “boring parts” are over. At this point it’s really just a matter of coding in tile placement/erasing, and then reusing the ImagePalette for the Prop and Decal modes and implementing them as well.
Getting Started on the Map Editor, and The Slump(tm)
As I’ve been hinting at for the last week or two, I’m at the stage of development where creating a map editor is overdue. Up until this I’ve been generating simple 50×50 maps consisting of randomly-sized rooms. This should be painfully obvious to all of you who have been keeping up with progress over these last several months. 😉
Writing a map editor can be a task ranging from simple to insanely challenging; it all depends on who your audience is. Any lone programmer’s favourite is likely the simple-to-code-but-incredibly-archaic editor, which the programmer naturally understands how to use, but anyone else is clueless. However, since the Skirmish map editor will be freely available alongside the game, I need to cater for a very wide audience. User friendliness is paramount, which means much more planning and more precautions have to be taken.
Development has been a little skittish lately because of this, since it makes the task before me feel all that more daunting. Making a clean, efficient, user-friendly map editor is a large task — just ask Jon about Stencyl! — so I’ve been relunctant to really sit down and get cracking on it.
Instinctively, fear of failure kicked in, and I tried convincing myself that I’d be better off working on a smaller simpler game project. I don’t really talk about it, but this is a nasty habit that I’ve had for ages now. When a large project starts to get to a particularly difficult part of development, I tend to saunter off and start a side project, if not quit the project entirely. Remember that Voxel Renderer? That was a product of the grimness of tackling the damage/resistances system and particle engine in Skirmish. Since a good experience came of it, I suppose you could argue that it’s a good habit. In fact, more than one of my games were brought to fruition by these means. However, if I ever want to finish Project Skirmish, I’m going to need to remain focused on it and not let myself slip off to less challenging projects. Feel free to whack me upside the head if you catch me slipping again. 😉
Stop cringing, it’s just a placeholder name. 🙂
BattleForge is the Work-In-Progress name of the Project Skirmish map editor. Like I said above, it will be freely available alongside the game itself, and will sport a clean and user-friendly interface. For those of you who have used SME, the last iteration of Skirmish’s map editor, expect to see the bar raised yet again. I don’t intend to go overboard or commercial-calibre, but my aim is to make the editor simple enough that somebody with no knowledge of how Skirmish works or plays like can sit down for the first time and get the editor to do what they want with minimal hassle.
Naturally this means that lots of fine-tuning will need to take place as development progresses. I haven’t decided how I’ll manage it just yet, but it will likey be something like posting betas on my development journal here and collecting what feedback I can from readers. By listening to the users of the editor as much as possible, I should be able to get the editor in good enough shape that it will be more than ready by the time the game itself is open for Beta.
Where does BattleForge stand right now in development? Early yet. One of the concurrent tasks that must take place is the creation of the GUI system, which will manage all of the user-interactable components like buttons, panels, menus, and so forth. I realize it is possible for me to embed an OpenGL screen within a Swing or SWT window and use a Java windowing library for my interface, although I’ve decided against it. Why? One reason is that I simply loathe Swing and SWTs’ APIs — tons of bloat. Rolling out my own system using OpenGL ensures that I have everything that I want, and that it is integrated seamlessly with the rest of the game.
That said, development is still very early, but the rough shape of the editor can be seen in the screenshot below. The idea is to have a hint/info-bar along the bottom, and a side-bar along the right side of the screen. The side-bar will be able to move between several different modes depending on what the user wishes to edit (tiles, props, decals, lights, etc). A mini-map will also be implemented for easy navigation of the map, although I’m unsure of where it will be placed as to not obstruct.
I’m still going to hold on to my original (loose) goal of having something downloadable (alpha of course :)) by the end of my Christmas holidays, which should be a safe bet now that I’m past the initial barrier of getting started on it. We’ll have to see if I can port some of the maps from the last iteration of Skirmish over, too. 🙂
For those of you who remember the gamedev article I was previously working on, you’ll be happy to know that the near-final draft is completed. Between studying for finals today seemed like a good day to get the article finished and (almost) out the door.
To anyone interested in the topic of metaballs and/or isosurfaces, or the topic of game development in general, I’d be very interested in receiving any feedback or comments on my article. This is the first time I’ve really sat down and wrote one, so there has to be plenty for me to improve upon.
The draft is in PDF format, which means that the links will not be clickable (doh). Most of the content is in the article itself though. This will be fixed in the final version. Also downloadable is the “Meta Playground”, where you can toy around with five different meta-shapes. If you have trouble running it, you might try downloading the Visual C++ Redistributable files from MSDN.
Without further ado:
Once again, criticism and feedback are appreciated. 🙂
The art of balancing study time for final exams and coding time for Skirmish is a delicate one, but always rewarding for those who can manage it. 😉
One of my goals for this Milestone was to implement a working rocket launcher. Rocket launchers seem to be the cornerstone to any shooter game, which previous iterations of Skirmish never had. I quickly decided they must be added this time around. Nice and early.
Starting from the beginning, this first meant that a model for damage was needed. I decided upon six types of damage to exist in the game world, which both players (via Armour items) and props (via natural resistances) can defend against, to varying degrees. The damage types are Projectile, Pressure, Heat, Puncture, Cold, and Toxic. Most weapons will be a combination of the types, like explosions falling into the category of Pressure+Heat, plasma being Projectile+Heat, and slug rounds being Projectile+Puncture. Different armour types will enable different defences depending on the player’s style of play. This will soon factor into the health/armour system, which will be a little more interesting than the standard fare “one regular boring health-bar” or “regular health-bar and armour-bar” approaches, but still remain intuitive enough as to not confuse the novice player.
Like mentioned above, props can also be recipients of damage. Props are (optionally) destructible. This is a big step up from the last version of Skirmish, whereas everything in the game world except the players was entirely static. Props can take damage, be destroyed, be created, and react to physics within the game world. This allows for lots of interesting gameplay possibilities. Currently implemented are wooden crates which can be destroyed; spawning a cloud of smoke and flinging out a handful of broken wooden plank props from the destruction. One can then proceed to fire a rocket launcher at the nearest wall and watch those planks of broken wood go flying as well. I admittedly spent perhaps a little too much time toying with that particular case. Hopefully I won’t be the only one. 🙂
(“Watch out, Doctor Crate!”)
Additionally, weapons are implemented independently as individual classes. This means that special/unique behavior is easy to implement into certain weapons. It also avoids the mess that some games into with having a large number of weapons that differ only in a handful of stats/variables. With this, small things — but effective in adding that extra subtle feel of detail and atmosphere — like the rocket launcher having a ~1 second charge time (whereas the player must remain motionless), complete with a little progress bar suspended over his head. There’s also the fairly large recoil of firing the rocket which tosses the player back a fair amount. I won’t hesitate to admit that I spent over an hour perfecting the appearance of the explosion’s particle effects. 😉
It’s just about time for start on the map editor, but I’m already counting down the days until I get to implement the plasma cannon. 🙂
I received the image files from DogPriest for the HUD, which certainly add a greater amount of justice to it than my previous long-lived art has. You can see what the weapon slots, chatbox, and mini-map windows look like with it in the screenshots below.
Also implemented is the particle engine, at long last. I’ve always had a lot of fun with particle engines — arguably too much fun. The majority of my games have made good use of particle effects, most notably Membrane Massacre, where 99% of the visual effects were generated by the particle engine. Given this, it’s not a big surprise that I decided it was time to have a little bit of fun. 🙂
(A fun laser cannon weapon!)
(Ah, I got a little carried away. Super Duper Laser Cannon?)
I want to add several more ‘fun’ content items, like ammo clips that can be picked up and used, the explosion system (which will apply forces to all nearby props and generate shrapnel), destroying props (like breaking those darned crates), weapon recoil, and likely a rocket launcher. I wish that the development was always about the fun stuff. 😉
(EDIT: Oh, guh, and the health/ability bars were also added to the HUD, for anyone who didn’t notice. :P)
With my previous voxel renderer project finished up, I decided it was high-time that I got back to work on Skirmish. Where I left off was during my work on the HUD, with the chat/input system next on my ToDo-list.
The ‘chatbox’ serves as output for all in-game chat message as well as game events (flag capture or death notifications) and other system/network events. Messages are all timestamped and placed through a channel, so certain channels can be filtered or ignored, and optionally can be recorded and saved to the player’s computer. Another tiny plus is that channels are colour-coded for easy distinction.
The ‘inputbox’ is a simple window that allows all ‘game keys’ (movement, firing, inventory selection, etc) to be ignored while all regular keyboard input for typing messages are enabled. It took a while to get it to handle extra whitespace and word-wrapping nicely, but it seems to be fully functional at this point.
(Chatbox text is fabricated filler; minimap text was drawn in)
The above screenshot shoes the basic functionality of the chatbox, which is simple enough, and an indicator of where the mini-map will go after the map editor is created. The mini-map will rely on large thumbnail’ed images that the map editor will — once created — generate alongside the map data.
An artistic friend of mine has offered to take a shot at sprucing up the HUD a little. I mentioned that my aim is for a gray burnished metal look to the outer borders, with a darker less-scuffed metal for the inner areas of the HUD windows. I also granted him total artistic license with it, so it will definitely be interesting to see what he comes up with. 🙂