Long story short, life has it’s ups, downs, and distractions. But while other things come and go, Atomic Space Navy is always on my radar as something I need to do. Most other game projects I start, while they are generally things I’m excited about in their own right, are things I view as exercises that might make ASN better in the long run.
In other words, any other projects I’ve blogged about in the distant past are pretty dead right now, but ASN isn’t. So, what’s happened with it? There’s a number of areas I’ve put time into but haven’t talked about yet. One of these days I may even release a Tools update with some of them.
- GUI polish: I’ve gone through and reskinned the GUI, and adjusted the layout some to be neater. The default Unity skin looks pretty cheap, largely because it’s so widely used. the new skin is certain to get replaced again in the future, but it’s a nice step forward. I’ve also adjusted some of the drawing logic to be nicer looking.
- CLI polish: For the console version, the command line interface has been moved over to a more standard library, which makes expansion easier and enforces consistency in the syntax going forward. It will mean a change from the existing syntax, though.
- Stargen: Something I’ve wanted for a while is to be able to generate random star systems and test them for stability, then just turn it loose on something with a lot of processing power and come back in a few months to find a nifty pile of places to explore. I’ve made inroads to that, though it’s still a work in progress.
- Testing: I’ve started implementing some automated testing of ASN’s codebase. It’s already shown some results, with missing functionality and quirky bugs popping out of the woodwork and being fixed. There’s a lot more left to test and fix, and it’s a surpisingly fun process.
- Race Prototype: It’s a long way from something I’d put out to the public, but I have a limited prototype of the Atomic Space Race gameplay that I personally find playable and engaging. Lots of work to be done, but an encouraging step towards a movement interface.
I’m not going to promise more timely updates in the future, but each of those bullet points could have been it’s own blog post when it happened. I’ll be keeping an eye out for such opportunities in the future.
So where’s that game? Here’s that game.
Game prototype really. It’s still rough enough that I’m not putting a playable version up.
The weekend game jam didn’t really achieve the goal of kicking my ass into gear, but the problems this game poses are important enough for me to solve that I wasn’t going to leave it by the wayside. I’m still hacking at it.
The game is a simple Real Time Strategy game, the working title of which was Really Tiny Strategy, but I’m now calling it Whitespace. Working with colored shapes in a white void is a visual that I like.
The RTS is a relatively complicated game to make compared to the simple shooters I’ve put together in the past. Lots of layered complex behaviors. My goals for this project are in order:
- Basic usable RTS user interface
- Functional enemy AI
- Android deployment
At present the first two are working, though both could be refined a lot. My immediate tasks are code cleanup and core functionality fixing, as well as doing some visual design for the UI. My end goal is to have something I can put on my phone and proudly show to people if they ask me about this whole game development thing. Lots of work left ahead of me, but I didn’t want to leave the blog silent any longer.
So I’ve been pretty bad at One Game A Month(1GAM). When I have had the focus and desire to work on game dev I’ve focused on Atomic Space Navy. I don’t really regret that, because ASN is important to me, but I still believe in the benefits of getting games done and out the door, and I think that ASN would be better for me having that experience.
Game jams are a pretty good way to get things done, with pressure and community. There are a few going on this weekend. For one reason or another, none of them really are clicking with me as something I want to participate in, but I still want to jam in general. So I will. Tonight after dinner I’ll mark the start of my own private challenge, 72 hours to get a new game playable and show-able. I’ll chronicle the progress on twitter @EatThePath and post the game and info about it here afterwards.
I’ve already got some ideas on what I want to achieve, and it should be fun!
Around Christmas I released Orbit Toy, and while it achieved it’s goals it does have a problem. Simulating the solar system is all well and good, but Orbit Toy(and by extension Atomic Space Navy) is meant for fictional science as well as reality. Building a fictional star system of Orbit Toy is possible, I’ve done it, but it takes a lot of math and hand editing of text files. The time between putting new values into a file and seeing results is also long enough to make trial and error pretty rough.
Luckily there exist ways to describe the shape of an orbit that are quite convenient. This past week I’ve been working on a sort of level editor for Orbit Toy called System Builder. System Builder allows you to edit a star system in a graphical interface, seeing orbits change shape immediately, and then save the results in a format that Orbit Toy can read.
System Builder is not a simulation. If your system is stable its display should be relatively accurate, but it not then all bets are off. If for example you make the earth heavier than the sun, System Builder will still assume that the earth, and all the other planets, will be orbiting the sun despite the fact that when you load that file into Orbit Toy at best everything will orbit the Earth, and more likely everything will be ejected from the solar system. The moon will still be given the right orbital velocity, but even then Orbit Toy’s simulation is unlikely to be able to handle an orbit that tight and fast.
Future versions of Orbit Toy will at least come packaged with a copy of System Builder, and may actually incorporate it directly into the program.
The initial version of System Builder will be available soon. The default system it comes with will include all the planets(you get Pluto as a bonus, and possibly the other four recognized dwarf planets too) and several of the major moons of the solar system. If anyone makes interesting systems and sends them to me, they may be included in future releases.
Still going well, though not quite as fast as I’d like. Probably won’t have as much polish as the game deserves. Most of what I’ve got done is setting up the game’s code such that it’ll be easier to expand in the future, rather than adding content. But sound, some UI elements, player health, and changes to enemy behavior mean that the game isn’t trivial anymore, and can be lost. Sound also spruces it up quite a bit. It’s definitely a playable game now.
Read more to play the current version.
The goal of Fast Attack is to provide a sense of building speed. I now have a working prototype that hooks several systems into an adjustable acceleration curve, with plenty of room for extension. A playable prototype is embedded below the ‘continue reading’ link.
I like how the game is looking so far, though simple. I should have an minimum-acceptable-release version soon. Plenty of content and polish from there of course. Sound shouldn’t be a problem, but finding the right music for it will take some work. It is far, far closer to a game than Rebound was at this point, though it is a rather simpler game.
Rebound has not entirely languished! I have had to cut down my plans some, but the core movement code has firmed up a lot since the initial prototype posted earlier. In fact, an updated prototype is available to be played at the same link as before(Here it is again)
The visuals are going to end up being quite simple. I’ve got what is probably close to final gradable surface art. Heres a screenshot of a level mockup including it with plenty of placeholder other stuff.
I’ve decided that I won’t try to model, rig, and animate a human form this month. The player will be a bouncy ball, probably with some effects to indicate state. I’m also leaving my ideas of story by the wayside, and settling for just some pure gameplay.
Finally, I’m considering a new name. A game’s name should be somewhat searchable, if you stick it into google you shouldn’t get a wave of other info. Rebound has a fairly populated google result set. The chief alternative is Grab, Jump, Bounce, but I’m not super happy with it yet.
Ten days to go.
One Game A Month
This year I have decided to participate in Christer Kaitila’s One Game A Month challenge (henceforth referred to as 1GAM), which means I will be attempting to produce 12 playable games, as finished and polished as possible, within this year. A tall order, but proven possible by some already last year. So lets talk a bit about my game for January.
I have started keeping a file with a list of game mechanics I want to use, and it grows pretty steadily. One of the prime candidates this month was Atomic Space Race, a sort of puzzle game building off of Orbit Toy that challenges the player to plot the fastest course through a star system that hits certain points. It’d build on the existing code and be a considerable step towards the goal of Atomic Space Navy. However, having worked on Orbit Toy pretty intensively lately and knowing that I have committed to 12 games this year, I decided to shelve that for later and find something else to focus on for January, so I skimmed my list and started sticking ideas together.
The result is Rebound, a 2D game about exploring the interior of a space station in freefall. You move by grabbing and ‘climbing’ along surfaces, or by leaping and bouncing off of walls. Since settling on this idea, I’ve worked out a very rough prototype of the movement, playable at this linked page.
I’m excited about this idea, but it has some large hurdles.
- As I’m not aware of any other games with movement like this, it’s harder to tap the collective knowledge of the internet and find known-good solutions to problems, or even to learn from past failures.
- More critically, this game demands some level of character animation. I’ve dabbled in character animation in the past, but never from a programmer’s perspective, nor with any of the tools currently available to me. Adding learning the tools to the burden of art production is an ominous prospect. I may be able to skimp on the art side some, but the point of 1GAM is to produce finished games, so that option can only be taken so far.
- This type of game can live or die on level design. I’ve no practice here. Guess I’m going to get some by the end of the month. The results of my experimentation with this will decide whether Rebound is purely an exploration game, or if I need to include enemies and combat to liven things up.
Sound and music are also obstacles, but plenty of resources exist for those.
I will do my best to keep this blog updated as the game progresses.