I got two of these $7.99 beauties:
http://www.amazon.com/gp/product/B000FJQ1VS/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=B000ECD4G6&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1FB63MF0665VHVFGTV2F

You have to ask yourself: "Do I really need more?"

Your best shot for info online is to look for "Flex" or even "haXe" tutorials. The terms "Flash" and "Actionscript" have become burdened with a lot of low-quality and outdated info. Both Flex and haXe have attracted stronger programming ability in contrast so they're less noisy.

Curiosity got the better of me so I decompiled the game to answer our questions. There is no win condition. I counted(by hand) 67 gems and 17 items. I suspect that a perfect game is either impossible or close to impossible, though if it were done tool-assisted, who knows?

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.

http://news.ycombinator.com
Mix of "startup news" and "hacker news."

[Version 0.91]

Version 0.91
Some bugfixes, including a large one where renaming layers was not working correctly(type error).

It makes sense that this could be put together in 10 months, since a lot of the movie assets could be re-purposed to work in a 2d game. And because it's the same guy doing both the movie and the game there's no communication overhead, no ramp-up, so it's a huge time savings on art.

Also, anthro characters are generally pretty awesome if you use them in context(furry stuff basically ignores the context, making it tasteless at best). They're an abstraction that lets you include the intellectual aspects of humanity while exaggerating emotion and abilities to capture the essence of other creatures. Plus they fit well into toon-style drawing.

A comment on the general architecture here: checking to see if tiles should draw by using collision rectangles and then updating the tiles piecewise is quite inefficient. It's based on the assumption that the map will change arbitrarily and the tiles have to "catch up" to the updates by polling the map later. You have to include all this extra state management for the collision, plus running the intersection tests, etc. It's a pretty expensive operation all around and gains nothing, since in the end it's still a tilemap on a fixed grid.

Instead, formalize the map access into a set of functions and build synchronization mechanisms into those functions. There are only two drawing cases to cover: drawing all tiles, and drawing them one at a time. When the map changes, you redraw immediately. It's that simple.

As for the broken updating code, I think I've figured the gist of it out - it's trying to account for oversized tiles, and that gets tricky because you have to make sure that when you shrink your pixel rectangle down to the tiles, you're getting the correct number of tiles to redraw. If the sprite is always growing evenly, then the size of the rectangle of redrawn tiles should always be an odd number on both sides.

When I print out the start and end values, after applying the / (self.tiley * self.scale) fix (and the same fix to tilex), I get this conspicuous result:

Code:

start 2 end 0

Which in turn pointed me to this major flaw:

Code:

        for eachrow in self.map[start:end]:
...
                for i in eachrow[int(start_tile[0]):int(bottomright[0])/(self.tilex * self.scale)]:

What you appear to have said is that every row of the map also contains every column of the map - otherwise you wouldn't be doing two consecutive slice operations. Unless you've done something very strange with how the map is made, this could never work correctly. What you want in place of the second slice is something like "if column>=tiletop and column<=tilebottom". Even better would be to start from the top-left and bottom-right pixel values, translate those to rows/columns, and then create a list of the cells you plan to change based on the two points, since they describe the local max/min. Actually what you're doing is fine, creating a list would only be useful if you iterated over it several times.
 
I would suggest factoring out the map access code into a set of functions or a wrapping class with pix_to_tile, tile_to_pix etc., and writing some tests for them, so that when you go to the full algorithm you're less likely to get mixed up. It really pays to start an algorithm from the smallest and simplest concepts, test and polish those up thoroughly, make sure they work with strange input data, and then add the additional complexity after. Anything less is asking for mystery bugs - though that doesn't stop any programmer, including myself, from trying to skip steps

edit: I was sleepy last night and came up with something incorrect.

I think the broader question here - not exactly the OP's question, but a similar one - is "how much do you want to define things in the tool vs. the game code?" It's easy enough to write a tool that only lets you edit a small, fixed set of properties for everything - a tile-based game, for example, where background art and entity spawns are both defined by unique tile values on the same grid. Such a format is simple to edit even with a hexeditor.

At the opposite end of the scale, you operate on what is effectively an exact instance of the playable scene on its first frame, with every property available for editing via runtime reflection. Doing it all in-game means that results - for the actions you write tools for - are fast, but if the data structures are complex you will quickly find yourself writing a lot of additional UI code to tune all properties, and you have to design the runtime representation so that everything is read/write, rather than read-only, which gives you the bonus of an extremely granular save/load system during play, but also leads to a raft of additional complexity.

In picking a point on this spectrum, you make tradeoffs on performance, design iteration and coding time.

I've moved towards a external model where entity definitions start from some form of property list. The tool holds everything in JSON and creates tool-specific representations by looking for magic-named properties. Then, at runtime, the archetype is spawned by bolting new runtime data on top of the original property list. There's no translation in my case because the language is dynamically typed, so the original JSON data maps 1:1 to fields of an anonymous object. It's a very simple and stable way to add diverse data, which for me is ultimately more important than sheer iteration time.

Nobody ever gets hired as a 'game designer' right out of college.

*raises hand*

Same. I made a small pile of games in college and got hired about three months after leaving, which isn't "right out," but damn close, considering that I didn't start looking until I was finished.

