Grab it!

[Download:]

Download:
SecondOrder.zip

What?
At inception, I was thinking of this game as "ASCII Deus Ex", but "Real-time Roguelike" might be a less copyright-infringing description. Second Order will be an action RPG with deep and complex systems, set in an infinite procedurally-generated world. I intend to support modding as extensively as possible, without getting sidetracked into "making an engine, not a game" territory.

Why?
After spending years working on a yet-unannounced indie first-person shooter, I was itching to work on something with minimal content overhead. So I deliberately chose a format which has virtually no art or audio expectations. This project is purely about programming and design, the two parts of game development I'm most interested in. I don't have any grand plans for it, just some loose ideas--I'm kind of excited to see where it goes!

When?
I won't be targeting a final release date. This is meant to be a project that goes live ASAP and then follows the "release early, release often" methodology. I've been working on core tech for about three weeks now. Several of the fundamental systems are ready to go live, including the launcher/patcher/modder frontend, the entity component system, and chunk streaming/serialization. I'll try to get some simple gameplay systems and a first pass of terrain procgen done within the weekend, and will release the seed build after those features are done.

Platforms
Currently, Second Order is a Win32 executable. In the long term, I would like to support Linux and Mac versions too. However, I'm writing the tech from scratch, so there's a lot of low-level OS-interfacing systems that I'll need to implement twice more, and I don't have any experience with those OSes. I'd consider open sourcing the project if some smart person could commit to porting to one or both platforms. Or if you would like to contribute to the "Buy David a Mac Workstation" fund, I'll make that information available later.

Screenshots
There's not much to show yet, but here's what it looks like at the moment.

       

       

       

       

       

       

       



Updates
Sept. 5: It's been a pretty productive weekend so far. I got the foundations of a procgen graph implemented and converted some special case gameplay code into a slightly less special case form. Working with a component entity architecture for the first time is interesting. I'm struggling a bit to make rapid progress, but the code I'm writing seems more robust and reusable than my usual object-oriented gameplay code.

Sept. 6: I figured out a good algorithm for distributing points sparsely and randomly across infinite terrain. That will help solve the problem of how to spawn entities procedurally (or rather, functionally--all my procgen is purely a function of the world space coordinates). I don't yet have procedural spawning implemented, but I've demonstrated the algorithm by dotting the desert biome with green cactus characters.

Sept. 10: In the last few days, I've implemented procedural entity spawning, entity collision detection and response, and a vision system.

Sept. 13: I added pathfinding on Sunday, but it was adapted from a navmesh implementation for a 3D game and didn't perform so well on a dense grid. I rewrote it all today with the grid in mind, and it takes about 6% of the time it was taking before. Success!

Sept. 17: The past few days have been spent working on destructible terrain. It now has a health value and reacts only to certain damage types. I've also done a bit of refactoring to make some things that were previously hard-coded be represented more generically through the event system, which was driven by the desire to update the player's vision cache when the terrain is altered. Next steps will probably be adding some non-sentient entities that can play with the existing systems. Probably exploding barrels. I can't resist them. They're so 'splodey!

Sept. 20: Exploding barrels are in, and I added some more kinds of generators this evening to support rooms and corridors. I'm not super happy with the first pass, but it seems like I'm on the right track and can get it to a better place with tuning. I don't think I'll ever have rooms as well-arranged as a good Roguelike, just because of the way I'm doing generation in a single purely functional pass. But I'm enjoying the challenge of finding ways to create features within that framework, and I expect the results to work well with the game I'm making.

Sept. 21: Spent a bit of time this evening in between drinking beer and playing DXHR to improve procgen interiors, and I found a technique I'm pretty happy with.

Sept. 24: Added map exporting. Not really a critical path feature, but I wanted to see a zoomed-out view of the terrain I was generating, so there it is!

Oct. 17: SecOrd work got derailed by real work and stuff there for a bit. And also, I was simply procrastinating. But I got AI behavior trees started yesterday, and I expect I'll have some enemies moving and shooting by the end of the week. I've been wondering if using modern game AI techniques is overkill for a game like this and if I could get away with much simpler routines. But as my goals for this project include a rich, RPG-ish simulation and robust, extensible content authorship, I think it is worth investing in more complex systems.

