|
Cedra posted:My main problem is figuring what goes inside those classes, mainly projectile. How would one go about setting up all those fancy bullet patterns, the timings of when a particular enemy appears and how they fly into the screen? Those fancy bullet patterns and enemy movements and timings have to be authored; you need to decide what you want to happen and either implement it in code or in some data-driven fashion. The most straightforward way of specifying when enemies should be created would be to check the time since the start of the level at the start of your game loop, and spawn enemies that should be spawned by that point. A slightly more general/flexible approach would be to have an ordered list of level events and times, and in the main loop run and remove from the list any events that should occur at a time <= current time. The level events can then be cutscenes, enemy creation, powerups, etc. The list of level events can be populated from your code, or from some kind of level definition file (XML, Lua, whatever). As an example of a data-driven approach, Kenta Cho created a markup language for bullet patterns, BulletML. It might be overkill for a first project depending on your experience, since from what I can tell there's no C# implementation and you'd have to write your own. Just browsing the docs might give you some ideas, though. Cedra posted:Anyway, I've been trying to achieve a consistent apex with no luck. It's been about 6 months since I looked at the code but from what I remember the apex sometimes differs due to the reliance on gametime as part of the velocity calculation. Also, the sprite doesn't quite have that snappyness of a classic Mario jump. The correct implementation of pos/vel/acc using Euler integration in a framerate-independent manner is: code:The acceleration here would include the acceleration due to gravity, but potentially also the acceleration due to wind, explosions, etc.
|
#
¿
Feb 26, 2008 13:33
|
|
|
|
| # ¿ Apr 27, 2024 16:23 |
|
|
Captain Pike posted:I have recently read an article which states that while UDP should be used for most messages (such as player movements) TCP should be used for very important messages, such as player-deaths. (UDP messages aren't 100% guaranteed. If a player gets killed, but never gets this message, he will still be wandering around the map) The important thing to note is that UDP does not guarantee the delivery of your packets, but there is lower space and time overhead per packet than for TCP. This makes it appropriate for things like updates in player position which can be interpolated and extrapolated so dropped packets will not be a problem (under sane conditions). TCP is quite different; it's stream-oriented rather than packet-oriented, so you have to frame your messages yourself. TCP guarantees that if you feed in a stream of bytes at one end, you get it back out again in the same order at the other end, unless the connection dies. You can implement your own acknowledgement and retransmission mechanism on top of UDP; for each connection between two endpoints, each endpoint should include a sequence number in the message header that increases each time a message is sent by that endpoint on that connection. Then the receiving endpoint can tell if it is missing any messages, and send some form of acknowledgement back. You can get arbitrarily clever with how you do this, although TCP essentially does the same thing and you don't have to worry about the details if you use it. If you want to use both UDP and TCP connections, you'll need a separate socket for each connection. Just set up one socket to each player for UDP and one to each player for TCP. quote:In addition, all of the low-level networking details are very confusing to me. (non-blocking sockets vs threads, ports, IPs, etc). TCP and UDP both work on top of IP (Internet Protocol). This uses unique addresses to identify endpoints on the network. TCP and UDP each then add a further level of addressing on each endpoint, called "ports". The combination of protocol (TCP or UDP), IP and port on one end, and IP and port on the other end uniquely identifies a connection. Ports are a way of addressing different applications on the same machine; if you didn't have them, either a machine could only have a single connection at a time, or all applications would receive the packet, and you'd need some way to distinguish whether the packet was intended for a certain application, and you'd basically reinvent ports or something equivalent but more heavyweight. In a server-client architecture, only the server needs to listen on fixed ports; when the client connects (TCP) or first sends a message (UDP) the server will know what ip:port that came from. quote:Questions: There are open-source game servers, but these are tied to a specific framework, engine or game. You could make a generic server that just routes messages to the various clients, but this won't be much use for many kinds of games; for an action game especially, the server needs to handle lots of the game logic. In terms of books, the only one I've seen that's half-decent is "Networked Virtual Environments: Design and Implementation", but I'm sure there are others. Several all-in-one game programming books have short sections on networked games. There are plenty of articles on gamedev.net and gamasutra.com, so I recommend having a poke around there.
|
|
#
¿
Mar 10, 2008 11:18
|
|
|
If you can make you game engine fully deterministic, and the game isn't too fast-paced, you only need to send player inputs; there was an article on Gamasutra in 2001 explaining how this was done in Age of Empires. http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php Otherwise, if you're sending the state of each object each tick, you'll want to consider interpolating between the current and latest received position for an object, and extrapolating from the last received into the future, so that a dropped packet doesn't cause objects to jump. And if this works well enough, you don't need to send an update for objects every frame; you could do it every few frames instead... When it comes to resolving collisions that affect gameplay, there are two approaches I've read about; in an FPS you would tend to do it all on the client so that when the player thinks they got a headshot, they score it; this is vulnerable to exploitation in various ways. The other approach is to handle the collision on the server, which introduces lag between a player's actions and a visible result and might look strange on the client. Will your game have a dedicated server? What sort of bandwidth is available and how many objects will need to be updated each frame?
|
|
#
¿
Mar 10, 2009 17:20
|
|
|
Some of the GDC 09 tutorials have slides up: http://www.gdconf.com/conference/tutorials.html There might be audio/video next week. The Insomniac slides on PS3 programming [1][2][3][4][5] are very interesting - very different from what I'm accustomed to. Unfortunately without audio/video some slides are a little hard to follow, although there is some overlap with the material they've released on their website: http://www.insomniacgames.com/tech/techpage.php I think it's awesome that they go into so much detail about their engine and implementation, and I wish more games companies did the same.
|
|
#
¿
Apr 9, 2009 22:41
|
|
|
I'm working extremely slowly on a little game idea that's intended to be like KSP's map/navigation view but with proper N-body simulation, so you can get into fun and weird orbits near Lagrange points, and use low-energy transfers and the Interplanetery Transport Network. It's going slowly partly because I'm using C++ and writing everything from scratch but that's half the fun of it. I'm using SFML for input, windowing and audio; I'm using some pretty dumb and naive OpenGL for rendering. Since a YOSPOS thread about NES game development got me in the mood, I modified my prototype to use a bitmap font and render to a smaller texture before upscaling. The resolution and palette used here match what a NES could do, but it's not tile-based so I'm not sure you could achieve this on a real NES. This is just messing around, the final game needs higher resolution because I want a much more crowded Low Earth Orbit, but I like the Elite-ish feel of these.  The red dots in the screenshots are the Lagrange points of the Earth-Moon system, but I've not actually managed to get into orbit near them, I am very bad at my own game and need to write some better orbit displays and other tools. Right now the simulation is N-body (N=2) but the orbits are rendered with patched conics ("patched" part not implemented) based on sphere of influence i.e. it switches to an orbit relative to the moon when you get near enough, which you can kinda see in the gallery below. http://imgur.com/a/oRUJr
|
|
#
¿
Jul 1, 2013 15:21
|
|
|
It's possible that valgrind is just so slow that it's hiding the rendering overhead. Your own code is being valground but the GPU is running as fast as ever. I usually use platform-specific timing calls to profile game code. I wrote a small timer class that wraps gettimeofday()/QueryPerformanceTimer() and then a scoped RAII thingy that prints nested timing results on shutdown. https://github.com/cswetenham/orbitalspace/blob/master/include/timer.h https://github.com/cswetenham/orbitalspace/blob/master/src/timer.cpp https://github.com/cswetenham/orbitalspace/blob/master/include/orProfile/perftimer.h https://github.com/cswetenham/orbitalspace/blob/master/src/orProfile/perftimer.cpp You have to call PerfTimer::StaticInit() at some point when you're starting up and then PerfTimer::StaticShutdown() when you're done and it'll print the results. code:There are probably also tools that let you actually profile what's going on on the GPU. All I know of is PIX for DirectX but I found a blog post that suggests some OpenGL profiling tools for AMD and NVidia on Linux: http://blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited
|
|
#
¿
Jul 2, 2013 13:10
|
|
|
|
| # ¿ Apr 27, 2024 16:23 |
|
|
I've played around with libRocket a little; it's an HTML/CSS based UI library designed for games. It pretty much does what it says on the tin; unfortunately I think I've found doing my layout with HTML and CSS pretty frustrating.
|
|
#
¿
Mar 26, 2014 13:12
|
|