Kylotan

Moderators
  • Content count

    14091
  • Joined

  • Last visited

  • Days Won

    45

Kylotan last won the day on November 16

Kylotan had the most liked content!

Community Reputation

10105 Excellent

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

Social

  • Steam
    kylotan
  1. I hope to see my game alive

    Marketing is by far the biggest factor in success vs. failure. Dumb luck is what makes the difference between the projects that don't do marketing.
  2. C# + AS3 + C++?

    Evolve to do what? If you're a beginner you shouldn't be making your own engine until you have spent some time learning how to use existing ones. Certainly you shouldn't base your implementation decisions on other people's job adverts because their existing technology is, as Frob said, the result of many years of different projects and different directions which they now have to maintain, not the ideal form that others should strive to emulate.
  3. C# + AS3 + C++?

    Scaleform is/was a standard UI tool for games, and it uses Flash/Actionscript. I don't see them mentioning C# there. But even if they did use C#, it's not a big deal. An experienced programmer is expected to know multiple languages and adapt to new ones as needed.
  4. What do people look for in a music "pack"?

    I experimented with selling music for Unity, and honestly, I don't think users are looking for music packs, generally. There are more than enough people offering free music, few Unity developers make it far enough through development to care about music, and anyone likely to actually ship something usually wants custom music anyway.
  5. Sound Design heavy music in games

    Obviously there are going to be artistic sacrifices in trying to match audio to visuals in cutscenes. That's just the nature of things. You'd do what you can to get things to match up, especially on the major visual beats, and maybe supply some feedback to the team if you think a recut would help a lot, e.g. to move a key frame. In actual gameplay, I'm less aware of anyone trying to do anything complex here; transitions often happen at the end of a measure, or sometimes the underlying music is written without a clear beat so that a switch to high-intensity music can happen at any point.
  6. You need to think about the control flow. Moving it outside the loop would mean you only ever accept one client, and then read from that one forever. Fine in some circumstances, but probably not what you want. Failing to store `client` anywhere, as in your current example, means you let a client connect, read some data, and then disconnect it and repeat the process the next time through the loop. You will want to be storing each client in a data structure so that you can service all of them periodically. Your current structure with the infinite loop makes this hard to do as it explicitly waits on just one socket, repeatedly. You're also calling this a 'Websocket' but your server-side connection is not a websocket at all - it's just a normal socket. A websocket is a very specific thing, i.e. a socket that accepts an initial HTTP request and transforms that into a 'raw' socket. See here, for example: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers . You don't currently have any of that logic on the server side, so the best you can expect right now is just to show that an initial connection has been successful. I would suggest that you maybe ditch the websockets for now and concentrate on getting a bare-bones server working, testing with something like Putty in raw mode instead. There are probably some trivial examples of C# chat servers around. Once you have that working as expected, you could add in the websocket support.
  7. Many games already perform that sort of calculation, but again it's not foolproof because the server's representation of the game world is different from every client's representation, and some degree of trust in the client is necessary for rapid-paced gameplay.
  8. I'm just saying that you can't have a meaningful discussion about interfaces when you are not talking about the interface itself. The whole point of the interface is that the methods it exposes are the way in which you interact with the objects. If you're trying to do other things that cannot be implemented in terms of those methods, it's a potential sign that you don't have a good interface, or that it's inappropriate for the types in question. You don't typically need values that are only part of the implementation. Sometimes people create an interface or a base class because they feel that they should be able to smash a bunch of different objects into the same data structure or container, only to then worry about how to get the derived type back later. The problem there is wrongly assuming objects are similar when they actually are not.
  9. Starting from (nearly) absolute zero

    No, UnityScript is what they called their cut-down version of Javascript. Unity's C# is standard C# - just an old version.
  10. There's basically no point posting a question about interfaces when you leave out all the content of the actual interface - that shows that you're not thinking in terms of the interface at all, because it's obviously irrelevant for your problem. It sounds like you are looking for something like the Bridge design pattern, and/or the Abstract Factory pattern. If you can ensure (to a reasonable degree of certainty) that you are always generating the right derived class for whatever you're passing it into, you can just cast it as needed.
  11. Starting from (nearly) absolute zero

    Nobody mentioned Visual Studio Enterprise on your original thread so I've no idea where that rant came from. Keep it polite, please. Unity uses an older form of C# so you're probably best off just learning from Unity tutorials and looking concepts up on the MSDN site as you go along. (Unity does support newer C# as well, but it's 'experimental' and crashes all the time, so I can't recommend that.) You don't need to buy tutorials, but you should be willing to invest the time to go through all their tutorials, videos, the manual, etc. After that, you can make a start on your game. I recommend starting out trying to get your world rendered, then drop a player into it that you can control, etc. Game rules etc come some way down the line. Regarding art, pixel art isn't really a way 'out', it's just another choice of aesthetic. Good pixel art can be more demanding than 3D in some ways, e.g. creating animations, transition tiles, etc. Your idea is okay, but ambitious for a first project. Expect it to take a long time. If you're impatient you may want to take on something simpler first. Your first project should be done alone, yes. Maybe you can get some help with art later. But don't try to run a multi-person project with no experience; it'll just end in frustration. And no, your age doesn't matter.
  12. Check your firewall settings on the desktop, and make sure that there are no rules that could be blocking that port. Also, install Wireshark and spend a few minutes working out how to filter the view of traffic. That should be able to show you whether data is arriving on the desktop machine at the port you have specified. Also, saying that IPAddress is hard-coded isn't much help - what is it? Is it definitely the local network address of the desktop machine?
  13. A good way to avoid extermination in RTS?

    I don't entirely understand the problem. Real battles had low casualty rates because one side would flee the battlefield and the other wouldn't necessarily pursue them. So why aren't you just implementing a fleeing mechanic?
  14. There isn't a big demand for people who cover all the different roles. Companies want specialists because dividing a task up into specialised problems is usually the most efficient way to complete it. So all I can suggest is to pick which of the disciplines interests you most and focus on that. Or, be self-employed.
  15. "if the level had waves which have rounds which have parts"... none of this is relevant to the view. Nor is anything about "return enumerations". The view needs to know what to draw. That's it. In a game, the things to draw tend to fall into 2 clear categories: concrete things with a dedicated visual representation. That visual representation might be a 3D model, a 2D sprite, or similar. You set up the view for those objects when the object is created. That object usually has a way of getting itself onto your screen. abstract things that need to be displayed some other way, such as a current score or some floating text. Usually you work around this by changing the problem into the first problem and either creating a concrete representation (e.g. a TextBox that references the data). The model needs to expose whatever methods are necessary for the view to get the information it needs. There's no super trick here - you just need to edit your model to make this possible. This is much easier if each entity has its own View object and its own Model object, because the View can reference the Model in each case, without needing to dig into hierarchies or whatever. But if you really want 1 View to be able to display a whole hierarchy of things in a Model, that is fine - you just need to make sure that the Model exposes methods to return that data. What data is that? No idea, it's your game. Talk of message queues and ticks are also missing the point. Your options are simply these: If the model is changing all or most of the time, the view needs to reflect that, so it should poll for updates frequently. If the model is changing infrequently, it can notify the view of a change via an observer. That's it. You don't need a message queue. The view just reads the data from the model when it needs it. If you find yourself doing too many updates because a small part of the model changes frequently, you probably need to break down your model into smaller parts.