If you do what I did, you'll go to college focused on acquiring broad knowledge, which will put you in conflict with the entire incentive structure of college(which is towards getting a specialized degree). "Game college" courses are pretty much always specifically about programming or art, which is not the same as design. You want interdisciplinary relationships in design.

Despite that, it is possible to graduate and make games at the same time, but you'll get stressed for time and you may have to take a lighter/longer-term courseload. I started off thinking I would go for CS, and shifted to economics in the middle when I found that I was completely unmotivated for math and hence failed integral calculus multiple times. I stayed for one extra quarter, in the end. It was all worthwhile, I think, though suffering was had at various points.

DavidLeverton: Greetings. Post in the introduction thread too or you'll be pestered about it forever.

[-=>>PLAYABLE BUILD HERE<<=-]

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.

I knocked off the 5000m achievement on Kong Fun game, has a little more depth than you'd expect given how simple it seems. If the level layout were hand-designed it could probably go quite a bit deeper though...

However, he himself manages to prove, with that game, that you can't really make a polished game within 5-8 hours

I think the operative word here is "polish." You can knock up the "buildings are generated and the guy jumps from one to next running into crates and stuff" concept in an hour or two. But then:

-Animated character
-Sound effects
-Different building types
-Different building art
-Background art and animation
-Title screen and restart game UI
-Particle effects
-Tuning/balance
-API integration
-Complete platformer collision, vs. pure "touch the wall and you're dead." I think Flixel provides this, but the point is that the latter is the minimum necessary for gameplay, and the former is what the game actually has.

At various points along this lengthy list of polish items, the game's quality goes up, but it's hard to say exactly where and when.

Doing game-making full-time, I can say that the main thing that changes is that you don't worry about any schedule but the game schedule anymore, which is good stress-wise, and that's about it. I don't magically go from procrastinating to full productivity. Instead the periods of productivity just come and go in fits and starts: some days I only get 2-4 hours of "sitting down working" work done, other days I'm deep into it for almost the whole day, 10+ hours, and will usually force myself away, after finishing some big feature, to take a walk and recoup my thoughts. The single longest spurt I've had was probably a 72-hour stretch of time that was pure eat-sleep-code-think, and it wasn't motivated by a deadline, just a challenging problem. A lot of the time that isn't "sitting down working" time is learning or preparatory time, so what I'm really accomplishing is smoothing out the workload regardless of my performance on any given day. Somehow, doing this, I've been staying roughly on schedule without really worrying about the time I use.

When I had an industry job and had to be in at the office at certain times, a lot of that time was wasted either because there was a bottleneck elsewhere in the team, there were meetings I had to be in on, my workload was light enough that I had to spread it out, or I was exhausted from crunching and thus would get into a habit of frequent and lengthy breaks. The "8 hour workday" was more like 4 hours of real work when it came down to it. That part drove me crazy.

But if you have to define DEBUG yourself, isn't the same deal?
I mean, it doesn't solve the fact that you must change something besides the compiler command line.
Same problem.

No, you compile with -debug. It's a command line flag.

Well, I made it to the "+" but that one has me stumped. Can't go through it(unless there's some magic angle), can't go around it(tried offscreen even).

I've collected 14 items and 39 gems. I'm getting flashbacks to Pitfall... presumably there's a solution for collecting everything? Or was that asking for too much in 48 hours?

Hmm, wow. haXe has conditional #if #end blocks built-in to write platform-specific code, but any arbitrary phrase(like "debug") is also allowed. So this problem doesn't exist in haXe! Instead, we get "this feature is only supported in Flex" problems!

I got past the large egg and hit the [end of level]. Hells yeah

There are situations where you want markup that's very lightweight or parses faster than the alternatives, or you need one little extension.....

I made a reflection data language that mostly worked like JSON, but let you create references from any field to any other field regardless of position in the document, creating referential graphs of any size/complexity. Quite complicated to make, the parser was pretty crude.....and in the end I still haven't found a use for it, mainly because it was a load-only format. After the trouble I had reading those files, I wasn't about to write the code to save them too

I should work with YAML more. It looks a little bit bulky, but more appropriate for "pretty markup" than the alternatives.

Also, much <3 for binary formats. Fast and compact. Depending on how you make them, they can be human-readable with a hexeditor...

I worked for a shop that cut an awful lot of corners, and I rode along with it until the wheels came off a few months ago. Pay was cut, and it started to come months late by the end, but it did eventually come in. The reason why it was easy to stay on board in my case was because my workload became quite light(the bottlenecks were in the rest of the team - the most I could do was clear the way for them, which they respected) and I was still pulling enough money to gain some savings. My salary was low for the industry but definitely better than working retail or food service. Plus after getting laid off, unemployment benefits were sufficient funding for me to take on a bigger project.

I did learn a lot about taking on ambitious projects, cutting them down to size, learning the different roles in small-to-medium-sized teams, and developer/publisher/licensor relationships. That was all very valuable and has helped me tremendously to focus my own efforts.

In your case the main factor would be - are there grizzled vets around the shop that you can learn something from? Those are the guys that can give you a leg up, and you need only stay a few months, at most, to get most of the benefit from their presence. Other than that, there's nothing in it for you in this job, especially with such a poor wage.