Our artist is hard at work making new assets again, which means we have pictures!
This is still work in progress… This is the zombie enemy, which comes in a variety of flavors, from the one that explodes to the one that’s only a torso!
Most of this work was done on a modeling tool, and then exported to a sculpting tool to add the detail… Some detail is still missing, but first a layer of color texture must be added to see where the detail is mostly missing…
One of the big differences between indie development and AAA is that (contrary to what would be expected), indies must be doing the math the whole time: will adding more detail to this or that feature give me one more sale? When you’re not worried about blowing people away with screenshots and snazzy press-releases, you should be continuously looking for ways to shave off work and get more “bang-for-the-buck”… That’s hard to do because most of us are perfectionists and will obsess about small details…
Anyway, here’s the obligatory comparison between concept and final:
A lot of difference… Our artist uses the concepts mostly to “feel” the character, not as much as a plan…
Catch you on a future update!
Well, it’s been almost one month without updates… Reason for that is simply we didn’t have time for any real development on Grey… All of us have full-time jobs, and all of us had a really heavy month, work-wise…
Work has not stopped completely on the game, we simply don’t have anything interesting to say on the subject…
Rincewind finished the new model for “Grey”, but we can’t show it in the game yet because while updating the resource library of the SurgePlayer I found a bug that I want to address before moving onwards… I could do a manual replacement, but that defeats the idea of spending on having a full, complete editor… specially if I have it my way and we end up releasing it in the future; I don’t want to release something that has bugs…
Anyway, I found that the way the bone/skeleton system works in my engine is terrible for resource updates.
Currently, there’s no “strong” relation between the skeleton, the poses and the mesh itself… This means that theoretically, you could use use any pose on any skeleton, and on any mesh… I say theoretically, because if you use a skeleton that wasn’t intended for a specific mesh, it will just break down all the transforms (you can do it, but you need something called a retargeting, which in fact actually builds a new skeleton/poses). There’s all sorts of dependencies between these elements (mesh/skeleton/pose), but the engine didn’t acknowledged them in practice, which meant that when you update one, you expose yourself to a whole world of problems if you don’t update the others properly… And that was what was happening…
Old Grey model had 49 bones, the new one has 47… and just this small difference would cause the whole system to crash…
I tried building some workarounds, notifying the pose that the skeleton has changed, but that just caused a huge cascade of events (another inefficiency: all poses/keyframes store a pointer to the parent skeleton… and I have thousands of frames per skeleton!), and it really was just a patch…
So I decided to bite the bullet and rebuild the whole bone system from scratch, making the ties between the elements stronger and less error prone (and I’m taking the opportunity to make them faster to load and more memory efficient)…
This means that I currently have a full offline engine (can’t even compile for now), will have to do a tremendous amount of work to support the old resource loaders Reality 2.0 and upgrade Reality 3.0 to 3.1 (besides keeping the compatibility with the old assets: doing an automatic conversion tool would just be sloppy and probably harder than just fix the issue)…
So, I don’t expect I’ll be able to get this up and running in the next couple of weeks… work is kind of insane at the moment, finishing a lot of projects and revving up to start new ones, besides an impending move to a new office… But we’ll all do our best… except for the bugs (this one was kind of unexpected, but most bugs are) and the UI system (which I had some great ideas for, due to the current project I’m working on for DayJob), most technology should be ready to go and I’ll be ready to work on game logic…
Yeah, yeah, famous last words… 
Last weekend I took part on Ludum Dare’s 26th competition, that was themed “Minimalism”.
Although building a minimalist game is kind of against everything I stand for (and that’s why maybe I don’t finish that many games), this one turned out pretty good, at least judging by the comments so far…
You can download the game here, and the source from here…
If you want to check out the development process, you can hop into my blog here!
I’m going to see if I do a better version of this one in the near future, since I won’t require that many hours to do add the stuff I left out of the competition…
You can check out a video of the game in motion below:
Work has come to almost a complete standstill, due to work and business travels…
We’re still plodding away, but our time has been extremely limited, so it has been mostly small scale stuff in the internals and props for the game, specially considering the next “big” task I have ahead of me is fixing a bug in the resource system which is preventing me from adding the new model for the main character…
Unfortunately, these lulls in development give me more time to think about games (because I’m not actually making them), and I start having a lot of new ideas, which isn’t good for the productivity and the future of Grey.
On the brighter side, we’re saving up to buy a markerless motion capture system to use for the cutscenes and game animations, looking into iPi Soft’s system, which seems to be fairly good and inexpensive.
Next weekend I’ll probably be competing in the Ludum Dare’s 48-hour competition, see if I can excise some game ideas that have been floating around my brain… Usually, when I participate in these I come back fully replenished (motivation is the key driver for hobbyist projects like Grey), so I hope this time isn’t going to be any different!
Work has been progressing well, although most of what was done from a technical perspective was mostly related to the internals of the Player, so no new screenshots to post.
But, I’m glad to say that most of the core stuff necessary to be able to actually build the game seem to be done (except for cosmetic things, like decals and special effects).
Now I’m working on making the UI work properly… Pedro has finished the base of the UI, and I’m making the code to make it all work properly, and it is going very well, considering I hate UI coding! 
I also coded in a new “remote console” system, which enables me to inspect all objects remotely and control the game from a command prompt. I run it from my laptop, so that I have full screen-space for the game… it’s really a joy to use for a geek like me!
Rincewind’s been busy with the new model for Grey, although it has been a headache to animate… Some care has to be taken to avoid the errors of the first Grey model, specially considering that Grey will spend most of the time taking center stage in the game, and as such needs to be as good as we can make it…
Hopefully, in the next couple of weeks we’ll be able to show more “game oriented” stuff, like the UI working properly, creature summoning, fighting between creatures, etc.
All in all, I wish I had more time to spend on Grey, since my brain has been hurting with ideas for side-quests and parallel storylines!
Work is carrying on a good pace… I’ve been focusing on technology, getting everything ready so that when I start working on the game code for real I can dedicate all my energy to it…
As I see it, only the UI specific functionality is missing from the technology side, besides a good, healthy dose of stuff to make the game look better, but that will come at the end of development, so we have enough time to fine tune the game itself.
Anyway, lately I’ve been working on game persistence, which is the fancy name for saving and loading the game state…
Since the game runs on top of the “Surge Player”, it means that any load/save system must be done in a general way… I’ve done the groundwork when making “Purgatory”, but Grey has much more (and more complex) data, so some issues with the system arose… Glad to say all is past now, and the game can now fully save and load it’s state, including dynamic things like the combat text scrolling up, etc…
The above screenshot was a load of a savegame I did after Grey got killed by the wandering skeletons… that will show him…
Next steps include work on the UI from a coding point of view (lots of work there… a good UI is extremely important for a tactical-based game!) and the summoning system for the creatures (so I can get some revenge on the evil skeletons!)…
Rincewind is also finishing the new “Grey” character, which is looking great already… Hopefully the next update will see some of that!
Although there hasn’t been much updates in the blog, work has been very productive lately…
First of all, Rincewind has started modeling the new “Grey” character, based on this concept
I may have posted this before, but there you go… He has a more “wildman” streak to it, which is a bit more different than the usual “mage in flowing robes”… Grey isn’t a normal mage anyway!
Second, we’ve enlisted the help of a friend of mine, Pedro Daniel from Phobos Anomaly Design to help us build the UI for the game. Rincewind doesn’t like to do that kind of stuff, and Pedro is an incredibly talented graphical artist, which is a match made in heaven… Although we’re still in the mockup phase, here’s a sneak peak:
You can check out more stuff from Daniel on his personal website: http://pedrodanieldesign.com/ , or the Phobos Anomaly Design facebook page. Be sure to check his awesome band Before The Rain as well!
Next week we’ll probably close the details on the UI so he can make the final assets for it. He’s already done an amazing wallpaper for the game, but I’ll save that for another occasion! 
On another topic, Rincewind has been complaining about the terrain being too flat and square, and being a nice guy that I am, I created a “terrain shader”, which takes some masks, some tileable textures, and the normal of the terrain and builds a very cool looking terrain from any mesh:
Changing the mesh topology (and nothing else):
Finally, I spent some time in the last couple of weeks sorting out small bugs in the editor and doing a big revamp on the 3d Package DCC plugins… Now I can configure every parameter of the shaders directly from the DCC tool, change geometry, see the effect, etc… It’s very cool! Also fixed issues with the shadows (so they work properly in the tool), and Rincewind can now see the animations with interpolation (instead of just keyframes) so he can fine tune them when he’s making them… A lot of stuff indeed:
The fiery blob looks very neat in motion… The two “grass blocks” are the tinting system in action (another shader).
All in all, these last weeks were very productive… I managed to eliminate all known bugs on the tools, so I can get back to making Grey itself… We’ve shelved Purgatory for now, since it reached the point in which it’s basically a scripting effort (and as such, it doesn’t benefit Grey directly) to dedicate ourselves more to the “important” game…
I wish to have at least some gameplay ready in the next couple of weeks, with Grey life-shaping and attacking enemies, and vice-versa… Hopefully that will allow us to make a “video-blog” thing…
There’s still one million things to be done, but it’s starting to come together!
Catch you on another blog update!
Yep, it has… Between Christmas and work overload afterwards, we haven’t exactly worked a lot on “Grey”…
We haven’t stopped, it’s just that the output rate wasn’t that big, and even when it was, it wasn’t “show-worthy”… Anyway, we’re back to blogging!
We came into the new year with extra motivation to finish a game (something we’ve been lacking the last few years at Spellcaster Studios)… We had some discussions about the possibility of dropping “Grey” temporarily and focus on an easier game to build (with less content, simpler game systems), but decided against it… seemed like some sort of defeat, and on the other hand, “Grey” is a good solid idea that needs a ton of work to get up and running, but I’m sure it’s going to be worth it!
Continue reading →
After almost 34 hours of actual work, we’re throwing the towel…
Loads of small problems kept us from creating this game… our megalomania, the tools weren’t as mature as I’d hoped for this kind of thing (and because it’s part of a big framework, it’s a bit unwieldy)…
The art was well on its way (would probably be done in time), but we wouldn’t have any time for a configuration screen for example (which is kind of important for a 3d game), no music, and badly written text…
I have the first area barely playable, and the game called for 4 areas… So, there was no way in hell we would finish this on time…
We’re going to finish this in time, for several reasons… one is that we want to see it finished and released (free, of course)… second is that we were learning tons of things; this was Rincewind’s first competition (and he did a bang up job), and this was the first time I entered one of these using Spellbook… that part of the experience I have mixed feelings about…
Anyway, here’s the last development screenshot… we might try to enter again before the 6th January deadline, but we’ll see…
This was to be the area where we fought the final boss… Yes, the game was going to have a final boss… besides the graphical adventure component (pickup objects, use objects, examine people, etc), and the stealth/sneak part (to avoid the enemies at the beginning when we are unarmed)… Yep, we should have scoped this better indeed…
Well, this is a broad statement… art is going very good indeed…
Code, not so much… The SurgePlayer wasn’t ready for this type of “intense” competition… there are still loads of things that aren’t working properly in the system, and as such, I loose a lot of time trying to get it to work properly (or fixing a work around)… It’s too big of a system to be wieldy enough for this kind of 48-hour competition, since it’s hard to do small fixes and workarounds just to get things working…
The end result is that it’s looking shaky if we’re going to be able to finish the game or not…
Most behaviors of the game are already coded in, but there’s still tons of things that have to be done, including writing all the game text (which is no small task)…
Still, I intend to fight to the end, even if I don’t sleep tonight!
Anyway, this has been a great exercise for several reasons… found one million small issues with the SurgePlayer, and the SurgeEd have been behaving well enough…
Current development screenshot:
