next »

[Triplefox]

Updated April 22
-=>>PLAYABLE BUILD HERE<<=-






Old builds:
Dec 1
Dec 6
Dec 13
Dec 20
Dec 25
Dec 31
Jan 7
Jan 16
Jan 17
Jan 19
Jan 22
Jan 27
Jan 29
Feb 12
Feb 23
Mar 1
Mar 4
Mar 18
Mar 27
Mar 31
Mar 18
Apr 15
Apr 21



--------Original Text---------

This is a Flash game about a mercenary submarine pilot's adventures. It is coded in haXe. It will be commercial and use micropayments.

I've been doing this all by myself. It's been in pre-production for months, and finally I'm ready to start giving some real updates. They'll be mostly technical at first and increasingly art-heavy later. The timeline looks like this(with dates from September onward being projected work):

Late May: Got laid off. Had spare time and finances. Decided to start working on it.
June: Various concepts, preliminary engine work.
July: Started on tools.
August: Finished lxedit. Got pipeline running.
September: Engine work, prototyping in-engine gameplay and all features, first art, vertical slice?
October: Production of levels, assets, content.
November: Finish production, polish and prepare for release.

I may be a whole month off in content production. This is quite a big project and it is aiming for tons of polish. But the consequences of a schedule overrun are small for me, so I'm assuming the best for now.

September 9


Basic menu screens are all in. I'll be giving these another pass or two to add cool art and maybe a tween-in. Right now they're just angled with Flash 10's rotateX property, which is awesome for these kinds of things. I made key-configuration code ages ago and it works pretty spiffily.



Gameplay, using faabulous colored rectangles and art from StepMania 4 to test my map's stamps. At the center is the player, represented as a set of collision tiles. White squares are environment collision tiles(the environment collision is in and working). Green dots are entity spawns. Backgrounds are stamped layers made in lxedit. I take the JSON data from lxedit, converting entities to haXe serialized objects in the asset pipeline(smaller/faster to parse), and tiles and stamps to ByteArray data. Entities in the engine are "Dynamic" objects, all with unique IDs, either instanced directly from the unserialized data, or spawned through code. The last step in the spawn process adds in a list of hooks for various components(collision, AI, etc.) so I have a universal means of cleaning up any dead entity.



In-game menus are working too. Here I'm controlling a drone sub (the smaller rectangle) and have the option to dock with the main sub to resume piloting the main one. The drone subs were the key concept when I originally came up with this game years ago. They let the player take on various kinds of abilities in a modal way - one drone can get into small spaces and retrieve objects, one can clear out rubble, etc. One of the tasks I have for prototyping this month is to come up with various interesting drone abilities, pick the best, and integrate them into the main sub's gameplay(which is more shmuppy).



Solidifying the overall engine architecture has been my focus from the beginning. I've had too many bad experiences of problems exploding in my face late in a project. My biggest tool in this endeavor has been to implement a formalized state transition system, or STS for short. (The difference between an STS and FSM is: FSM has an end state and does not loop.)

I use the program QFSM to create these pretty diagrams. They get exported to a CSV-style table of states and transitions, which I then combine with magic comments in the existing code to pass to a code generator and generate "cached" code to compile. The code generation process gives me a set of constant values named after each valid state and transition event, and calls the appropriate states from a giant switch statement using the constant values. Each state is a function containing more magic comments for the transitions it is allowed to have. The code generator checks to see that there is exactly one of each transition and lets me know if it's otherwise.

The results of this process are pretty godly compared to what I put up with before. It's really a lot like starting with a skeleton and adding on the flesh: with the high-level concerns out of the way, I only have to worry about each individual transition's actions, rather than "how do I untangle these actions when the game gets in state x." Or worse, not knowing that I introduced an invalid state y at some point. Those problems were already solved for me when building the STS. And I get rewarded for it in spades as it leads to some very clean compartmentalization of things like the menu system, the dialogue system, etc...

I am also using these to control entity AI, since they'll obviously come in handy there too.

Anyway, the next features I'm going to implement(and pretty much the last ones necessary for gameplay) are shooting, enemies, death, and the dialogue engine. Then it will be prototyping and art! Yay.

[medieval]

what you did so far looks cool,





but may I ask how this game plays?

[Triplefox]

Let me put it this way: I would tell you how it plays, but I'd rather get the game to the point where I can show you. That'll be the subject of the next update.

[increpare]

the qfsm idea is really neat

