Advertisement Jump to content
  • Advertisement

Angelic Ice

  • Content Count

  • Joined

  • Last visited

Community Reputation

929 Good


About Angelic Ice

  • Rank

Personal Information

  • Role
    3D Animator
    3D Artist
    Art Director
    Artificial Intelligence
    Audio Engineer
    Business Development
    Character Artist
    Concept Artist
    Creative Director
    Environment Artist
    Game Designer
    Game Trailers
    Level Artist
    Level Designer
    Pixel Artist
    Quality Assurance
    Sound Designer
    Technical Artist
    Technical Director
    UI/UX Designer
    Visual Effects Artist
    Voice Talent
    Voxel Artist
  • Interests

Recent Profile Visitors

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

  1. That depends on the lobby-setting. One can set a maximum amount per turn, e.g. 30 minutes. Closing the game is fine, one can always reconnect to a lobby. I thought about serialising the game on the database. Games save their own state on disk, if someone wipes all data, then one would need to request the game from the database. Well, my game is somewhat like Hearthstone. Players can look at their "items" and plan ahead, and use the chat. At some point the server notifies them that their turn is due and the timer ticks. I looked at WebSocket and I think they suit my needs quite fine. I will have to see on how authentication works with them and how to wisely differentiate channels from another, but maybe authentication and token acquiring should be a different WebSocket-server and maybe even HTTP then lobby-managing? When I think about acquiring things like daily quests, that's easily done via HTTP. While lobby-creation seems to be rather done via WebSocket. Is it common to simply set up multiple servers as multiple executables? Eg. login/token-acquiring-server via HTTP, quest-acquiring via HTTP, lobby/game-session-server via WebSocket, ...?
  2. I did not even think about the chat, yes, there is a chat. Also it works via cross-play, so both mobile and desktop-players. Websocket seems a bit risky if the receiver is on mobile. E.g. Android could kill the application or internet cut off. So some resync-strategy would be required. I really liked my HTTP-simplicity but that seems unfit then I guess. Polling every x seconds is too slow, some sessions are as fast as players react and not in a slow-mode tolerant way where players can react within an hour. Is there a protocol suited here? Maybe something like WebSocket? How is syncing done?
  3. Hello! My plan is a game where multiple players play turn based, often with a hours in between turns and sometimes seconds. My idea was an RPC/REST-server, where users request data and send data. One question arises though, what if a player disconnects? How do I inform the player? I fear I will need a TCP-connection? Or should clients regularly poll for updates via the HTTP-API? I feel like having an event-log table in my database might be a solid option and the player then requests new entries after entry number X? Thanks for your time : )
  4. 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!
  5. 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.
  6. 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?
  7. 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?
  8. 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?
  9. 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.
  10. 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?
  11. 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
  12. 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?
  13. 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 : )
  14. 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.
  15. 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.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!