Jump to content
  • Advertisement

Angelic Ice

Member
  • Content count

    214
  • Joined

  • Last visited

Community Reputation

929 Good

2 Followers

About Angelic Ice

  • Rank
    Member

Personal Information

  • Role
    3D Animator
    3D Artist
    Animator
    Art Director
    Artificial Intelligence
    Artist
    Audio Engineer
    Business Development
    Character Artist
    Composer
    Concept Artist
    Creative Director
    DevOps
    Environment Artist
    Game Designer
    Game Trailers
    Level Artist
    Level Designer
    Pixel Artist
    Producer
    Programmer
    Quality Assurance
    Sound Designer
    Technical Artist
    Technical Director
    UI/UX Designer
    Visual Effects Artist
    Voice Talent
    Voxel Artist
    Writer
  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Education
    Production
    Programming
    QA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Angelic Ice

    What technology for a game-server

    Oh, sorry, it probably makes more sense if you have the full context. Users can rate downloadable levels, expressing how much they like/enjoy it, so it does not really matter how much they rate it as long as it is within the given range of minimum and maximum : ) If it is outside boundaries, the request will be rejected, which makes sense since input should be validated as far as possible. I'm yet unsure whether sending files is an easy task and reliable (images, files, ...) over HTTPS? Ah! My issue with PHP is that is not statically typed, so I might stick with another solution anyway : ) But thanks for this insight, one never knows when that will help me!
  2. Angelic Ice

    What technology for a game-server

    I thought about using PHP too! Not specially, I just think data transfer should be kept encrypted as it is of not of interest for other people in the same network. To be precise, user data needs to be transfered, so why not send everything via HTTPS in the first place? What do you mean about trust? If someone manipulates my provided client, then the server will reject bad requests. If someone wants to rate 10000 instead of the maximum of 100, I reject it or if they provide other invalid data.
  3. Angelic Ice

    What technology for a game-server

    Is there anything in particular I have to look for? E.g. when I see a hosting offer, what terms will tell me that this service offers me HTTPS gateways?
  4. Angelic Ice

    What technology for a game-server

    What I definitely need is a good upload/download support, since uploading and downloading levels is easy to implement. I considered Go, because it seems to often used and statically typed, not sure if the standard library is sufficient or if I need Gorilla, yet. HTTPS would be very important, due to required authentication, as every level-rating sent is also related to a user. I read about RPC, REST, and CRUD. CRUD seems to be direct and sole operations while REST hides a multitude of operations behind a single request that strictly use HTTP commands (POST, GET, ...). RPC is a more customised approach as it seems, but in the end it seems to come down to "belief" or are there any ways to find out what I should use? But I'm not sure whether sending files via HTTPS is that great? E.g. a compressed folder containing images and scripts?
  5. I gave all these concepts a bit more time for me but still have some questions: When does the conversion from abstract values to real values happen? When I load an object and simply mutate the abstract value with the real one or does that happen prior drawing and I keep working with abstract units all the The issue I have with this, when the sprite moves, the graphics position change too, but do I mutate abstract values? This is a bit mind boggling to me. Also on another note, when my sprites are 1024x1024 large, simply because they have a high resolution, how do I handle the game's native screensize? We talked about using down- and upsampling of 1280x720 and 1920x1080, but this would result in a very huge size. If I have a row of 10 of them and I want them to fit into what the player sees, I would already need a format with at least 10240 pixels, I think that might be a bit brutal for a game's native size. Should I lower the size of my sprites? How do quality settings in games come to play? Do they actually draw to a larger native size with higher texture-resolution or do they draw simpler/complexer textures? Or do they start with textures that are lower than supposed (e.g. 32x32 instead of 64x64) and upsample them until the settings are put to Very High and then the original size (e.g. 64x64) would be used?
  6. Hello! I want to develop a server for my game, the game-client communicates then to it. I need following functionality: - HTTPS-support (TLS) - Uploading/downloading levels - Requesting ratings of levels and other meta-data - Sending ratings - Request overview of rated levels, own levels, popular levels, ... - Neat way to use MySQL for mentioned points And my questions are: What technology would be the best fit? What programming language/framework? What exactly do I need to provide named functionality? I value ease, safety, development-speed over performance, as I won't have millions of users. Thanks for your time.
  7. This is what I wanted to learn about in this thread. I know that art should be seperated from physics, but I was not sure how I would make art independent from resolution and then physics transformable into graphics. So borders are literally bonus pixels that are used so that sampling methods do not blend over with nearby colours. I think the rotating cube image did explain it fairly well: So what I see is that Unity is using abstract units. Their meaning is given by the developer. A unit represents a number that I decide. Working with percentages would be one way to construct these units, I assume? And about physics, if I say, an object is defined as such: x-position: 0.5, y-position: 0.25, width: 0.2, y-position: 0.2 I think that is okay to do? If there is no off-set, I assume it is safe to calculate the collider's position like this. But I assume one would usually save physics x, y, width, and height separately from sprite x and y. One last thing, what's more common: Sampling every sprite directly to the screen-size or rendering in game's native-size to a view and sampling this to screen-size? Because first would require me to set the scale of each sprite manually, latter would make me set the scale of the view, I guess?
  8. Hm, but wouldn't artefacts occur over the entire sprite-structure anyway? I'm not sure if I understand this issue well enough. Not all sprites are fully filled to the very corner (out of 64x64 pixels, 64x64 are filled) and own a mix of transparency/isometric/dimetric/.. and do not fill the entire sprite-image assigned to them inside the sheet. Thus I do not really understand how adding a "border" would fix this? The bleeding would occur way before the border of the sprite is arrived. Sorry but I still cannot imagine the process.. So, when I have a 64x64 sprite that I load 10 times onto the screen, next to another, I would at least require a width of 640. I decide that this looks good and shall be what every player (with the same aspect ratio) sees and pick 1280x720 as my default resolution. Now a user with a native resolution of 1920x1080 starts the game - the game starts in 1280x720. The user changes this in the settings. If I draw to a render target, I can simply upsample this to 1920x1080 - there would be no restart required here or would it be? I can reproduce this with a view-element from SFML, rescaling the view does not require a restart, it's a pretty dynamic process. So the restart would be required if I work in percentages? Deserialise whatever level, and directly save every percentage as absolute coordinates on a sprite's usual way to attribute its position and size? On another note, I assume physics would work in percentages too and also converted to absolutes? Thanks for you two's patience with me<3
  9. Thanks! So there seem to be two ways, either one works with absolute pixels and a preset window-size and transforms the view to window-size or one works with a very basic coordinate system of values between 0 and 1 and draws accordingly based on window-size. The reason I mentioned two attributes was to prevent re-calculating by caching the result until it's outdated (sprite moved, screen resized, ...). Since doing 0.5 * 1280, 0.25 * 720, every time seems unnecessary. Now, what I do not understand, what do you mean by artefacts? What does this mean? What are artefacts? I know that when I scale images, pixels can jump around into ugly places, is that what this means? Especially if nearest neighbour scales from 100% size to 120% instead of the next full option: 200%. But what is a margin in this case?
  10. By artefacts you mean artefacts caused by up- or downscaling? What I understand: Draw to a render-target or something as a view, this could be 1920x180 big. Then scale this to the actual window-size, e.g. down to 1280x720. The question that remains for me: How do I handle different aspect-ratios? If I do not care about what is actually seen on the screen, I can simply show more or less and have 1920x1200 as virtual size? I always thought relational coordinates and sizes are the way to go, so this is a bit new to me, but interesting : )
  11. Hello! I know that working with absolute positions and sizes on sprites and collision-boxes is not a good idea if one wants to support multiple resolutions. But what ways are being used to actually scale properly? What I know is working in percentages (and offsets). One would define a vector of x and y (both between 0 and 1) and an offset vector of x and y of arbitrary pixel size. Now multiply with the screen-size and add the offset and get the scaled absolute size. This would work for size as well, but probably without the offset. So if an object is outside of the window, its relative coordinates would be higher than 1? I assumed updating absolute coordinates is done once when the resolution has been altered and every sprite owns two attributes: relative and updated absolute coordinates. But then again sprites can move thus change their relational coordinates; it's probably easier to do the calculation every draw-call or maybe keep a "has sprite changed its size/position"-flag/bool. And I also assume that physics are calculated the same? Since the transformation is 1:1, every mouse click can be transformed into relational coordinates and then do the usual collision maths. Same goes for sprites, I would calculate movement in relational coordinates and with relational sizes and then alter the relational coordinates. There is one issue on my mind, since all these values are meant to move in floating numbers (e.g. between 0 and 1 for everything inside the resolution/visible canvas), isn't there a float-point accuracy issue with different hardware? Especially if savegames are usable on other multiple devices, e.g. from desktop to smartphone. On a final note, are there any other alternative systems for scaling sprites according to a resolution? Thanks for your time.
  12. Oh, interesting point, thanks! I wonder why there is such a lack of interest to support newer features, C++11 is 7 years in the past by now and plenty new features arrived that help development. Is it because those compilers are considered time tested? So I fear, if I use anything newer than C++11, it will bite me whenever I think about porting later, hmph.
  13. Hello! I'm currently working on a project where I'm heavily using C++ 11 and 14 features, but also came into the taste of 17. Now, I know there are plenty of NDAs, but what would be the wisest decision to make if one wants to keep other modern consoles as a possibility? I know wrapped around my current graphics backend, so switching it out is less of a pain, but I imagine that if I build my error-management on C++ 17 features, it might become very annoying to port the project. Especially since I fear that systems - as the Nintendo Switch - are only supporting C++ 11 - if even. Are there any tips to be given as in how I should decide on this or how to structure code? I assume, they use their own modified compilers, not sure if they are interested in even adapting to new standards... especially I read somewhere, that older consoles were not using C++ 11. I think, using boost would be one option and use its implementation of some new types introduced in C++ 17. I might just need a toss in the right direction. I know there is probably not much to found decisions on, but might be a part that I'm overlooking... who knows! Thanks for your time : )
  14. Hello! I'm actually an intense user of Lua for scripting-related events, but there is one thing that bothers me a lot: Serialising an in action scene. Let's take a dialogue-system as an example. In Lua, I see these often realised via co-routines, and did that myself quite often, but it's a difficult act to serialise the exact state. I know about serialisers like Pluto, but those are not really clean solutions, a change in the Lua-version etc. and suddenly the behaviour is anything but defined. I don't think I would want to serialise the raw content of Lua's stack etc. This concludes to my question: How are these systems serialised? Using a state-machine could be one thing, but I fear that writing such code might be difficult for casual scripter that want to modify the game a bit on their own - being an inherent reason of me picking Lua, as it is simple to understand and learn. Any solutions to this? I would love to see implementations, prototypes, or articles of any measure. Maybe there is a different simple scripting-language that solves this better? Thanks for your time.
  15. Ah, I see. That means, I need to keep and transform the bounding box from axis-aligned to the displayed view as well? Will have to look into what mouse-collision is common for that shape, probably some diamond/point math.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!