[Triplefox]

22 October

I haven't touched this thread in a while, so how about an update? All my old plans have gone off the rails and I'm going to make the game episodic in three parts for my own sanity - I can release faster and focus a little more on maintaining a high quality the whole way through. It'll take longer, of course - now I'm shooting for the end of the year to finish one episode. Release might have to wait for the new year after taking into account sponsorship lag time.

But the game looks like this now:


So yeah, I've been doing some work on art. A little bit of shooting gameplay starting to come along, in dribs and drabs. I'll be iterating over it, so I'm hoping for it to keep improving. But the bulk of the work has been technical and that's the rest of this update.

Biggest catastrophe: A cascade of technical itches to scratch. My tool was crashing when I started making real maps, and I suspected PyQt's PNG handling to be at fault, so I decided to just rewrite it in WxPython. I also had a ton of ideas for how to improve the program, so there were other things influencing my decision. The first time took two months, the second time took five days and it's in most respects a better tool now. I also have to rework the pipeline a little before the game's development can start again, but it's amazing how fast a rewrite can go when you know exactly what you want and how to do it.

WxPython turns out to be better than PyQt for most apps because PyQt tries to dump Qt paradigms(Qt versions of primitive types, Qt slots and signals, etc.) into Python and just makes everything a zillion times more confusing and error-prone, where Wx treats the code "Pythonically" and you end up writing less, even when you implement custom components. Only downside is that my rendering got noticeably slow... but it's a tool, it doesn't have to be too speedy.

But the main improvement was in how I handled data: I store everything in buzhug now, which gives me fast, easy data integrity and query support. This improvement also led me to decide that the game should implement some relational data modelling internally, so I started on that too, and have got the basic data structures started already:

The original way I did it was to give each entity a property field and attach component objects on top of that. That is OK and could easily have shipped, but I was hand-maintaining ugly one-off indexes all over for each type of component. It bugged me seeing that kind of repetitive, error-prone thing, and I decided to go all the way and work out a way to make my data relational, maintain its integrity well, and provide some decent query mechanism. It'll take perhaps one more week to do, I expect.

The new way involves something more heavyweight than property fields - now everything revolves around node objects, which are sort of like columns in a SQL table. You assign each node any number of indexes, a "home" set(what was the old property field), and "mirrored" sets(acting like SQL foreign keys). The indexes can be any collection structure, but I'm using an array of lists of integers - the array partitions values within some predefined range and # of  subdivisions, and then delegates the key ordering in each partition to the list. When there are updates, it's automatically sorted, and I can select keys along any integer range.

Net result: The amount of code I'm writing is going to shrink like crazy. The data will be automatically synchronized for me, and I can reuse the same structure over and over with minor changes in the data layout: positions of entities and collision boundaries, counts of enemies, item collection counts, timed sequences of events... the access will be uniform across all of these and I can mix and match my queries to filter through all the data sets, or add custom indexes where query speed is needed. I can also cleanly destroy entities because of that same uniformity: simply delete one node in the set and it'll destroy everything related, cascading through all the mirrored rows. All that boilerplate....gone.

And that, I think, will be the last technical improvement I'm doing for this game Going for awesome code really sucks up a lot of time. But at the end of it I'll have learned and written stuff I can apply to the next game, so hopefully at some point the savings will appear

I'll start putting up demo builds in the next few weeks, once it's to the point where a demo would show something meaningful. Stay tuned.

[nihilocrat]

yaaay!

How is HaXE treating you?

[Triplefox]

yaaay!

How is HaXE treating you?

haXe remains one of the most productive languages I've worked with. I fall back on Python when I need more libraries, and Python does have a little more sugar in various places, but when I work with it I'm like "man, I have to run my code over and over just to find these stupid type errors." I really don't have compelling reasons to use anything other than those two in making an solo-scale game.

Flash is still a pain though.

[Triplefox]

Hit a small milestone for the end of October: the engine is back on track with all my new revisions and architecture ideas - I've got the player moving and colliding with the environment again, with more fine-grained increments than before, though I still need to test actor-to-actor collisions. I don't think I'll be tempted to try refactoring my codebase any more cause I've thrown nearly every architectural idea I've ever had into this thing by now, six months in. Way more effort than necessary to ship the game, but it gave me a lot of thinking room to develop the other concepts.



