Jun 7, 2015 · 4 minute read
GSProgramming
In many games things like the ability to stand/sit/move are considered fundamental for the game unit. Behaviour and restrictions to these functions, if any, are hard-coded. In our case, ability is tied to the body part. When there’s no body part, there’s no ability. Idea worked well with one-time abilities: equip the gun and you can shoot, drop it — ability goes away. On contrary, it doesn’t work at all with continuous abilities like standing.
Read On →
May 20, 2015 · 1 minute read
ArtGS
Some pictures for you.
Read On →
Apr 16, 2015 · 5 minute read
GS
Abilities were planned as an important part of the architecture almost ever since the game development was started. Scripted actions, totally customizable and very loosely coupled with the rest of the system, they were supposed to cover everything unit would ever want to do. Unlimited modding capabilities, fast development, easy changes.
Then the reality kicked in.
As you can see in this advanced picture, the idea was rather simple and obvious: make separate body parts responsible for separate abilities. Then you can walk around the entire construction and obtain the final list of everything this unit can do.
And, of course, any changes in the body plan, including picking up items, dropping items, losing a limb or two, would automatically update the list of available actions:
Care was taken to avoid false additions, so as when soldier picks up item he doesn’t know how to use, or picking up things that only supposed to give abilities when they are properly attached to the body (goggles in your hand will do nothing).
I was able to find a solution for scripting, both support and performance-wise, so scripting is practically a breeze. But as I’ve been implementing various parts of the design, architecture problems started to rise.
There are three main problems: GUI interactions, ability cancelling and state concurrency.
This post is about the first one.
Read On →
Mar 30, 2015 · 2 minute read
GS
Well, that was expected. As I said, I’ve been preparing the post about the abilities, but I still can’t quite get it the way I wanted. Sorry about that. The truth is this thing had grown into the heavy psychological block, and I’ve been dancing around it, cheating myself to postpone the unwanted work. Always trim your mental lawn, kids. So I laid down some work for the editor, which was required, but not a top priority, and I’ve implemented the debug console, completely with remaking the GUI system, which was even less needed right now.
Read On →
Mar 18, 2015 · 1 minute read
GS
We’re back in the saddle! Short news: Alone no more! Stephen White kindly agreed to help me and so there are two of us working on the project now. Big improvements. I’ve been training in code and drawing all this time, working on a serious business™ software with a very good team. Now i urge to rewrite most of my old code, but the improved speed, stability and maintainability are worth it.
Read On →
Sep 29, 2014 · 1 minute read
GSIntrospection
Ok, where the hell.. I’ve been? Moved to the biiig city. No money. No job. Thug life. That happens. No progress on the game then? Yes. Nothing big, at least. I’ve planned to put up prototype before moving, but failed. And when? Couple of months, i’ll be damned but i’ll make the thing at least somewhat playable. Playable? One map, two teams, several soldiers, working bullet physics, hopefully working FOV (questionable), sandbox for object testing, that kind of things.
Read On →
Aug 29, 2014 · 2 minute read
Gamedesign
This is my Ludum Dare entry. There are many like it, but this one’s mine.It’s that kind of strategy where captured worlds are constantly building units, also bundled with an indirect control via routes and a twist with the world connections. Main feature of the game is the ability to connect the worlds. With each connected world conglomerate switch to the bigger ships. Tiers are untransitively balanced: fighters<-corvettes<-frigates<-fighters. So the two connected worlds beat two single worlds, but three connected worlds are worse than three singles.
Read On →
Aug 19, 2014 · 1 minute read
GS
Ludum Dare is a great chance for training in making completed games. Given the time limits, you have no margin for straying around, only you and your idea. The skill i’m striving for. Here’s the entry i’ve prepared for the warm-up event. It’s the first ever game i’ve actually completed. Behold, the Gauss Flux! http://www.ludumdare.com/compo/ludum-dare-30-warmup/?action=preview&uid=38947 The idea was to make shmup with the ability of building your ship on the fly from various details.
Read On →
Aug 14, 2014 · 1 minute read
GS
Simple abilities implemented, call routes overhauled. Now everything regarding abilities goes through the actor, allowing me to influence ability calls with actor mental stats. Orders implemented. They are smart, they are strong, they could handle the failures. It’s an additional level of abstraction needed so the AI could operate constructions like “Go somewhere north, take sniping position” instead of “go 1 tile north, go 1 tile northeast, etc”. I’m considering making these scriptable.
Read On →
Aug 7, 2014 · 7 minute read
GamedesignGSProgrammingScripting
So, i’ve realised there’s no sense in releasing a prototype which contains no game at all. And it turned out there’s a bit more underlying work ahead, and suddenly i’ve got buried under the ideas which aren’t quite fit together as they were. Four days i’ve been writing and drawing diagrams, trying to fit every piece together, with some success. If you’d want, you could have a look at what’s my design documentation looks like.
Read On →