March 7: Well, it's been a while since I updated this. Things I've done since October: more AI knowledge and behavior work, some actual enemy characters, a bunch of work on export tools to visualize the procgen graph, player death and resurrection, some UI, better procgen for buildings, huge improvements to memory allocation patterns, frobbable doors, and more. And I've been able to use this project as a sandbox for whatever random project interests me. In particular, I've implemented Jump Point Search A*, and I'm now prototyping a kind of social sim AI to explore more artsy ideas like what happens when a player tries to forgive an enemy instead of killing it.

Learning about Python modules and packages while working on a small prototyping project, I wrote the following:

Code:

AI = ai.ai.AI()

That's exactly what I do: slerp the quaternion, lerp the translation vector, and combine them into a matrix.

If you look at your matrices before and after the operation, does anything look especially wrong about the result? Does the translation part end up being wildly different than the translation part of the A and B matrices somehow?

I'm still having troubles, Whenever I press the jump key it jumps fast and very jerky.

You're not multiplying your velocity by delta time when integrating position.

Code:

position.y += velocity.y;

should be

Code:

position.y += velocity.y * delta;

I believe it's also more common to integrate velocity first, then integrate position using the newly-solved velocity. You'll get more stable results that way. (http://en.wikipedia.org/wiki/Semi-implicit_Euler).

Even if you don't use threads, you can fix the hanging. It's fairly easy to pause and continue an A* search. Just save off your open and closed sets after some number of iterations, and then load them back in to continue the search on a subsequent frame.

It won't get results any faster, obviously, but it will prevent hanging, and then you can cover it up with a cute animation of the AI with a little thought bubble over its head. Game development yeah!

For Guitarguy Rocks Out, I built a bunch of in-game tools. I originally intended to author everything in a hex editor, but it turns out that's super tedious. So I made:


Color editor


Palette editor


Sprite editor


Tile editor


Glyph editor


Level editor (tiles and entities)


Level editor (collision)

By virtue of being in-game, all changes were instantly reflected in the game. And if I was playtesting and I saw something I didn't like, I could just pull up the appropriate tool and try fixing it right then. Real-time editing made iteration fast and painless.

I wanted to write a music editor, as well, but never got around to it. So I did end up inputting all the music by hand in a hex editor. It wasn't too bad, actually--not dissimilar to using a music tracker program.

(I'm going to break one of my rules on this forum and talk a bit about my professional work. Can't find a way to respond to this without doing so, as my indie work is only a hobby and this article is about the commercial games sector.)

The tone of the article seems to be baiting. The very first sentence speaks of this alleged poor reputation of game programmers, but that's not an impression I share. Game development can be terribly mismanaged, but not because programmers (or any other developers) have no discipline.

Some of his assertions are ridiculous. If anyone is making games without source control or bug tracking, then yes, they're 15 years behind, and ignorant to boot. But everyone uses source control and everyone tracks bugs. No studio could possibly sign a project without these things--they would never pass due diligence with their publisher.

Code reviews are rarer, perhaps. We do a relatively casual (I think) version of them where I work: any programmer can ask any other programmer to do a code review, and it's just a cursory sanity check, not an intense line-by-line inquisition. More often than not, the code's author catches more mistakes than the reviewer. That's the greatest benefit of code reviews, in my opinion. It forces the author to review his own code once more before checking anything in.

I can't imagine there's any game in development that isn't agile. Heavyweight waterfall-style processes do not jive with creative minds. Each new thing that gets added to the game can (and should!) inspire the team to greater heights. Developers will get new ideas halfway through the project once the creative juices get flowing. Things that sounded good on paper will turn out to suck in practice (which is why you prototype properly, but that's a separate rant). I truly believe that all game development is inherently agile. There's simply no other way to actually make a game, because games are an artistic endeavor and not an assembly line.