Leo was a huge help in getting this last code overhaul together. I've been raving about it for the last week or so since I started using it. I worked for a few days without compiling any code, just sketching out a little bit here and there in Leo outlines, adding files and changing things as the ideas clarified themselves; then today I fed it through haXe and it gave me a few hundred type errors to fix, followed by a handful of other errors when I ran it in Flash. Took most of the morning/afternoon to get the basic movement going, and then in the evening I fixed up the collision.  Leo replaces what I used to do with random text files scattered throughout my hard drive, and does it better because I can mix code and docs pretty freely. It makes writing code more like natural language writing, which is good for my motivation. Best of all, it gives me hope of being able to properly document all the code by the time the last episode is shipped and make a really, really nice open-source release.

[Triplefox]

November 18

I can now write code like this:

Code:

my-per-frame word:    # add 1 pixel x every frame to the entities this choreographer spawned #
	get-spawned
	with
		get-collision
		1 add-x
	end-with

and this:

Code:

test array:       # a simple dialogue box. before this I had a horrible "data-driven" system #
    "hello world." 
    "this is some text"
    say !
    ;

These are extensible languages, which, in my mind, means that I have finally have engine tech that can clearly surpass Game Maker for "rapid development," at least for this particular game.

Possible dates for releasing a "first playable": Thanksgiving day, the 31st, the 1st. We'll see. I have some breakage to fix but I think this may be the turning point as far as moving forward into playable stuff. I've iterated over everything several times by now, shaken down every core feature I can think of, so I don't anticipate any more delays

Oh, the game's gonna be episodic now. I have more than enough ideas to pull that off, and I want to give them all a great treatment but also release something in a reasonable time frame.

[george]

Loving this devlog Triplefox, keep it moving. 

[Triplefox]

November 29

I'll be putting up something playable on the 1st. It'll still look rough and placeholdery, but in any case, here's a main character dialogue portrait, to whet your appetite:

Name: Guy Kingfisher Age: About 30? Sex: Male Profession: Gun-for-hire Biography: Ten years ago, Guy's father was politically active, a champion of radical ideologies. While away on a trip, all of his known family went missing, presumed dead. The killers were never found, but Guy suspects that it was a politically motivated assassination and sought revenge. He has spent the last ten years honing his skills and looking for clues.... Personality: Despite being someone who seeks eye-for-an-eye justice, Guy is typically peppy and upbeat. He doesn't let very much bother him....it makes it easier to stab people in the back later. He has the occasional bout of rage, though. DSD's planned story arc uncovers the mysteries behind the deaths, the names and whereabouts of the killers, lost family members, and perhaps more...all within future-fantasy underwater settings. (In case you're wondering, the avatar inspired the character, not the other way around. I made some sprite sheets one day and decided that I would flesh out the character someday, it's just taken a year+ to do so.)

Edit: formatting!

[Triplefox]

December 1

Link is up in the first post. Play discreetly in your browser now, my captain!

Tiny, tiny demo content-wise; under 30 seconds of gameplay, debug output spamming the screen and various placeholder graphics, but it gives a good idea of what is to come. It ends after you pass through the door.

[Triplefox]

December 6th

SECOND PLAYABLE(1st-6th) - DONE

Create a timeable 5 minutes of gameplay.
Create drone gameplay, pickups
Add some dialogue scripts
Refine graphics

2nd: Breather.
    I discovered that digital paints are much faster to make than vectors - as much as a 10x difference. Fortunately I only had 1.5 vector pictures done so it poses no problem to switch.
    Tool work:
        1. Better tile placement -# CANCELLED because apparently there is a wx display bug that I can't resolve right now
        2. Store palette sets in db, allow them to be swapped in and out # DONE
        3. Brush cycling: Press "tab" while adding stamps to cycle. # DONE
    I did a little bit of work catching up with Blender 2.5. I think I will be using it moving forward just because the interface is more stable
3rd:
    Finish a painted Guy sprite. I tried two methods - a "smudged" painterly look and a clean high-res linework look. I'm going with the latter. # DONE
   Expand the demo level: New enemy type(the "Demon" ship) # DONE
   Add health pickups(auto-collected) from defeated enemies. # DONE
   Tool work: Auto-remove missing images from db with warning(instead of having to remove manually) # DONE
4th:
    Richard Evans talk at UCSC: 11am-12:30 pm # AWESOME
    Add some dialogue using the Guy dialogue sprite. # DONE
        Import the sprite. # DONE
            Fix flipped xy in sprite values # DONE
            Make a better mouth-bubble # DONE
        Test my DSL again. # DONE
        Add RunConversation again. # DONE
    Render the drone. # DONE
    Tune Demon for size/balance. # DONE
    Create a sprite for the health reclaimer. # DONE
