|
Hello world doesn't motivate any further subjects, which is what a learner should aim for. It's a "hay guys the compiler works." My suggestion, which is very non-specific and expects you to do your own research, is to practice towards general programming knowledge. That means, don't worry about tutorials for graphics and 3d and stuff yet, don't worry about performance or commercial applicability or anything. Just choose any well-documented language to learn with, and try stuff that you'd see in introductory college courses: loading and manipulating files, text input loops, implementing simple data structures(linked lists, queues, stacks), and then maybe a text-based game to round out everything you've learned. Once you've got the core background together, you can really go anywhere in programming. Game programming tutorials just implicitly assume that you already have it.
|
#
¿
Dec 4, 2007 00:29
|
|
|
|
| # ¿ May 2, 2024 19:54 |
|
|
Space Creeps I put this game up yesterday - my first commercial/indie effort. There was an earlier version up a few months ago but it wasn't really good enough at that point to get anywhere in the cutthroat-casual market that is Flash games. I think with the high scores and recording and various improvements I've made since then it might do a decent business. The recording function in particular is something I don't think any previous Flash game has done. Something a bit disconcerting is that most people don't seem to be finishing their games. 500 plays today and I've only got five scores up - and the server isn't broken, the log shows plenty of people connecting normally to get the game of the day. They just aren't following through by sending a finished recording. But I know from the first version that Flash gamers find the whole targeting thing too complicated - which is unfortunate given that it's also a big part of makes the game unique. Even so, I'll probably still do another revision with slicker graphics down the line. Most of the elements look OK, but it's really missing that cohesive, polished look. If I were to go all-out on it, I'd convert the game to 3d with Papervision or something  But it's hard to justify.
|
|
#
¿
Dec 8, 2007 07:04
|
|
|
It's a good critique. The game isn't really yet set up to forcefully baby the player through every single thing on the screen, and it needs to do that - there's no genre convention to go on for these particular mechanics. For example, this recording, where the player doesn't know how to rotate walls and places targets in the least useful spots, is downright painful to watch. Also, every map is random so there's no telling if you get an easy one or a hard one. I've considered doing a campaign mode which would serve that purpose. The main target is the competitive players, though, so I've focused on the higher level play and slowly drilled down from there. There's a tremendous metagame having to with whether you kill the creeps earlier(safer, and you can get the clean map bonus) or later(more to kill=more points). Tower usage, wall placement, etc. follows from how conservative your overall strategy is.
|
|
#
¿
Dec 9, 2007 10:32
|
|
|
Following up on my release and review of Space Creeps, I took a few notes and have a new set of plans for future versions: Replace puzzle pieces and rotation with only single-square walls. Puzzle pieces add little to the game as it stands - they are very annoying, add additional controls and rules, and block many strategies by random chance. The main restriction should have to do with the external foe, not what pieces you can place. Create a new interface engine; look at the gui system options available for haXe. The current interface is primitive and brittle in several ways. Convert and upgrade graphics to vectorized versions. Pixel art can be cool but for this kind of game, the detail of pixelling just clutters up an already busy screen. Add a short mini-campaign or video introduction to the game, in three or more parts: 1. Sealing walls. 2. Placing towers. 3. Upgrading towers. Strategy? Using the recording system for this would be awesome and would require three general extensions: 1. Support custom maps(and in that case....why not allow the players to make and upload maps, too? And then add more kinds of map elements?) 2. Extending the recording system to load data stored in the swf. This shouldn't be too hard. 3. Extending the recording system to allow commentary tags. It would be great if players could do this too, and it could be "modular" (one-per-person) commentary so that you aren't drowned in a flood of youtube-esque spam. The greatest thing about a web game is that it never "ships." Or it ships as many times as you want. Whichever view you prefer  ed: a missing
|
|
#
¿
Dec 10, 2007 09:29
|
|
|
drcru posted:What would be the best way to implement a fog of war? I'm thinking store the visited sectors onto a list and store that into a MySQL Text field and explode/implode them. Well, it depends on what you mean by best. You have several options for representing maps and at different points you may want to use them all: -List or 1d array of references to given locations, what you have. In this case probably the best because you're only returning a list of what you need to know, so you don't waste your processing power and bandwidth on the remainder. The list/array consideration has to do with how your data gets accessed and rewritten. -2d array of references. Not hugely different to the list, but semantically easier when working with known sizes of map. -Graphs where each location references other locations near it. This is a good way to search and navigate a map, but inflicts serious penalities when one tries to grab the entire graph at once. So not good for getting a fog of war or other "summary" data. -Other data structures? You can put caching and lower-resolution versions and other things on top of the others, but these are mainly used as optimizations. I don't know of other (sane) ways to represent tiled maps in games. And there's a basic decision underlying all of these - whether to dump all the data in each location into a single structured data type, or to parcel out some of the data into their own maps independent of the others, using primitive data types. In some cases you could see a speed boost from the many-maps/primitive-types approach, but it's much harder to maintain a unified structure that way, and the optimization comes mostly from reducing indirection(which has to be weighted against the cost of doing the same lookup amongst multiple maps). Ultimately it's an architectural decision to figure out the data representation(s) your game needs. There's no one right answer, and most games will use some kind of mixed approach, like an array of terrain and a list of units.
|
|
#
¿
Dec 20, 2007 10:41
|
|
|
take boat posted:I'm wrapping up a soul sucking year and a half long drain on my life, and am looking forward to using my new found time to maybe build a simple 2D sprite game (my first!). That's not quite enough information on what kind of speed you are looking for. Any of those can display hundreds of animated sprites at 30fps, and probably even 60 -- depending on screen resolution, bit-depth, and collision/AI complexity. I've used a lot of both Flash and Pygame. I used to be all about Pygame, now it's all Flash. Pygame is probably the slowest renderer because it doesn't have a fast scenegraph built-in like Flash, but if you add OpenGL to the mix it can get a lot faster. Flash on the other hand has a scenegraph that performs pretty well for straight-up bitmaps; the vectors and transformation effects can be looked at as additions to that. Perceptions of Flash slowness are almost entirely due to an overuse of vector rendering. There are also some great open source tools for Flash: I use and actively promote haXe where I can. I've never used Adobe's commercial tools on a project, though I know they have their benefits. Also, I would warn you away from a focus on rendering. Having hundreds of things on screen, while technically interesting, tends to make the game design converge on a uniform, repetitive gameplay where you have a cloud of stuff that is either moving too randomly or too predictably to be fun. The most you can use massive amounts of sprites for is in particle effects, unless you have a very specific design in mind that needs high quantity. What you should really worry about - if you are serious about making a game - is collision, state, and timing, in that order: those things constitute the core gameplay of most game genres. Answering problems like: How to make characters slide against walls instead of bouncing or stopping dead. Working out which frames of the player's attack anim cause an hit on the enemy, and how the enemy AI will perform its hitreact before returning to normal behavior. Transitioning from gameplay to an in-game cinematic, and back again, without completely breaking the gameplay. Those are the tough questions of game programming that have nothing to do with optimization. The other thing to consider, besides the gameplay, is the asset pipeline. It should be as easy and seamless as possible to add new content, if you are doing a content-heavy game. Fortunately with 2d these problems are mostly organizational. In 3d-land it's easy to end up with conversion processes that fail "some" of the time. For all those questions the language is mostly a matter of "which one will allow me to make the fewest errors?" If you can build off a game engine which answers some of the gnarly problems outlined above, life becomes much easier. (A lot of people make engines that do almost nothing to solve those problems, of course. Those engines are rendering, a pipeline, and a little bit of collision. Good enough for a demo, but a long way from a shippable game.)
|
|
#
¿
Sep 9, 2008 04:46
|
|
|
The way I did slopes(a way which is probably a sin against performance, if you're trying to do everything "as it was done back in the day") was to ignore terrain-specific stuff and instead run a speculative collision test where the character is moved a little bit higher on the vertical axis, ignoring physics, and then is subsequently swept horizontally. If that test works, but a test where they move horizontally without vertical movement fails, then I flip on the "slope-climbing" bit and let them move up vertically without falling in that frame. Then on the next frame they repeat the test and can now move a little bit horizontally...etc. It takes three different tests(horizontal only, vertical only, horizontal after vertical projection) but is very stable. With a little bit of tuning, this lets you climb any slopes your collision detection can support.
|
|
#
¿
Oct 21, 2008 02:40
|
|
|
Kleedrac posted:I'll probably spend far more time on balance issues and tweaking the XP curve and other aspects of monsters, bosses, and player classes (yet another reason that needs to be its own class with inheritance for each and a tool to allow easy editing of the file format which will store it.) Again thank-you for your help, I hope this clears up my intent. No. Unless you're making an uber-competitive multiplayer game like Starcraft where the balance is so essential it needs statistical analysis -- it will take at most a few weeks of work to tune and balance preexisting gameplay mechanics. It takes months to years to implement said mechanics, pump out content and scripting, and get the presentation and polish down pat. Basically, the tuning happens in between doing other things. If you really want to focus on gameplay immediately, slap together a battle system prototype. Aim to do it in about a day; for an RPG, not hard since no graphics are needed, just model the relationships between different variables and stick a command-line interface on top. Cut all unnecessary features to hit the deadline. Your goal is simply to prove your gameplay, eliminate unknowns in the design, and identify the features are important to iterate on, and the ones that are useless to implement. Do this, and you won't waste your loving time writing out pretty, non-functional classes with what appears to be a misguided worship of OO inheritance hierarchies(which most commercial developers have long since moved away from because a God Object results from using inheritance to define all gameplay entities). The best code is no code and the best tool is someone else's. The exception is if you are interested in researching game technology. In that case, by all means try something outrageous. Also, if you studied Extreme Programming, you'd know that what you are doing right now isn't it. Planning far ahead and dividing up work as if it were an assembly line is a classic waterfall pattern. As for your OP questions about tools, file formats and engine stuff: What you're looking for is the pipeline. It is ultimately up to you to decided how assets are created and imported into your game, what the user-facing interface is like, and how the game engine will save and restore data. Using Python, you have a plethora of code available to base your own work off of. For a custom binary file format, you can just serialize everything using the built-in pickle library. For formats you want to edit with a text editor you can choose between XML, JSON, YAML, and miscellaneous others. If you have data with a lot of relationships that can be aggregated in multiple ways, you might want to use a SQLite database. You can implement loaders for existing engine formats, or formats for generic editing tools like Mappy and Tile Studio. No matter which you choose you still have to write some boilerplate to relate the external format (data order, tagging, etc.) to the internal one your game will use.
|
|
#
¿
Nov 14, 2008 07:08
|
|
|
Morpheus posted:Is there anywhere to see coding design documents that go over stuff like that image? The only trouble I have is with the higher-level design: what objects know about other objects, how are things connected, etc. This is the first time I've worked with animation stuff, so stuff like damage hitboxes, state-based animation, and all that stuff is totally alien to me. I don't know about design documents, but here's a general template for what I've seen(and implemented) in working engines: - Characters are spawned with all their collision, and it's disabled as needed. (This is generally done for simplicity of memory management) - Characters have one (or more!) finite state machines. There are a wide variety of formalized finite state machine implementations, and variations on the FSM concept, but using them isn't required. One can also opt to wrangle some ad-hoc logic together. The state machine can drive as many or few things as desired; completely unreactive, immobile scenery won't need any state, while moving objects probably want some kind of physics state(ex. air vs. ground) and characters that engage in combat will contain some state for attack/hitreact/knockback/knockdown/death/etc. which manipulates positioning, anims and collision as needed; AI behaviors can also be handled with state machines. This is an area of game programming that nobody's very happy with, as a large number of states becomes extremely complex and hard to debug very quickly. If the logic feels overwhelming, write out flowcharts. If the flowcharts aren't enough, write out decision tables. - Animation and state machines can cooperate and override each other; one can specify an animation format where at given frames of the anim a state-changing event is fired, and collision is turned on or off or moved. Similarly, a state machine will probably want to interrupt anims for things like player inputs or combat/environment damage. - Scripting languages can act as a layer on top of all of the above, providing an additional pathway for logic without tinkering with an existing state machine. The details of how characters interact with each other and how events are fired are specific to the game design; thus no one engine has a complete solution, just solutions that are good enough for the problem domain. A typical event one would write is something like "body collision triggers a hitreact on its parent when it intersects attack collision." This event describes your typical "you swing the sword and your opponent gets hurt" situation. As needed you can differentiate your collision's data more and more finely to resolve things like different types of weapons and armor, environmental effects vs melee vs ranged, etc. There are also shortcuts that can be done in the design. Doing something like having the game loop drain health from characters with every frame that they're in damage collision lets you eschew hitreact states entirely, and reducing enemy AI to "move towards the player" means you won't need behavior states, but the resulting gameplay of these shortcuts is probably unacceptable to modern audiences.
|
|
#
¿
Nov 17, 2008 10:20
|
|
|
Re: the python/psyco/pypy discussion I think it is worth pointing out (bragging) that haXe has a C++ target in testing now: http://gamehaxe.com/2008/10/28/c-backend-for-haxe/ and http://gamehaxe.com/2008/11/10/hxcpp-02-huge-performance-increase/ If that gets more stable and optimized, it'll be feasible to write number-crunch-heavy software in haXe. I used Python for a very long time but have switched over to this in the last year - nice language, the multiplatformness rules, and it's much, much more promising than PyPy if you're looking for speed. The main downside is that library support is limited and probably will continue to be for years to come.
|
|
#
¿
Nov 30, 2008 05:51
|
|
|
The way a simple roguelike would implement the feature is to add on top of the movement something likecode:If your world were instead, for example, a 2d array of lists, you would instantly know how many and which things exist in the point you're looking at, because you would look up the point in the array and then iterate over the list inside that point. The tradeoff is that then it's harder to say "this is how many monsters are in the world" without iterating over the entire world(slow) or maintaining an additional list for monsters(additional state to maintain, potential source of complexity/bugs), and it's also harder to do movement because you're shuffling your monster around from one list to another instead of just incrementing coordinates. Once you get beyond a few kinds of things in the world it helps if you shift to a composition-oriented system, where actors are collections of component objects that each implement a little slice of functionality(collision, visualization, ai, etc.) as it lets you reuse more and specialize only where it's necessary.
|
|
#
¿
Mar 14, 2009 10:21
|
|
|
terminatusx posted:The tutorials made by Metanet (the guys behind the game "N") were extremely helpful when I was trying to implement collision for my 2D game, and can most likely be useful for any kind of collision detection in 2D games. They talk about stuff like implementing broad and narrow phase collision, Separate Axis Theorem for AABB objects and Circles, and all that stuff that I now pretend to understand. Those tutorials are really useful for getting some of the concepts together and making basic, non-sucky collision. They don't really last once you try to do something different from N, though. Doing a SAT-based response on two AABBs of differing sizes, for example, is considerably trickier than AA-squares of equal size. Particularly, situations like this: code:With that in mind, I've simplified to a slightly less ambitious goal with groups of fixed-size tiles: http://dl.getdropbox.com/u/254701/examplemultitile.swf This was relatively straightforward in comparison, as now the world collision stays strictly on the grid, and the player is a composition of equal-sized tiles that only need to check - at most - four world tiles each. So then the question is only about reconciling different pushout vectors to find the preferred one. I needed a few tries to get it, but the algorithm I resolve that particular part with is: 1. Apply a temporary velocity vector to each tile and collide using that. 2. Get the pushout vector returned from each tile in the group. 2a. If none of them return a pushout vector, there is no collision here and the original vector is safe to use. 2b. If one of them says they hit but can't find any pushout, you're running into a corner, so end the computation and return a zero vector. 3. Run the pushout again using each of the solutions. The first solution that doesn't hit anything is a good solution, so end there. If none of them work you're blocked, so return a zero vector. It seems to be pretty fast as-is; at least, it holds up when I try stacking hundreds of excess tiles on the player collision, but I don't have a really good test case yet.
|
|
#
¿
Apr 8, 2009 08:48
|
|
|
|
| # ¿ May 2, 2024 19:54 |
|
|
Avenging Dentist posted:What. Both of those are really, really easy. Rolling back in time alone gives you a fairly lovely collision response - no sliding behavior, your player sticks on the walls when moving at any diagonal - that you have to add hacks over to make work in gameplay. Hence I'm going back and looking for a more general solution.
|
|
#
¿
Apr 8, 2009 17:54
|
|