And maybe that's really the source of game development's reputation for mismanagement. How do you schedule an unknown quantity of work? How do you define future milestones when goals may be continually shifting? Obviously, a good team must have the discipline to keep that target date in mind and stop adding and changing things as the deadline approaches. But notice that "timely delivery of the final product" is tellingly not a tenet of agile development, and yet it is a very present constraint in game development. And that's what I believe the author fails to understand.

P.S. Trying to unit test gameplay code is dumb.

I hacked the Blender .obj export script for my own nefarious purposes, so Blender is my level editor.  Is that cheating? xD

I also use Blender as my level editor. Not the greatest interface for configuring placed object properties, but it works. And I like that it's so scriptable. In addition to a custom export script, I whipped up a custom texture alignment script that's more suited to large flat world geometry than any of the default unwrapping.

Quite a lot of games got no votes this time. That's rather unfortunate. Was it more difficult than usual to try them all, because they were multiplayer?

(Full disclosure: I didn't attempt to play any of the other games or cast any votes, for this exact reason. But it's possible I'm just a grumpy hermit.)

...release the mouse cursor when I pause the game. Please acknowledge that maybe I want to switch windows once in a while.

It's done! Download it!

Quick postmortem on this project, since I neglected to do a dev journal:

I was initially hesitant to enter this compo, as I'm not a huge fan of multiplayer games and I didn't have any idas that I felt were especially strong. But I haven't done much hobby/indie development the last few months, and I was hoping for a creative spark like I experienced working on Guitarguy last summer. I ended up convincing myself that it would be fun to work on an isometric game (something I'd never done before) and to focus more on design than tech. I wrote up a page of design notes the first night, focusing on the pillars (Approachable, Frenetic, and Deep). I had no ideas for the theme and decided to punt on that, assuming that some brilliant idea would strike me later.

Progress was slow at first. Dealing with isometric tiles was a new challenge for me, but it turned out to be less fun than I'd hoped. My first major goal was to define and render a volumetric tile map. At the core of the game's initial design was a dynamic world. Lots of strategy games offer destructible terrain, but I also wanted to support construction. It was satisfying to see randomly generated volumetric worlds being rendered after a couple of short days of work, but it also revealed that I hadn't fully considered how I would handle occluded visibility of sprites.

Dealing with visibility ended up being a key problem throughout development. I experimented with transparent overlays of varying opacity and complexity and ultimately settled on a continuously fading overlaid render of the layer just above the focused tile, with all higher layers completely absent. It was the only solution I tried which was remotely readable in noisy random environments, and it ended up working just fine in the simpler, neater map I later designed.

Many of the deeper features I'd originally envisioned were cut, due more to apathy than difficulty or time. (After all, I'm calling this done with two weeks left on the clock.) I had conceived of a game with a strong base-building and resource-gathering component, but by the time I had some rudimentary combat gameplay working, those aspects had become less interesting to me. I still wanted to support terraforming as a core feature, but I was finding that it didn't provide the sort of tactical options I'd hoped it would. Changing the order of the phases (action, then move), or introducing X-Com-style Time Units might have made such choices more interesting, but those and other approaches I considered tended to conflict with the Approachable or Frenetic design pillars.

At that point, I almost wanted to abandon the game. I'd been less than enthusiastic about the project from the start, the gameplay wasn't as engrossing as I'd hoped, and I still had not discovered a good theme. Furthermore, I suspected that the fact that I was making a hotseat game meant that this game was far less likely to be played than any other compo entry I've worked on. But I'm stubborn and I hate to fail. I soldiered on, adding a few missing features and doing a quick art and sound pass. Although I knew the game wasn't great, I wanted to finish it properly. Having never picked a theme for the game (largely because I'd never spent any time trying), I drew up with some rather generic and colorful sci-fi units with no weapons. I'd had a very vague idea of a battle fought in the mind, maybe with the soldiers representing something abstract, like thoughts or ideas. Although I didn't pursue that thread, it led me to the idea of a war fought with telekinesis, which led to the horrible title TKtics (pronounced tick-ticks, if that wasn't clear).

So, there it is. Not my favorite of my games by a long shot, but I finished it and I'm proud of that, at least.