5th:
    Purchased Cobalt VSTi and Poser 8.
    Rocks BG Render # DONE
        Rocks added to scene # DONE
        Fixed some scene export issues # DONE
    Additional polish on the dialogue # DONE
    Create a pickup like the DSD1 bomb, that attaches and releases on death # DONE
        Basic pickup entity # DONE
        Pickup attaches to drone # DONE
    Automated a pipeline step in adding art, saving some legwork.
6th:
    Create turrets (placeholder graphics) # DONE
    Flip use of "shoot" and "menu" in dialogue to avoid accidental shooting # DONE
    Tutorialize with Guy dialogue # DONE
    Release

Didn't get to the 5 minutes of gameplay or drone gameplay goal, but I made a ton of refinements. Here's the comparison of the "painted" and "linework" looks I tried:
I kind of liked the "painted" look - but it was making me spend forever on endless refinements, so I stopped and went for a simple "draw high res and flat and fill." Not quite as good as the vectors, but also easy to make consistent.

[medieval]

i dig the hands

[george]

hey, I tried out the 12/6 build! I'm digging the visuals, however I think the non-passable areas could be somehow better delineated or contrasted with the passable area, sometimes it felt like the ship just stopped but it really was colliding with a boulder or something.

Also it felt a little slow -- not sure what the FPS was (is there a counter?), admittedly my laptop is not that fast.

The diving/rising animation seems a little strange, is that what subs do when they move up and down? It looks like the sub is tilting?

[Triplefox]

george: Excellent points which I really should address.

Passability issues are coming from a mismatch between the tiles and shapes. I can't make the tiles any different, but I could pretty easily make more rectangular-looking rocks - so I'll do that.

I can provide an FPS counter. Also, I've been releasing builds in debug mode, which are considerably slower. I don't expect performance to drop much more below the 12/6 build, since I will be using the level design to limit what is spawned at any time.

Diving and rising is a playability/believability issue; subs don't look like that in the first place, and they don't move that quickly. I wanted some animation to make it feel more lively though, so I had them do side-to-side rolls for vertical movement. I could try reducing the tilt and making it a "up/down" rather than "roll" movement. I had them viewed side-on at one time but this made ships look similar and boring.

[Triplefox]

December 13th

6th (Post-release):
    Worked on music
