Times, trials, and turbulence.
Monthly Archives: February 2008
I can’t believe it’s been two months that I’ve been working on this gosh-darned map editor, but I’m very happy to say that it’s done (the Alpha release, that is) and just about ready to be distributed. I can hardly wait to jump back into development on the actual game itself. 😉
(Battleforge — nearly ready to go!)
The last feature missing, which was mini-map generation, is now implemented. I ended up using a slightly different approach from the one I outlined in my previous entry. The original plan was to render everything to a bitmap in memory and then save it as a PNG to disk for later usage in-game. It was a nice thought, but just plain impractical if I wanted to do any kind of nice effects on it, such as the alpha-blending needed for patches and (one day) lighting effects. That would end up taking perhaps over a minute to generate! Hoy!
I settled instead for “cheating” a little bit. Not only is it much easier than writing software-rendered equivalents for all of my existing OpenGL-based drawing, but it’s far faster. In fact, there’s no longer any need to save the mini-map data to disk at all anymore — it’s fast enough to be done on-demand upon each map load. All that happens now for the generation is simply rendering the whole map all at once, without any off-screen culling, but at a 1/8th scale. The final image fits within a 512×512 box on-screen, and I directly copy the pixels from the backbuffer into memory, where a texture for the mini-map is then created. After that, it was just a matter of drawing on dynamic objects (crates, players, etc) in real-time over top of the mini-map texture.
(The mini-map in action. Edges will likely be clamped in the future to avoid showing the black ‘void’ beyond the map area)
Webstart Adventures Ahead
Although the editor is complete, I really want to get Skirmish — that implies both editor and game — Webstart-ready. This will make the distribution and setup of the game far easier on players, and it will also automatically check and administer game updates every time it is launched.
I’ve never used this technology before, though, so it will take a little bit of doing before the transition is fully made. Webstart requires all resources (graphics, maps, audio, etc) be packaged inside of JAR files and digitally signed, and imposes a strict means of loading data within the app. What’s more, users need to “accept” my digital signature the first time through in order to allow Skirmish security permissions such as file i/o and network access. A little bit of an annoyance, but in the long run I’m adamant that the gains greatly overshadow the downs. It’s been a great asset for many popular Java games, such as Wurm Online.
In summation: for those of you interested in trying out the alpha version of Battleforge, the Webstart-ready version should be ready to go in the very near future, barring massive Earth-shattering disaster on a cosmic scale. 🙂
With saving and loading completed, Battleforge takes another step towards completion. For the sake of including a screenshot, below is a incredibly simple ‘map’. As a credit to the ease-of-use of the editor, it took a little over a minute to create.
The next item on the list is the generation of mini-maps. I’ve been using it in a very buzzword-like manner, so I shall explain.
The general idea is that in-game there is a box on the HUD in the top right-hand corner of the screen where a miniature version of the map will be displayed, showing players, objects, and the surrounding area. The mini-map itself will just be a large static image that will have a rectangular region ‘cut out’ and placed in the HUD box, with players and other dynamic (read: movable) objects being drawn over top of it on-the-fly.
Mini-maps will be generated every time the user saves a map in Battleforge. Eventually I want a single file to contain both map data and the mini-map image, but for now it will be saved as two separate files: a BFM (BattleForge Map) and a PNG containing the actual mini-map image. Since the generator will be shared code, the game will be able to generate the mini-map if it’s not present. The only reason for having it in the editor is because larger maps could take several seconds to generate, depending on the system. It does allow map sharing to be a lot easier, since only the raw map data needs to be sent to players if the host has a map s/he does not, and the mini-map can be created on-demand.
This is the initial plan, so it’s wide open to suggestions, comments, or questions.
Until next time!
More progress on Battleforge, which is getting nearer and nearer to completion.
The “Map Properties” dialog is now completed, which allows you edit several trivial (at the moment) fields, and two important ones (width and height). As you can see in the screenshot below, this involved the implementation of the ValueSpinner component, which will hopefully be the last one I need to write for a while. 🙂
I’ve also had to implement a handfull of helper functions for the UI work, such as centreXComponents(), which accepts a variable number of Component objects and a pixel value for padding, which it arranges them with aforementioned padding in order, centred. Not particularly hard work, but it’s the small things that add up at the end of the day.
Also out of the way is the generic “YesNoDialog”, which is a simple dialog window that presents the user with somesort of question that can be answered ‘yes’ or ‘no’ to, and uses Java’s [weird] anonymous classes to embed the functionality right into the code. These are hugely useful for confirmation when map data is at risk, such as when clearing the map, closing the editor, or loading in a new map. It’ll be a huge boon for in-game menus that oftentimes require confirmation, as well.
Only file I/O work remains, which entails: saving, loading, and the generation of the mini-map for the game to use. The map format for the Alpha version will probably be a simple binary format, although I intend on looking to some compression and/or encryption libraries in the future. Barring any spontaneous motivation drops, the editor should be ready to go in another week, at the most. 🙂
It’s been a good long while since my last entry regarding Project Skirmish, but lately I’ve been getting some solid motivation, which I haven’t been letting go to waste.
More specifically, it’s about continuing to push the map editor, Battleforge, forward. Writing map editors is a labourous task — at least for me — so I try and convince myself that it’s sluggish speed of development is understandable. Hopefully that is the case, and productivity leaps into full swing once it’s completed. More than likely, though, it’s just working full-time writing code at Sony that’s draining the heck out of me. Still, I plan on pushing forward Skirmish’s development.
More GUI Fun
In particular, dialogs and edit-boxes. With all four of the editting modes finally implemented (tiles, props, decals, and patches) it’s just a matter of creating a map-settings dialog and then adding saving/loading before calling it a finished Alpha version. The idea behind a Dialog is that it blocks out input from the underlying level (ie. the map editor’s interface), unlike the sidebar and bottombar Windows, which work alongside the regular input for the editor.
I won’t drone on about the various GUI components, rather I’ll leave that to someone more qualified to do so. I’m really opting (mostly) for a get-the-darned-thing working methodology, but I am paying attention to the design enough to keep me from shooting myself in the foot. And trying to make it look sufficiently pretty. 🙂
The important thing is that the editor is just about fully functional, and I’ll soon be able to start on the beef and potatoes of the whole project: the networking engine. I’ve had a ton of interesting ideas swirling around lately about the very topic, so it will be exciting to finally tackle it in the (hopefully) near future. Naturally, having networking necesitates having testers to insure that the darned thing works. I don’t see much of my original testing crew online any more, so this may prove to be a challenging process. Stay tuned!
For a good long time the daunting task of learning how to model in 3D has been on my to-do list. I’m certainly a great distance from claiming proficiency in the subject, but I’m glad to say that I’ve finally started on the dusty path towards such a goal.
Dean has been working very hard on more sprites/actors for Cyberspawn, and I figured I would take the opportunity to try and model some simple props and weapons for the game as well. Not to mention the refreshing break of just taking some time off of programming to pursue something a little more artistic. Coding all day at work and then coding all evening tends to suck a bit of the creative juices out of you. 😉
In terms of weapon-of-choice, I opted for Blender, the juggernaut of free modeling software. Blender has a bit of a reputation for having an unwieldy interface — which I think I can somewhat attest to — but overall it’s been quite a learning experience. And surprisingly, fun. I could see myself doing this even just as a hobby.
With a sizable helping of dedication and motivation in-hand, I set forth to attempt to create a simple handgun for Cyberspawn. Just some little pea-shooter for gunning some baddies down with.
It ended up looking and feeling heavier than a pea-shooter, so this model might end up being the infamous “Hardpistol”, a nonsensical term for a heavy handgun that I coined in Skirmish Online.
The modeling wasn’t particularly hard, but then again, it’s not a very complicated model. I plan on tackling texturing (UV unwrapping?) soon, which I’ve heard mostly horror stories about. Should be interesting. 😉
All in all, the model looks ‘alright’ in-game. It took a bit of trial and error to get the perspective/angle correct with the camera such that the gun appears properly on-screen, and my only real regret is that the weapon looks a little too thick and short in the particular render that I took.
The advent of weapons means several subsystems must come in the near future: particles, weapon animations (groan!), decals (for bullet holes), and some sort of inventory system. Hoy!
I’ve found a decent balance between development and work, and it seems to be working out pretty well for me. The game is moving along very smoothly.
Among the newly implemented additions is a global listing of Actors, which now also follow the same game physics as the player. This will essentially allow other characters to bounce around and jump about just like the player. Actor-to-actor collisions are also in, using simple bounding boxes. If you noticed the player’s inability to walk over small steps in the demo, this has also been fixed with a smooth upwards transition.
I modified the demo level a little — still entirely procedural; no map editor yet — so the second room is a large stairway with another stairway in the middle, and filled it with actors that walk around and bounce off walls and eachother. A little more interesting, and the other actors have no problem walking up and down the stairs. Dean has been working on hard on art — you’ll notice some new characters present:
Either weapons or decals will come next. I’m not entirely decided how decals will work, but I see two viable options:
- Each decal is an object that is drawn with perspective correction on top of walls or floor surfaces. This is the standard approach in most 3D games. This could be a performance issue, depending on how many decals are visible at once.
- Decals are graphics drawn directly onto the wall/floor textures, made as a unique copy of the texture for that surface. This somewhat means unlimited decals, at the cost of extra memory to store all of the unique textures. This would allow for a lot of neat effects though, like heaps of surface-covered gore, non-tiled smooth carpet or grass burns, and generally really battered-looking areas that have seen a lot of combat. In essence, it’s really a lot like destructible terrain in a 2D game, but on a texture level in a 3D game.
More on this as it develops.
Hoy, it’s certainly been a while since my last update. There’s plenty to talk about, although it’s in a little bit of a different direction than usual.
I have a keen interest in software rendering, as several of my side projects have hopefully shown. A few weeks ago I was toying around with a particular algorithm for raycasting, sheerly for the spontaneous fun of it. Weeks passed by, and I found myself still steadily working on it, rather than Skirmish.
(The first phase of the renderer — no bells or whistles.)
The first step was to get the thing actually drawing. The idea was to adopt a Wolfenstein 3D sort of map format — insofar that it is tile-based — but allow for variable-height floors and ceilings, in addition to everything being textured. Getting this rendering fast has been a really interesting challenge.
Next up was getting in some better textures. I opted for the set that Dean drew from a project a few years back, which fit the theme I was going for perfectly.
The world was looking overly too bright and bare, so fog and sprites came next. The fog can be set to any colour, or fade distance, and the sprites can be scaled to any size and support animations.
don’t won’t want to mess with the Cyberpolice.)
Dean was nice enough to draw two neat characters for me (one human and one bot), and is slowly pushing towards getting one of them fully animated.
Next came the implementation of what I’m currently calling “mask walls”, which are essentially optional wall textures that can be on any of the 4 sides of any tiles that fit between the floor and ceiling of that tile. They support z-buffering and colour masking, so their purpose is to act as things like doors, steel bars, grating, or other semi-see-through-able walls. Door logic isn’t implemented yet, so the above is really just a hard-coded mock-up item. 🙂
The last graphical addition was a simple form of lighting, whereas each tile can be given a colour to modulate its textures by. Most lighting will likely be static, but I couldn’t resist adding this because of the neat benefits such as having energy-based projectiles or explosions that light up the surrounding area.
Cyberspawn, as the name may hint at, is to be a cyberpunk themed game. If you read over my entry a while back about my once-project Gloom, virtually everything from that applies to this project. The idea is a first-person game that explores an interesting cyberpunk world, and gives the player plenty of ways to approach the way the game is to be played.
Cyberspawn is, for the time being, taking the place of Skirmish as my primary project. I’ve felt more than a little burned out on the overhead shooter genre, which I think is understandable given my history of developed games. I’m jumping at this chance because it gives me a chance to do more work in software rendering, and finally an opportunity to work on components of game development my other games are rather devoid of, such as storyline and deeper gameplay. I think it will be a very interesting game to work on.
I packaged a small ‘demo’ of what I have so far, which isn’t too much by some standards, but certainly a solid start. Most of the player physics are implemented, allowing for running, jumping, and full collisions with the map.
Optimization is still a work-in-progress, so don’t be surprised if you get a less-than-splendid framerate. I manage a mere 60 on my 3.0ghz machine, but your mileage may vary. Framerate independent timing has been implemented, so it shouldn’t feel too sluggish for anyone. Controls might feel a little awkward though, since I have odd tastes in that realm. 🙂
- Arrow keys: Move forward/backward, and rotate
- W and E: Strafe left and right
- A: Jump
Fingers crossed that I haven’t forgotten any critical DLLs. 🙂
EDIT: Looks like I did. Install the Visual C++ runtime DLLs if it gives you a hard time.