<div style="padding: 5px; padding-bottom: 0; float: left"><img src="http://www.dphrygian.com/tktics1-300.png" width="300" height="200" /><p style="margin-top: 0"><a href="http://forums.tigsource.com/index.php?topic=17139.0">TKtics</a>, by David Pittman</p>
</div>



TKtics, by David Pittman

Bump!

I didn't keep a regular journal of this game's development like I usually do for compos. But I didn't abandon it, either. I've updated the first post with the link, but here it is again: http://www.dphrygian.com/bin/TKtics-Beta.zip

I'll be testing more over the next few days and possibly adding some effects, as it's rather spartan at the moment.

...ship with at least some basic debug/dev tools. I've frequently wanted god mode, ghost/noclip, and pause/slow-mo sim so I can study a game without constantly getting killed, and it's very rare that games ship with "cheats" like that anymore.

[Dah-ray]

...my world of pronunciation is collapsing around me. It's not a person, but is it Ludum Dah-ray or Ludum Dare

It's Lou-dum Dah-ray.
But tons of people call it Loodem Daire anyway

Always wondered that myself. I guess it means something about giving games, as opposed to being a dare to make a game?

Really nice style in the isometric screen posted, is it the actual style or placeholder graphics? I quite like the minimalistic style myself. Is it in-game tile-rendering or a mockup?

It's placeholder, but the actual art may end up being equally minimalist (albeit with a better palette). I'm still completely undecided on theme and art direction.

This sounds mighty interesting. Any ideas for unique mechanics yet? "Destructible terrain" sounds like it could make something great...

I'm planning to use some RTS tropes, namely resource gathering and base building. Base building will be done in a very hands-on block-by-block fashion (to complement the destructible terrain). Minecraft is an obvious influence on that, and I've also been thinking about the building phase in Rampart. Plus, I'm not aware of too many head-to-head turn-based strategy/tactics games, even though it seems like a perfect genre for competitive play.

I've since cleaned up some of my first post, but part of what I originally wrote was: I expect the tricky part of making this game is going to be keeping it fast and punchy. I want to capture the tense, frenetic experience of a fighting game match and not let players get bogged down with a myriad of decisions and unwieldy menus. This is especially important in a turn-based game, and I'm considering ways to keep each player involved during the other player's turn (perhaps a split-screen mode, so you can continue to view the map and even schedule future moves while your opponent takes his turn).

Well, this isn't progressing as fast as I'd hoped. I decided to write a TGA loader tonight. Never mind that I could have used any existing image library to do it, or that I've already written support for other file types--no, I wanted to write a TGA loader.

Also, I'm discovering that the half-baked 2D image library I wrote almost four years ago and never used on a large project is kind of poor quality. Shocking!

But in any case, I've got this project off the ground and I'm ready to start making some isometric terrain!

[asymmetric games]

I'm hoping to see some asymmetric games (even though I'm not doing one myself). Things like:

Boss Fight: P1 is the diminutive hero and P2 is the big bad boss. The challenge here would be making things interesting for both players (imagine playing as Donkey Kong, just throwing barrels down the ramps at a very distant Mario--not very fun).

Versus Shmup: P2 controls a flock of endlessly respawning chumpy cannon fodder. Perhaps take a page from Nidhogg, and when P1 dies, the roles get reversed: P2 takes control of a single ship, P1 controls the waves of baddies, and the screen starts scrolling down (or left, if it's a horizontal shmup).

Versus Brawler: Same deal, but with more kicking and less shooting!

Also, it would be neat to see games that rely on audience participation in interesting ways; maybe something where P1 is an evil Dungeon Master setting up a devious trap-filled labyrinth for P2 to navigate; but the audience can see everything P1 sees, and they're free to shout it out, so P2 can use their noisy (and perhaps conflicting, or even intentionally misleading) advice to try to suss out where it's safe for him to go.

(I sort of want to steal that one for myself, but I'm sure would never have a great opportunity to showcase it...)

Be aware though, I'm probably going to implement that on my game too.

What I'm saying is that you can totally do it, but I'll do it better. <3

Oh, it's on!

But seriously, feel free to share more ideas and I will steal them too.