• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

CC Ricers

Members
  • Content count

    396
  • Joined

  • Last visited

Community Reputation

1491 Excellent

About CC Ricers

  • Rank
    Member
  1.   It was a RPG with voxel graphics. The problem with that is that I put the cart before the horse. I started working on the polygonal voxel engine first, when I should have really started coding the RPG stuff first.
  2.   Raytracing seems to close to what I was looking for. Because I have not done this before I did not know what to search. Now that I have done just a little bit of searching it seems that using raytracing in a video game is not a good choice unless everyone is using a server farm to play the game.   Now I'm getting into some opengl questions(yes and no are not what I'm looking for). I would like to know the api calls or a link to tutorial would be nice. 1. Can I map a png to a plain in opengl and still have transparency? 2. Can I map only a portion of a image to a plain?     You might actually be looking for ray marching. You can more easily test intersections with objects (such as your plane) and use a fisheye-like projection to curve the rays to produce the sphere effect. Then animating the plane movement is as basic as off-setting through the X and Z directions.
  3. In addition to what Hodgman said, Microsoft provides documentation for the .xnb format and a parser for it which is written in native C++. This parser outputs information about the original file data and format as it's encoded. This will let you load .xnb's in a non-XNA environment. The MonoGame team probably used this to write the pipeline code for their own framework.
  4. My hobby programming plate was kind of full at one moment. In addition to the game idea I have for Project SeedWorld, I have started working on a Pong-based game for Mini LD 58, and I also have my open-source Bummerman game. Though not a serious project, I plan to hold on to it to learn multiplayer networking code. Mini LD is already over, so I can go back to work "full-time" on the voxel game. I already have it working in a MonoGame project now. Putting all the Code Together Between this and other small games I have worked on in the past I have seen a familiar codebase develop over time and started to see what others mean about deferring your plans on building a game engine. Most recently with the voxel game, and even before then, making pet projects I haven't shown in public. Over time, I have developed a "Screen Element" system which works like Game State management, but there is no manager class, and I prefer to call them Game Screens or Screen Elements. With Bummerman, I also have a custom ECS framework that works for this particular game but I have copied the code over to start making the platformer. So I have two sets of code that I notice I can copy to other projects, in two separate folders. One is for the ECS and the other for Screen Elements. I can then start with a Game class that loads the first Screen Element for the game and in the main gameplay logic use ECS. Porting SeedWorld to MonoGame Today I have started work on taking the important voxel engine code and updating it to run with a game using the ECS and MonoGame. It's a success so far! Project SeedWorld can now go multi-platform. I am not using procedural noise functions this time around. This game will be made using custom tiles, which are represented as 16x16x16 chunks. Right now I am still using voxel streaming to load and unload chunks, but that may change soon as it's not completely necessary now. As before, it loops through all the possible chunk areas to see if any need updating. Tile information will be handled in the ECS framework. First, a Level object will read tile data, which is just a series of number IDs that point to voxel object files. A Tile component will store the tile position, tile ID and rotation. It will also be accompanied with a Collision component. I may not want voxel-perfect precision but instead have hit areas represented with simpler shapes. Finally By the way, MonoGame has one big annoyance: It has no built in SMAA support! You'll have fix it the hard way by adding this feature to the source, get around it with a post-process shader, or be more gutsy like I was and use a super-sampled render target at 2x the native resolution (in other words, 4k resolution!) If you compare it to the first screenshot, it actually did not drop the framerate much at all. This is at 3840x2160 dowsampled to 1920x1080, running on a GTX 750Ti. But it becomes more GPU bound when I started rendering a lot more chunks. This is because of the number of draw calls of one per chunk, just the way it was when using XNA. But I think this time I will combine several chunks into one mesh to reduce the draw calls. In the meantime, I will be working on a voxel tile loader so it can generate pre-made chunks from voxel sprites. It will basically be a tile editor but in 3D. I want to give the players the ability to customize and make their own maps with the game. Hopefully next time I will be able to show the process of making a map with the tile editor and show some of the game features with it.
  5. I use some fake directional-based ambient lighting. This is what it looks like in my voxel engine. The idea came from this article on image-based ambient lighting but I kept it more simple and instead am just using the six sides of a cube to gather lighting.   It's a simplified version of what Swiftcoder posted. The sides facing the skydome have different tints of color which change during the day/night cycle, as well as the intensity of the light bounce (how much they contribute to the final color). The sides facing the bottom are less saturated versions of the top colors. I only did this because the voxel lighting will block most of the light from the bottom sides anyways.
  6. The "premature optimization" quote is the quote which is most often misquoted and taken out of context, here. Making a high level architectural choice of where to put some data (in this case because the code gets simpler to write, when you wont discard the type information for components and there is no useless typechecking in the entity to make up for it), is a completely different thing than obfuscating a function to microoptimize it before you know it was needed (what the quote is about and in later sentences is relativating).     This is the main reason why I am storing components in an array. It's not so much for cache optimization, but to avoid type casting on every frame. At initialization each System gets the array of Components it needs to work on. They get cast to arrays of the derived Component classes which are stored in the System. When entities are processed I can access the properties of each Component without doing any casting.
  7. That's why I use a TilePosition component and ScreenPosition component.  A Tile system is responsible for finding the closest Tile position for a sprite's screen position. It also looks for any static sprites that have a Tile Position set at load time but not a Screen Position. The system sets the screen position for them according to their tile position. Additionally, you may also want the tile information to exist in an array or hash map if you want the fastest lookup times for handling collisions. If your level has tens of thousands of tiles it is a lot better to check collisions against moving entities by looking up tiles in a hash map or array, than to loop through the thousands of tiles for every entity that can collide.   I did what Phil_t does and put all components in an array, with their index indicating what entity they are a part of, and register at load time. Although I still tend to bitmask/null check at every frame, I eventually want to register very large quantities of similar Entities early. There really is no Entity structure defined in the code because they're implicitly defined by the array indices.
  8. If the GIFs need to be processed through a special pipeline with XNAGIF, you might want to double check that additional GIFs you add to the project have their correct content Importer and Processors set so they can work with the library. It might be causing the no animation issue with your other GIFs.
  9. I like it, especially the second pic. Looks very organic despite the hex tile layout.
  10. Unity

    On the flip side, one disadvantage of working from scratch, that I have seen personally, is making it harder to collaborate with local indie developers. I don't have any experience with Unity and prefer to use MonoGame. Unity has gained a lot of traction and it has been harder to find a developer that codes their games without the use of a major engine with a GUI such as Unity or Unreal.
  11. I played Rogue Squadron on the N64 but was impressed that it ran at a smooth 60fps on it (must have to do with the Expansion Pak). I prefer the more arcadey space games like that one, or Strike Suit Zero, over the deep simulations.   Space combat is something that looks pretty easy to approach on the surface. IMO designing cool spaceships are easier than designing good looking characters. But I echo what AFS is saying about art style. SSZ for example has some striking backgrounds all done with artistic liberties to be memorable to the player. In contrast, I hate the default skyboxes for Space Engineers. It's an interesting game mechanics wise but the gray-ish green backgrounds look blah.   I think one of the bigger challenges would be getting the controls tight. That makes all the difference for having a enjoyable game. XNA has a spaceship tutorial for example, but its controls felt too loosey goosey so you had to tweak variables in the ship and camera movement for it to feel much better.
  12.   Quoted for emphasis. This may sound like a subtle step, but the order of resolving collisions by the axis of minimum penetration makes a difference for better collision responses.   Here's a relevant article: http://www.geoffblair.com/blog/order-matters-tile-map-collision-response/   Now, this article presents other approaches to resolving axis of least separation, but for platform games they're not always necessary. I tend to just loop through the boxes/tiles that are colliding with the moving entity, no matter how they are ordered, and start resolving with the first one found in the loop. If penetration for X is shallower than Y, push away on the X axis.
  13. ncsu121978:   Currently I have gotten far enough in the network part of the code that the clients send two pieces of data: an input command state (encoded as a byte or possibly short), and the player number (byte). Nothing else about the game state is being sent.   The input command state is agnostic to whether the player uses a keyboard, joystick or some other input device. I send data only every time the command state changes from the previous frame.   The server applies the input commands to the appropriate player(s), and updates its own game. From here I don't know if the server should relay these same input commands to the other clients, or that it should send its updated game state. Sending the game state sounds better, since input commands are going to be delayed even more going to the other clients.   Rewinding to a previous game state to compensate for lag is something else I haven't yet tried for a client-server setup. Do you rewind everything, players, bombs, destroyed blocks, or do you just rewind the players' positions?   I have only tested multiple instances on one local machine, but so far the players in the server game move as they do in the clients. Client / Player 2 moves up, and Server / P1 sees P2 move up on his screen. They go to their same positions as they would, bombs placed are in the same places on all screens.   Even power-ups work as they should. Since the same player walks over the same powerup on all screens, on every instance of the game he is powered up and can place more/better bombs.   Validating the player positions sounds like a good idea, though. All players walk at the same fixed speed, so I guess the server can track the walking distance of all players in the last few seconds and if it's absurdly or even slightly higher than it should be for the time interval, it can assume that a player is cheating.   hplus0603:   In the long run I am thinking of hosting a master server online, a bit like Valve does for their source games but simpler. I don't expect to get a ton of traffic. I work as a web developer so I have knowledge building a dynamic website, using APIs to communicate with other machines, etc. Using online hosting to maintain a list of available game hosts.   I'm expecting that I could get my game to communicate to a web API and send relevant information about its IP, latency, etc. in certain intervals to let the master server know that the host is still "alive". The web server will check and validate the data and it does its own updating on a database. I won't use the program to directly edit the database, don't wanna pull another Super Meat Boy here.   But right now I am more focused on getting the network code working on local machines, before I can start testing with remote IPs. I just figure that deciding between client-server or P2P should be done early in the process of turning your game multiplayer, because it looks like it will impact everything on how I program the network code and how the game logic should be updated.
  14. I am making a Bomberman clone and have the game logic all set up, and now I'm ready to add in networked multiplayer.   This is my first time attempting network code for a game and have read about client-server setups, P2P setups and their main advantages and disadvantages.   It seems like some game genres are more convenient for certain network structures than others. For example, P2P is common in RTS games.   Well, I consider Bomberman to be like RTS of sorts, just greatly simplified in rules and player options. It has real-time action like a shooter or fighting game, but not as fast-paced (although I know Awesomenauts also uses P2P and that is an arena fighter). I am going to make it support up to 4 players and then after having that work, see if it scales well to 8 players.   Currently I have some test server and client setup in the game, using Lidgren. Just for sending string messages through each other and displaying them in their windows, nothing more. If I were to use P2P instead, I was planning on just sending player input states every time the input state has changed for that player. The input state is encoded in a bitmask which would help in sending data to a minimum.   Would P2P be better for this sort of game, or client-server? And am I correct in the kind of data I am going to send to the other players (or server), or should I send the players' own position and bomb data?   I know I still need to deal with input lag, and sending player data directly is more prone to user hacking, but I want to start with the basics first because I think that the network structure I choose will greatly impact how I will update the game logic.
  15. I have released my first open source game code to GitHub for my Bomberman clone, Bummerman. Here is the project link: Bummerman This game uses MonoGame 3.2 for the build, and the Lidgren network library. The solution is set up for a Windows/Windows 8 build- I'm not yet able to try to build it for Linux of Mac OS X. What started out as a small side project seems to be turning into a full-fledged game with many details. As you may know, it began with a custom ECS framework and then adding game logic to test it out with. Then I got interested in adding networked multiplayer. So I'm making this a longer term project and as a stepping stone to build other games from. Current features are, one power-up, support for keyboard and controller buttons/D-pad (no joystick input yet), up to 4 players, and rudimentary Game Screen states. I plan to finish this game with added polish, and more features. There is just enough to show the gameplay interaction and flow of game states. Upon starting the game, you are greeted with a message on the screen telling you to choose between hosting a game server or connecting to one as a client. After making your choice, the game starts and you can control your character. What's left to do The game is very much a work in progress so there are a lot of bugs and things missing from the game currently. I'm a noob to networking code here, and this is the first time I've tried it on a game. Networking is nothing more than a check to send test messages, as they have no impact on the gameplay whatsoever. But it works at least! There needs to be more power-ups, input controls can only handle one unique set of inputs per player, so there's still the issue of one set of inputs controlling all characters on the screen. I might need to add the ability to deep-copy components that have reference type variables. I didn't include sprite assets because I am using copyrighted sprites as placeholders currently. I will add free placeholders later. Next Mini Ludum Dare [s]is around the corner[/s] has just begun and I hope it is my first one to participate and try this codebase out for other things. Probably not the network code, though, since that is still very basic. The theme was just announced as "Pong" so it shouldn't be too hard to make something out of that. Feedback and comments are welcome. I hope this code could be of use to someone wanting to see yet another approach to coding a game.