• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

2443 Excellent

About Satharis

  • Rank
    Advanced Member
  1. HTML5

    Why would it not be possible? As long as you can get some kind of click event and a mouse position clicking something in a game is basically possible in any medium.
  2. Not sure what you'd be exposed to early on but in terms of practical math for games the most common things you'll use are vectors and trigonometry. After that, matrices are an obvious one but if you're say, using a game engine, the matrix math is often hidden in the background. Vectors are used pretty consistently for game logic though, and anything related to interacting with them. Basically linear algebra at a minimum, calculus is more specialized.
  3. Honestly if your goal is to make games and not engines, you should be using an engine, not pure API's. It can take months to figure out D3D by itself, whereas something like Unity can have full 3d objects rolling around a level in minutes. Plus you have to write all the connecting game engine code.
  4. Why do you need to fit an entire building inside the rendering box? Surely parts of it could be visible at different points in time?
  5.   I wrote that, because that is the only way it would draw the graphics on the screen. I'm sure there's a better way to do it, but it was a simple solution. I'm actually looking at other code, similar to what I wanna do and I can see what I was doing wrong, so I am working on fixing that.   What you're doing here is equivalent to  having a thousand customer records and you copy john doe's record over all of them. Typical programmer steps would be to verify that each part of the code is working with your debugger. Is the container actually filled with the right things? Are you iterating over it correctly? Is the information pulled from the container actually being used correctly by your later code?
  6. Keep in mind nothing in networking is going to be "real time" really. You're basically sending and receiving packages through the mail and are responsible for making sure you send and receive all the pieces and also handle all the code related to waiting for them. As an example if your server is sending a file to a client then the client is going to have to communicate with the server so that both parties know they are in the state of about to transfer a file, then you'd have to client sit there and wait(a specified maximum amount of time usually) for the pieces of the file to be received. Usually you'll want to code with the mindset of worst case scenario. You might get a really tiny file in 10k pieces, it might take multiple seconds to transfer, the other end could disconnect partway through sending. Network code is very error prone without a lot of safeguards simply because there are so many things that can go wrong.
  7. Helps to think of game time as virtual time, you want to collect the game time that has elapsed and then periodically move things and update the game based on what kind of action would happen over that period of time. Use a while loop instead of a for loop, if rendering is slowing down your code a lot then it may be the case that you could say, have 10 game updates worth of time elapse between each rendering call. Also I say game time but that's a bit of generic term since time could be used for many things. Imagine you have a game that runs in accelerated time, you can click buttons to make everyone run around the screen super fast. Well you'd still have to make them move and react based on real time, so they don't say do 10k actions in half a second when they should have done 200. Basically you're converting from real delta time to game time. If you think even more that game time may be occurring in a window that has a GUI, that gui may have buttons and things that need to react to time and input, but you probably don't want them to change speed with the game. If you think about it that way, your basic goal is to determine how much real time has passed and then use that to affect game events as you need it to.
  8. It's a pointless metric because it doesn't really give any useful information about performance. It's like trying to compare cars by comparing the RPM their engines spin at, one might sound like it is better and yet be a much less useful car because of other bottlenecks or design problems.
  9. In my opinion most of the hardest code really comes from having to do low level things. Now making a complete game of any size is pretty hard, but believe it or not it can often take more knowledge of things like algorithms and type behavior to write a game like snake or tetris than it does to make a small rpg with a drag and drop system. Things like collisions, physics, dealing with time, rendering, are all quite complex if you get down to them. So anything like an engine that abstracts this away will make it ridiculously easier. You can throw together a 3d ball rolling around a physics world and hitting exploding barrels in about 30 minutes in Unity, you can spend many hours writing the code for snake just having to sit there and write all the code to manage the data and make sure it works under all circumstances. Stick to a game engine with an editing suite like unity or unreal, or something like RPG maker or game maker. I wouldn't really get into code unless you have serious plans to be a programmer. Sometimes I feel like an idiot with how hard certain programming problems really seem to be because there is a million ways to do the same thing.
  10. To me it seems an odd strategy to want to make a game that requires a moderately powerful gaming computer, does not use the video card, and also is web based. These three things are all at odds with each other. Usually web games benefit from having low graphical requirements, runescape kinda pioneered that point, they got far more players than most desktop client based games simply because it was so easy to run. Not to mention if you require such a powerful computer then its a little nonsensible to not be using the video card to full potential, in fact I'd say people with gaming computers tend to gravitate towards desktop style games like stuff available on steam a lot more than they would web based games. Sort of alienating your own audience. Also not to be rude but I'm rather skeptical you even have the ability to make such a product based on how unsure you seem of each of your own requirements or even if they're the best way to do things. If I see people post 10k game ideas on here a year I doubt more than two of them even get past the prototype stage usually.
  11. Normally a server creates a socket you can think of as a listening socket, assuming we're talking TCP they then can connect to the socket. Connecting sets them in a sort of "waiting" state until you accept the connection through the listening socket. When you accept it, it gives you a socket that is connected to the client, you can then send and receive through that socket. Setting up the listening socket usually means creating the socket(some basic information about the protocol it uses) then binding it (setting it to work on a certain port) and then setting it to listen(setting it to wait for connections and hold them.) Not sure how Java abstracts that away but that's how the socket libraries work at the bottom level.
  12. Keep in mind if the port is in use or something like that then the code should break when you try to set up the socket. BSD sockets and winsock will give an error when you try to bind it to a port that is in use. So if everything works then you can assume that the socket is fine and that the connecting part is the problem. Firewalls are generally the culprit if you can't connect. The two obvious ones are your router firewall(forward the port) and your local firewall(add a port exception.) Usually connecting to localhost should work without much issue though. I couldn't say if mobile might have any OS related issues for blocking connections though.
  13. My first thought is: the code is kind of hard to follow. I don't remember much Python but one thing I quickly noticed with your game is that you basically have a giant switch statement for fights and set the "enemy stats" manually for each switch. Although this works it is rather redundant and hard to follow. An alternative you could do is use classes and make an object for each enemy(either set in code or from a file) and then have much shorter/simpler code for the fight part, since you wouldn't have that massive blob of stat setting repeated over and over again. Another suggestion would be to split up the combat function more, usually more functions is easier to follow than less because function naming helps to separate out what each section of the code is doing, that can be useful even if the code isn't repeated. You could also look into using multiple files, if I remember right python lets you import functions from different files so everything isn't in one giant blob of a file. But it's not bad.
  14. Unity

    I'm surprised you make it sound like every game is coupled to the graphics. While that often does happen in AAA development because of time constraints there isn't really any 'good' reason to couple graphics and game logic. Usually it just happens because people throw things together and it started off separated anyway.   Most code that isn't written in a rush like that generally IS decoupled from the rendering because often the game needs to support different variants of rendering anyway, so it ends up using a lot of interface code. Probably the best example I can think of this is dwarf fortress, which more or less runs the simulation by itself and everyone has developed different "visualizers" for the game.
  15. Every game needs a concept of time. Old arcade games had the hardware update at a certain real world rate so they just moved things to equal the desired real world elapsed time. Then we moved to using timers to determine the passage of time between points. Game time is just a virtual construct, you should be thinking about everything in real world time.   How you approach the problem depends a lot on specifics. For instance think of the old sim city games, they had ways to let you pass time but when time was ran at an accelerated rate all of the wandering visual characters onscreen would generally move at the same rate. Clearly the update time for the game was decoupled from the in game world time.   On the other hand a game like the sims couples them together completely, when you speed up time the characters all move, think and interact in half the time it would normally take them, or less. Your game loop is still updating at conceivably the same rate, so how are they moving?   One simple way to do it is to consider the fact than you may have 100 ms or something pass between game update loops but the code for say, simulating a unit moving across the screen may only run for 0.01 ms. You could technically then run it dozens of times while taking very little real time and they would appear to be moving at an accelerated rate. So then it stands to reason that some of your game code should be multiplied based on the game time scale and some of it should not. You may want the units to move quickly when the time is sped up but you may not want the ui to start doing things 2-3x as fast. Which leads me to my point that it kind of depends on what requirements you have for things moving at accelerated time. For a general case you would maintain some kind of counter of what the current "game time ticks" are. Maybe we start the game clock at 0 and every single digit increase of the clock represents a second of game world time. Now maybe you want one second of game world time to equal 100 ms of real world time. All you have to do then is accumulate real world time into a counter and then "consume" it and translate it to game time. I.e. if 314 ms have passed you can do a little math to now have 3 seconds of in game time elapsed and 14 ms left over. However you might notice in this scenario that you are technically "in between" game seconds. On the bright side something like this is easy to multiply, if you want to run the game at double speed you just multiply the time.   Since we have game time as a simple value it is then easy to have in game events happen after a certain amount of game time has elapsed instead of real world time. However you have to make sure you update things that depend on each in "blocks." If you had a platformer game and could speed up time you would want the hero to run into spikes and die twice as fast if the game was running at double speed, you wouldn't want them to take a double distance step and appear in the middle of our spike block and THEN suddenly get hit twice by the spike block and die instantly. You can see the difference between the two would be that in one case each event is ran multiple times by themselves as opposed to all events being run together in a loop that happens twice.