At any rate: after about 7 weeks of absurdly intensive work, we have turned that clumsy demo from the Global Game Jam into this:
For anyone who missed the last post, Life Goes On is a puzzle game where you sacrifice an endless stream of knights one by one to bypass a trap filled gauntlet. Where in most games death is a sign of failure, in ours it’s the basic unit of progress. It’s a combination of devious puzzles and black humour where you have to think about how best to fail in order to succeed.
We’re really happy with the result. Give the demo a spin, and let us know what you think! You can email us at LifeGoesOnGame@gmail.com, follow us on Twitter at @lgogame.
We are, of course, not done with this. We’re going to expand that 7 level demo into a full game (current target is around 50 levels), and we’ll release it on multiple platforms. I’ll hopefully make more blog posts about the project to document our progress (though if you put any stock in that intention at this point I’ve got a bridge to sell you), but the best place to keep track of what we’re up to at the moment is to follow us on Twitter.]]>
You might recognize this symbol as the Ouroboros, an ancient symbol with a great deal of meaning to a great many different cultures. Very, very fertile ground for a game concept to be formed from.
Aside from knowing that we wanted to do the game jam, though, we weren’t sure exactly what sort of game we wanted to create. The initial brainstorming session on friday night was a LOT of fun. In many cultures the Ouroboros represents life, death, and rebirth, and so we used that as our starting point. One of the initial concepts was that of a recurring cataclysm, that would revert to its start state once concluded and the player would have another go and try to change things. Another concept was playing through the same timeline multiple times, with each timeline’s actions added to the next, so that by the end you’d be interacting with multiple copies of yourself. We also brainstormed ideas like dying in certain ways allow you to respawn with a new power (jumping off a cliff might let you jump higher, for instance) or even just respawning each time as a different character/animal with a different moveset.
Eventually, though, we came to a concept that immediately felt like a winner: a puzzle game/platformer set in a gauntlet filled with murderous traps, through which the player must navigate. The body of your character would stay there when you died, and could be used as a tool for your next run through the gauntlet. Can’t quite jump far enough across a spike trap? That’s okay, jump into the middle of the pit and then next time you can use your corpse as a platform to jump the rest of the way. Need to hold down a button that opens a distant door? Get hit by an arrow trap and then drag your body onto the switch!
Not only was there a lot of room for interesting and novel mechanics, but there was the potential for just the right shade of over-the-top black humour. We all couldn’t wait to get started.
For our tech needs, we chose Unity3D. It was cross-platform (two of our team members used Macs) and it gave us a big leg up in terms of tech. However, we’d have to invest some time in learning the engine, as nobody other than me had used Unity before, and I wasn’t even going to be doing any programming! As the only person there who could do art, I was going to be plugging away in an educational version of 3DS MAX and my copy of Photoshop to build and texture our 3D assets.
I’ve never done extensive 3D work for games before (I do most of my game art in 2D) and I wasn’t familiar with Unity’s pipeline, so there was a lot of trial and error. Just getting my first model in-game was an adventure. Models would come out too large, or too small, and all sorts of silliness occurred getting animations working, textures applied, and everything else needed to get the game looking good. It was a great learning experience. My normal reason to work in 2D is that I’m a much more competent 2 dimensional artist than I am in 3D, so I would be able to confidently create my own assets for my games without needing to enlist another artist. However, after two straight days of trial by fire in 3D game asset creation, I now feel comfortable enough working with those sorts of assets that I wouldn’t rule out doing 3D projects in the future. I still produce much better results with Photoshop than with 3DS MAX, but I have a solid basis now from which I could learn the trade.
Anyhow, after the first day of work, we were still struggling to get anything working. Unity is a powerful engine and there are a lot of reasons to sing its praises, but it’s also absolutely HUGE. It tries to cover everything that a game developer might want to do with their game, and as a result has a huge learning curve. Physics, in particular, was finicky, and gave us trouble for the entire weekend. Unity has a reputation as a great tool for quickly putting together a game prototype, and I can totally see how it would work for that, but the caveat there is that you need to know your way around Unity first… what tool works best for which task, what script functions to call, the limitations of individual components, etc. Trying to build a game prototype while simultaneously learning how to use Unity was painful, and it emphasized to me the lesson I learned from my Ludum Dare entry a while back: when doing rapid development, “know thy tools” is the first commandment.
However, by the second day, everything started coming together. I finished up making 3D assets for the world, and the gameplay mechanics started coming together. I can still recall the moment where someone put all of it together: “Hey, guys, we have a game!” By the end of the day, we had several levels put together, with spikes, spinning blades, and flamethrowers. You could use bodies on the spikes to jump the pits, and flamethrowers would destroy bodies, creating a new sort of obstacle that would need to be worked around. Our sound designer put together a set of hilarious, randomized sounds for player death that still get a grin out of me. It wasn’t perfect—physics issues still were cropping up, and we hadn’t had time to get anything but the most basic mechanics into the game—but you could play several levels start to finish. It was rough and unpolished, but it was starting to feel like a real game!
We tossed a few titles around, but settled on “Life Goes On”, which was a great fit with the lighthearted tone of our game, and focused on putting together a bunch of levels for our presentation at the end of the day.
It was time to demo it in front of the rest of the 94 attendees (gulp!) Fortunately, it went really well. We were the second last presentation in a night that saw 18, but we still got a really enthusiastic response! The demo was a hit with the audience, and when it was over it seemed like the entire room had their hands up to ask questions. The first question was “where can I play this”, which was really, really gratifying.
In no small part due to the enthusiastic response we got, we’ve decided to keep going with this project. We’re not quite sure how far we’ll take it (heaven knows we’ve got a ton of ideas), but we do know that we want to have something complete and polished enough that we can show to the world. Now that I’m getting this blog going again, I’ll try to remember to post updates.]]>
I’m still working on the “Towers” project I mentioned in my last post, but I’m rewriting it from the ground up. The prototypes I built before were promising, but I was starting to hate a lot of the underlying architectural and design decisions. While this does mean that I’m throwing out a lot of work, the lessons the prototypes taught me (both in terms of programming and game design) are valuable in and of themselves. In this post, I’d like to go over some of those lessons, as well as why I felt I needed to discard a lot of the preceding work.
To recap the high concept, the Towers project is centered around the idea of competitive tower construction, with players having to balance building towards a goal with sabotaging their competition. The intended experience is a frantic, strategic game in which players are struggling to keep their unstable towers upright.
This is a pretty vague concept, admittedly. This is why I’ve already gone through a couple prototypes, and intend to go through more to nail down how the game should look, play, and feel.
The first prototype approached this concept pretty literally. Each player had a junkyard from which they could grab building blocks, and then they would arrange and weld them together to climb higher than their opponent. Some of these blocks were structural, while others were weapons that could be fired periodically at the enemy to deal damage to their tower. As these towers got higher and higher, they would wobble back and forth, and the loss of a structural support (or even a heavy impact on the tower to knock it over) became a more pressing concern.
There was a lot of stuff going for it. Playing with the physics to build a tower is satisfying, and it’s even more fun to knock them down and blast big holes in the sides. However, there were some big problems. The building method was awkward and unwieldy, not really lending itself to quick placement of blocks. The player had to rotate and place each component manually, overlapping them to weld them. This made actually building the tower a frustrating, unwieldy experience when the tower was taking damage, moving around, etc… and since building towers is a central part of gameplay, this was unacceptable. Another problem was that the weapons needed to be fired manually, and this became a babysitting task that took away from the building process even more.
I made some rather drastic changes to try and address these problems. The original “drag, rotate, and weld” method of building construction was replaced with something more akin to the building method of World of Goo: the player would click near existing parts of his structure, and if there were resources available for building a new “node” was added to the structure and linked with existing nodes. This was a big improvement, because you could rapidly construct and repair your structures even under fire from your opponent, and because the wobbly World of Goo style structures play very nicely with the physics engine and are satisfying to watch.
The weapon systems were also overhauled. Instead of drawing weapons from a resource pool as before, there were “depot” nodes scattered in the environment. Building up to them would allow you to claim them, and once claimed they would generate a powerup on a regular basis. That powerup could be dragged to an existing node to transform it into a weapon. This is great, since it ties building more closely into the combat aspect of the game, and provides a more interesting reason to build upwards. I also removed the manual firing of the previous prototype; weapons would now fire automatically, as they reloaded. The player would only control their orientation, which could be set on the fly. This way, the player could focus more on building and less on babysitting their arsenal.
There were still problems with this design, however. While making the weapons fire on their own helped the babysitting issue, manually orienting the weapons meant that it was still a factor whenever aiming needed to be done… and with both the player and their opponent’s towers swaying around, breaking, and otherwise not staying still, this was distressingly often. The same problem was occuring with the powerup upgrade mechanic, in that players would need to watch the depots and drag the powerups out as soon as they appeared in order to not give up the valuable resources.
My plan to address these issues is to take a page from the tower defense genre. In tower defense games the player will usually have a single pool of resources to draw from which they can use to build or upgrade defensive towers. Similarly, I want the player in my game to have a finite, renewable resource (for brevity’s sake we’ll call it “metal”) which they can use to upgrade nodes in their tower for specialized functions. Further upgrades can be done later on those nodes to transform these specialized nodes into even better versions of themselves, for a price.
This is a better mechanic for upgrades, I feel. The resource it relies upon has no cost for not being immediately exploited, as metal can accumulate in a way that the powerups could not, and the interface is cleaner, with the user only needing to interact with the node in question and not some potentially distant depot. It also makes it much, much easier to add variety into the arsenal, and I have a whole array of potentially crazy ideas on how to take advantage of that flexibility.
I also plan to take another cue from the tower defense games in that the player will have no interactions with the weapons once they’re deployed, as they aim and fire automatically. If the previous prototypes have shown anything, it’s that babysitting an ever-growing arsenal is a lot less fun than building and repairing a teetering tower.
The depot mechanic of the previous prototype is not something that I want to lose in this transition, since it ties the combat and building components of the game together so elegantly. The depots, then, should be changed so that they now increase the regeneration rate of a player’s metal supply. Once can also thing of multiple kinds of depots… maybe they provide different resource types that allow for specialty upgrades, or provide “victory points” that decide the outcome of a match. This is something I’ll be experimenting with.
I won’t spend a whole lot of time on this, but as I mentioned earlier architectural decisions in the game engine were a significant factor in me doing a rewrite. The biggest change was moving from a traditional hierarchy of game objects to a component based model. Basically, instead of using inheritance to share functionality between game objects (e.g. a TowerNode object is a type of PhysicalObject is a type of GameObject) I use composition (a game object is just a collection of different components, which together define the behaviour).
I’ve found that this is much better for prototyping, and saves a whole lot of code duplication. I can create a new object by pulling together a whole bunch of existing components. For instance, a tower node might have components for a sprite, physical simulation, object ownership by players, and HP. A new “money generator” node could be just as easily created by adding a “give the owner money every second” script to that same collection of components.
The downside is that collaboration between components is not as straightforward as it would be in a more monolithic class. It requires some extra thought as to how game logic should be implemented. Preferably, one wouldn’t create a new component for every object type, since that defeats the purpose… the challenge is to find a way to combine existing, generalized components to get the desired game logic, or, if that is insufficient, then at least to make the new components required general enough to be reusable.
The whole thing has been a hell of a learning experience, and I hope to be able to post more about it soon!]]>
I’m currently in the prototyping stage, and trying to figure out what the details of the design should be. There have been a few thorny technical challenges (not the least of which was figuring out why the multiplayer wasn’t working) but the biggest outstanding issues are design ones. While the concept has a lot of promise, it’s been difficult to nail down exactly where the fun is. My first attempt has been lacking in that regard. That’s not a bad thing—this is why we build prototypes!—but it does mean I’ve got a lot of work ahead of me.
Here’s what my first attempt has looked like:
Players have individual “junkyards” from which they can draw new components to place on the field (at this point consisting of blocks and rocket launchers), which they can then place by rotating them, overlapping them with terrain or other components. Rockets can be fired by right clicking on them, and they’ll slowly reload.
Now, it’s not a bad start. The building method leads to some interesting structures, and Box2D (the physics library) means that when I knock towers down it’s entertaining… just like it was when you knocked down block forts when you were three! So, there’s some promise here.
It’s anything but perfect, though. In fact, I’m not sure it’s viable as a gameplay model yet! In no particular order:
Obviously, I’ll need to seriously rethink my design.
I’ve started by looking at the competition. At first glance, this is difficult because I haven’t seen anything quite like it. However, two good candidates popped out after a bit of thought: World of Goo and Slam Bolt Scrappers. World of Goo (WoG) is built entirely around the idea of building wobbly, jell-o like towers to solve its puzzles, while Slam Bolt Scrappers (SBS) involves superheros stacking Tetris-style towers full of weaponry which they then blast each other with. My concept ultimately appears to be in the intersection between the two.
Unfortunately, lacking a Playstation I am unable to give SBS a go: I can only rely on previews and media to get a sense of how it’s all put together. World of Goo, however, I immediately bought on Steam and played through, taking notes all the way. I’ll save my thoughts on WoG for another post.
I’m now re-evaluating my design. My first focus is on how to make the tower building fun: it’s absolutely a requirement if this concept is going to have any value at all. I also want to streamline the combat mechanics, and provide clear objectives for the players to overcome.
Here’s where I’m heading at the moment:
Closer to World of Goo now: placing a component near to another is all that’s required to weld them together. It’s a lot more forgiving, and gets rid of the need to rotate objects (mostly) but still isn’t quite where I’d like it. In particular, I’d like to get away from the “pickup, move, drop” flow of building towers. Even using keyboard shortcuts, it’s cumbersome and finicky. I’d like to be able to simplify the building process down to a single click: simply clicking NEAR the tower should be sufficient to place a new piece.
That’s all for the moment!]]>
But, enough! Enough shenanigans! Enough delays! There shall be posts! I actually enjoy writing these articles a fair bit, and on the rare instance that someone actually finds my inane babbling useful it’s incredibly rewarding.
At any rate, I’ve got a couple new projects in the works.
One is a new particle system and editor for HGE, one of my favourite 2D game engines. It’s a great library (free and open-source to boot) that nicely wraps up DirectX in a friendly, intuitive package, and it’s got a lot of nice helper classes. However, I’ve found that the default particle system that ships with it isn’t sufficient for my purposes. It’s fairly restrictive in terms of what you can create with it, and it doesn’t readily support a zooming (or, heaven forbid, rotating) camera. To make things worse, the particle editor that ships with the engine is more of a demo of the GUI classes than it is an actual functional piece of software. I mean, hell, you can’t load or save particle systems, except to overwrite one of the 10 presets, which you must then manually copy, paste, and rename in your game’s files.
So, my (probably insane) plan is to write a more robust particle system. This isn’t too hard in and of itself, but I also want a user-friendly pipeline for particles, which means I need to write an editor. When I wrote my animation system a while back I had to create the tools for it as well, and that was easily the most time consuming part of the whole process… especially because I was insisting on writing it with managed C++ for access to the .NET framework. THAT was a headache.
At any rate, I figured that this would be a perfect excuse to go and learn C#. I’m already familiar with the way the .NET framework works, so I won’t need to spend time beating my head against that. Additionally C# is an easy jump for someone skilled with C++, and downright eerily familiar if you’ve done any Java programming at all. I figure I can pick it up fairly quickly, and thereby expand my skillset, make a wicked editor, and have awesome particle effects. I’ll try to blog my design decisions and progress as I go.
Nothing could possibly go wrong.
The other project I’m working on is a small multiplayer game based around competitive tower building, where two players compete for height while actively sabotaging the other’s efforts. It’s almost at a playable prototype stage, but there are some minor bugs that need to be ironed out before its ready for display. Like, for instance, being able to ACTUALLY CONNECT to another player. You know, minor bugs.
Beyond that, my time is mainly just spent playing games, finishing up my final term of university, and contemplating in abject terror the prospect of life after school, and the attendant concept of “real life”. Such is life!]]>
For those unfamiliar with the game, the setup is very straightforward. You own planets, the size of which determine the number of ships they produce each second. You can’t see the number of ships on an enemy planet, but can usually guess from their production rate and their troop movements. Ships accumulate on planets, and can be sent to other planets. When they reach a friendly planet, they’re added to the local reserves. When they reach an enemy planet, they sacrifice themselves at a 1:1 ratio with enemy ships until there are no more opposing vessels, at which point you own the planet (and its production). Neutral planets spawn at the start of the game with ships on them, but do not produce new ships until a player takes them out. The objective is to be the only person with planets at the end of the game.
Thats it. There’s nothing else, no unit types, planet types, and few subtle nuances. It’s the simplest computer strategy game I’ve ever played. Yet that simplicity can translate into a lot of strategic and tactical depth in a multiplayer game. While a 1vs1 is generally speaking just a contest of math, reflexes, and calculated gambles, Galcon really begins to shine in free for alls with 3 players or more. Mind games, bluffing, backstabbing, and guessing the intentions of other players are the skills brought to the forefront. In other words, it’s a game so simple that the majority of the gameplay can be derived from the human elements instead of the mechanics themselves.
The best gameplay emerges when players have the mindset of rational, self-interested parties who are looking for the big prize: to be the last man standing. While this can often turn to a stalemate situation (being the first one to move in a four way stalemate can result in you being torn apart by the guy opposite from the one you’re attacking) there are a lot of mind games, fake-outs, and alliances of questionable authenticity. When irrational players enter the game, sometimes the results are game-breaking (for instance, out-of-game alliances between friends, or a grudge held between matches that results in another player rushing someone at match start to grief them, sacrificing their own chances to screw that player over). However, in most cases, they just play into the hands of the people who can recognize their irrational behaviour. If someone is holding on to ground that they’d be better off ceding to a bigger power, both them and the person attacking them will suffer losses that you can exploit. Likewise, if they lock themselves into a conflict with the second strongest player the big guy just sits back and waits for them both to exhaust themselves. An irrational player can taken advantage of by taking advantage of what is usually a fairly predictable mindset.
Yet there’s an interesting interplay, in which an otherwise rational player might engage in seemingly irrational behaviour by design. A common survival technique when you’re the small player in the scene (and therefore, anyone with half a mind could take you out wholesale) is to bunker down and make yourself too costly to take by massing up troops and ensuring not to waste them on attacks that won’t pay themselves back. The intent, ostensibly, is to defend their small territory to the death. Yet, if an attack comes, defending that ground to the last man will result in your force obliterated as well as losing your planets, ending the game. You would expect that a rational player, therefore, would be bluffing in this instance, and if a sufficiently large attack comes, they’ll simply give up their planets and run away to preserve their fleets. Their posturing is a non-credible threat. Indeed, this is often the case, and players faced with overwhelming force or an alliance of enemies will often retreat.
Yet you’ll also find experienced players digging in, meeting every attack, and ceding no ground… even going on the offensive against a superior foe once attacked! New players often do this simply out of stubbornness and loss aversion, but experienced players are instead employing suicidal behaviour intentionally. Why in the world would a rational player employ behaviour that will likely cost them the game?
Well, it’s not so insane as it first appears. If a player digs in under a sustained attack, other parties will be watching and waiting on the wings. They know that taking your worlds will weaken the aggressor, and will be eager to capitalize on it. This is even more true if the defender takes the fight to the enemy and starts cutting into their least defended planets, forcing the aggressor to fight fires when his forces are out of position, usually resulting in a massive over-correction. It’s a calculated gamble… will the other players intervene soon enough that I can come out ahead, or will I have taken too much damage (or even been destroyed) by the time they sense the opportunity? There is a small, albiet significant chance that an aggressive defensive posture can pay off.
Sometimes it works, and you can end up with a large production base and still have most of your army. Sometimes it doesn’t. Like I said, it’s a gamble.
Yet, another part of this is the metagame. Galcon matches are rarely played in isolation… instead, they’re often played in sequence against the same players, due to the length of a typical match. Making a suicidal play might cost you this game, but in future games your opponents will be more wary about attempting to take your worlds, fearing that the losses incurred gaining your worlds will make them vulnerable. It sends a message to your opponents: you might be able to overwhelm me, but I’ll be sure to take you with me if I can. Likewise, fleeing at the first sign of overwhelming force might be a good move this game, but your opponents will take note of that behaviour and play more aggressively to take advantage of it.
This is why I love Galcon. It’s a game that is not about its mechanics, but about its players.]]>
I’m finding that putting development off until late at night is a terrible, terrible idea. By then I’m often tired, distracted, or otherwise preoccupied, and the work simply does not get done. The main reason I’ve been putting it off that long is because I try to work “normal” hours at my day job. However, since I work from home and control my schedule, I think I’m going to search for a time slot that works better, earlier in the day. Given that my job is ending soon and school starting, a time block that fits with my class work is best. With luck, it’ll be easier to motivate myself to work when I’m lucid enough that I’m not ready to collapse!]]>
First time this week I’ve had a chance to work on SPX, but I FINALLY fixed my issue… turns out that I was creating my ogre window and updating it in different threads, which screws things up. I also got my precompiled headers set up, DRASTICALLY shortening compile times. I am a happy man.
Didn’t get into any code today, but I am working on a detailed development plan that I can follow for the next week or so. I’ve been thrown off track by work commitments and that godawful bug I was struggling with, but now it’s time to get moving again. My main priorities, going forward, will be to rewrite the rendering, input, and camera systems, in that order, to achieve feature parity with what I had before the engine port. Afterwards, I’ll begin focusing on making a game prototype.
Started trying to implement graphics. Most of my time was spent on the architecture for managing graphics assets. Nothing to show… yet.
Eureka! Finally have something to show! Temporary ship graphics, and everything is working again!
Okay, so apparently I’m an idiot.
In the process of switching to Ogre, I made a few game architecture changes without testing them in order to adapt to Ogre’s way of doing things. All this time, I was assuming that the actual game was still intact under everything, but between getting the client and server threaded and altering how the frame-to-frame updates were being done, I cocked everything up. The server was quitting because the client thread hadn’t had time to start running yet, and none of the game objects were updating because the change to the updating cycle meant that the "currentFrameTime" wasn’t being calculated anymore. Both of these were one-line fixes, but I spent a huge amount of time trying to figure out if I screwed up the game OR screw up on the Ogre port, when I could have focused on tracking these bugs down.
Lesson learned: in any large overhaul, do whatever changes you can without breaking the system FIRST so that they can be tested, THEN start breaking things.
At any rate, I can start moving on to other aspects of the port. Once input and camera control are back in, it’s over and done with, and I’ll be able to start working on turning it into an actual game!]]>
I’m going a little bonkers, but them’s the risks when you start programmin’.]]>
I was much better about keeping logs this week. Starting to get into the daily development habit, and about damned time.
Started delving into Ogre tutorials. At least on a basic level, the library appears very straightforward. It’ll be interesting to see how complex it is to work with in the end.
I think I’ve got enough of a handle on Ogre to really begin porting SPX over in earnest. I’ll start by splitting off a branch in the repository, as a precaution.
The major sticking points in the port are going to be changing the game to wait for frame and input callbacks, switching from SFML’s Vector2f to Ogre3D’s Vector2 (which, hopefully, will just be a rename + removing the helper functions I needed to write to make SFML’s Vector2f class usable), rewriting the camera system, and rewriting the graphics code. It’s fortunate that none of these tasks seem too herculean on their own, but it’s going to be a while before the game is back in fighting form, as it were.
There’s also the issue of the file structure of the project, which the necessary Ogre files will need to fit into. I’m only including DLLs, libraries, and includes, so that’s fairly straightforward, but I suspect I’ll need to juggle it a bit until it’s something I’m happy with. It’s a good opportunity to rethink the file structure, though, so I’ll make the most of it.
While it was inevitable that a port of several thousand lines of code to a new graphics engine would cause snags (the act of ripping out SFML and replacing with Ogre has left me with 164 errors and no functioning program) I’m finding more issues than I anticipated (which–in a line of reasoning doomed to go in circles like a merry-go-round—is exactly what I anticipated).
For starters, Ogre3D redefines all the STL containers into the Ogre namespace as structures with the original STL templates as members, which is something that I find utterly mystifying, since it isn’t even retaining their interface. The lines "using namespace Ogre" and "using namespace std" results in a lot of ambiguous symbols that the compiler feels obliged to choke and die on. I can’t think of any reason why this would be done, save driving me nutty, so if anyone can enlighten me that would be appreciated!
At any rate, it’s high time I got rid of the using namespace calls anyways, they’re bad form, and there’s only a few places where the extra characters are more painful than the potential errors… those can be dealt with using typedefs to get rid of the namespace.
By the end of the day I’ve gotten to the point where there are no compiler errors. I had to gut all the graphics code, and there isn’t a WORKING piece of software, but it’s a good position to begin Ogre implementation.
Unexpectedly, the switch to Ogre has necessitated a change in the main() function. I previously ran two separate GameManager classes on the same machine in a serial fashion, but the way Ogre handles frames (hit go, wait until it returns instead of hit go, then run an update loop) means that I needed to put each of those classes in their own thread. This was the eventual plan anyhow, so it’s hardly wasted effort, but it did require me to do some research. I had to learn the boost::thread library, but it’s a fairly straightforward piece of software and I’d been meaning to learn it anyways. Hopefully the process of threading won’t bite me in the ass.
Finished off the Ogre initialization code… kinda. Crashes when OIS (Ogre’s Input System) loads, need to find the source of THAT error. Haven’t been able to figure out if the threading works as designed yet.
I’ve got a window rendering, and the threads all seem to be cooperating. It’s now a matter of getting basic functionality back into the game so that I can move forward from there. However, the program currently crashes with OpenGL, so that’s a point of concern. However, since I can run with DirectX, it’ll do for now.
Basic input functionality is in. Mouse moves around, application quits when you hit escape. Not perfectly happy with the mouse behaviour… it’s locked to the window, so you can’t click anything outside it, so that will need fixing. I’m also running into strange issues where it won’t receive mouse inputs if I run it without the debugger active, but it WILL if I do, so I’m going to need to dig into Visual Studio and figure out exactly what changes when debug mode is on… the configuration hasn’t changed, so it’s executing the same code.
I did, however, spend much of the day struggling with an error caused by erroneously linking to the debug dlls in the release build. Talk about a dumb mistake… lesson learned: doublecheck that release AND debug builds are both properly set up!
That’s it for this week. If anyone is actually reading these, it’d be great to know if the format and content of these logs are at all interesting. Let me know in the comments!]]>