7th:
    Create a logo # DONE
        Integrate logo into title # DONE
        Researched ways to spruce up title (didn't like the results)
    Add invincibility cheat # DONE
    2nd pass drone model # DONE (cheated, I had another candidate model that I swapped in)
    Drone perma-death # DONE
        Recovery stations to get new drone (placeholder graphics) # DONE
    First sound effects # DONE
        Found/created # DONE
        Loaded # DONE
        Integrated # DONE
        Overlap limiting # DONE
        Music integration # DONE
        Music looping # DONE
    Research explosions # DONE, will struggle with Blender particles to find something workable
8th:
    Door model
        Modelled # DONE
    Turret model
        Modelled # DONE
    Positional audio # DONE
    Dialogue sounds # DONE
    Menu sounds # DONE
    Shoot/hit/miss sounds player->enemies # DONE
    Render one explosion # DONE
9th:
    Implement and test waypoint paths # DONE
    Better miss sound effect # DONE
    Hurt sound effect # DONE
    Iterate explosion # DONE
    Do debug/release mode properly # DONE
    Door model
        Materials # DONE
        Render # DONE
        Integrated # DONE
    Turret model # DONE
        Materials # DONE
        Render # DONE
        Integrated # DONE
    The new turret revealed a real need for rectangular rocks (the 90 degree angles don't visually align well with the existing rocks)
    Cleaned up transparency issues on background rocks.
    Rectangular rocks - these new rocks look brighter, I'm using glare filters on them(which is in keeping with most of the rendered objects)
        Rendered 4 square rocks # DONE
    Tested tilting looks again; strong rotation feels disconcerting, much more so than the old roll motion did.
10th:
    Iterate tilting - very light roll is now used for the manta, other ships will wait as I form new opinions
    FPS counter # DONE
    A bit of extra polish on the dialogue sound/timing # DONE
    "K" model # DONE
    "K" render # DONE
    "K"-stand
        First costuming iteration # DONE
    Rectangular rocks
        Render larger-sized rocks, irregular rocks # DONE
        Integrate # DONE
            Rearrange level # DONE
    Question raised: Should the player ship have different environment and combat collisions? Visually pleasant environment collision makes combat a bit on the unforgiving side. I'm leaning towards a smaller player hitbox.
    Started making e1m1. Wheeeee, the game is getting some draft-quality gameplay!!!!!
    Researched preloader tech
11th:
    Basic preloader integration # DONE
    Add a visual "entry" point for e1m1 # DONE
    Went on a wild goose chase looking for "corrupt" images where none were to be found(real problem was with some image crop/resize code in the tool); resolved to start using TGA or TIFF as the future source image format(after this game ships) because it simpifies the whole pipeline over trying to preserve 8-bit PNGs the whole way(most libraries can't handle PNG8 right. sad...)
    Add placeholder switch, weapons-cache and recoverystation art
        Drawn # DONE
    Fix bgrocks repetition # DONE
    Make rock rendering not have white dot artifacts # DONE
        This turns out to be an artifacting error found in both pngnq and pngquant, which is inherited from artifacts in rendering that normally disappear in the alpha channel. Fixed with new renders.
    e1m1 environment filled in # DONE
12th:
    Prettied up preloader a little # DONE
    Fix artifacts on "wide" rocks too # DONE
    Weapons-cache as pickup type # DONE
    Implement Switch entity # DONE
    Add placeholder switch, weapons-cache and recoverystation art # DONE
        Art Integrated # DONE
    e1m1 entities
        Item collection/gating events # DONE
        Win-scene event # DONE
        1st pass enemy patterns # DONE
            Simple movement choreographers # DONE
            Circle+fire horizontal choreographer # DONE
        1st pass enemy layout # DONE
            Ships # DONE
            Mines # DONE
            Turrets # DONE
    Disallowed multiple triggers of a choreographer, it seems to cause mystery bugs
13th:
    Store settings # DONE
        In SharedObject # DONE
        In GamerSafe # DEFERRED
    Tutorialize/contextualize e1m1 a bit # DONE with placeholder intro text
    Release
    Second "K" costume
        Research women's fashion # DONE
            Peacoat, slim leggings, rain boots
        Sketch it
    Make "S" model
    Create an "S" costume

It's really looking like a game now. Plenty of placeholders, plenty of things to tune and balance still, and the scene looks really sparse, but it's a good starting point and performance seems OK even after filling out the entities. I've been messing with the music a ton since the first MP3 I made. Not quite happy with it, dunno if my usual funky synthy style is the right one here.

[Triplefox]

December 15

OK, I've reached my breaking point just fiddling with the sprite assets, time to magically make the graphics way better via the power of lighting effects:



They aren't real-time at all, just added on top of the static background, and I still have to add tool support for them(won't be hard), but it's still definitely one of "those" moments. I can make them colored, use different blending modes and stuff too, or apply filters over the whole scene - that's all coming from Flash. There are lots of things to play with still, both in the lighting tech and the art assets, but I think I can relax a little - the tone of the game's art is close to where I want it now and it's all details and small refinements from here.

I am also going to add some procedurally generated metal/tech scenery elements. Those will probably take some iteration, but far less so than it would to manually build and place a gazillion little bits of piping and panelling   Waaaaay back, months and months ago, I tested procedural techniques to do the rocks and it wasn't working out, which led me towards stamps, but the "non-organic" stuff should be a lot less tricky to generate, it'll look right being all straight angles and gradients.

For reference, the art processes and tech of this game, in total, will now include:

• 3D models, modelled in Wings, materials and animation in Blender. I don't even UV them, the sprites are small so all the detail can come from the model and some procedural textures.
• Poser 8 figures with poorly modelled custom heads bolted on, posed, rendered, and then painted over.
• Procedural lighting, procedural tile-texturing.
• Proportional bitmap font rendering
• Particle effects (which I really need to get started on)

And no, lighting was nowhere in my schedule. But I decided at 3 AM that I had to have it, and now, at 6:40 AM, I do. Such is how awesome things get added to games

(Gameplay seems to be taking kind of a backseat this week, but I will probably have at least one gameplay thingy done for the next build too!)

[MeshGearFox]

Hey, it's like Dr. Riptide! Neat!

[Triplefox]

I remember Dr. Riptide, vaguely. Haven't gone back and played it but I probably should