Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Dec 2001
Offline Last Active Jun 23 2016 05:57 AM

Posts I've Made

In Topic: Rope Racers - online multiplayer racing game! (by Small Giant Games)

23 March 2016 - 02:37 AM

Great work, this game looks like a lot of fun! I can definitely see myself playing this on a friday evening with some friends (and beers)! Does it come with ad-hoc wifi play?


My only gripe is with the fonts (specifically the "Xth" place text and the text for the distance to other players (i.e arrow with "28 m"). The font feels like a debug font and the general placement of it feels off (especially for the Xth place text). I'd suggest to move the Xth place for the local player up in the main hud at the top center of the screen or replace it with gold/silver/bronze medals for those positions maybe. 

In Topic: Cross-platform API design

10 March 2016 - 07:08 AM

Yeah, definitely going with sprite sheets! There will be some data for the available animations in the sprite sheet and the per-frame info will contain the row/column index of the subrect. So essentially in my world a Sprite is a usually a sprite sheet containing an array of available animations where each animation contains an array of available frames.

In Topic: Cross-platform API design

09 March 2016 - 06:43 AM

Hey nfries88, thanks for your reply! First of all, yeah I'm currently basing my Windows/Mac/Linux version on SDL2, which is great. I should spend some time with browsing their source to get more ideas on how to handle different platforms, that's a great idea!


My initial idea with the sprite code being different between platforms would only be for the parts you mention, as in the loading and drawing code (etc). My initial idea was that I would create an array of generic Sprite objects with a pointer to some platform data and the platform data could contain OS/renderer specific info (texture ids, file handles, SDL_Surface* etc). But it feels a bit weird to do it that way and it also feels insufficient in terms of the code having to jump between the generic sprite info and the platform info.


My current plan is to, as before, let the generic code just work with the generic Sprite struct. The platform would though instead make a PlatformSprite struct which contains a Sprite struct and whatever platform data is needed. When the generic game layer asks for a Sprite object, it would be initialized as a PlatformSprite and then given a pointer to the Sprite part of it. The generic game layer is pretty much only done in Lua anyway and Sprites are passed around as light userdata (pointers). So that seems like a pretty good match.

In Topic: Super Sportmatchen by Kaj Forell VGB

07 March 2016 - 05:49 AM

Today we had a plan to show off our latest sport, but unfortunately that plan had an accident and so there is no new sport to report about. Instead I'll give a quick rundown of our so far only tool that we have developed for the game. The purpose of it is to help our graphics artist animate all of the characters and objects found in the game.
This is the main interface of the tool. As you can see, it's possible to switch animation from the scrollable list of animations (wow!). It's also possible to select the current frame, either by clicking the frame button or by pressing left/right on the keyboard. 
We've also got support for something we call "attach points", which is basically a named reference point in a frame. It's just an offset from the sprite's center point, that we can use to attach characters to bouncy balls and similar.
At the top there is the general menu for pausing/playing animations, toggling loop mode, adding and removing ghost frames (loek) as well as saving and opening sprites.
Switching animations
Here you can see me switch the vulture's animations. Notice how some are looped while others only play once. The loop behaviour can be toggled between always on, always off or use the specified value for the sprite's animation. Also note how the current frame button highlight changes as the frame of the animation changes.
Opening a sprite
Here you can see the interface to open a sprite. It's just a simple input interface (inspired by Sublime Text) to browse for the wanted sprite. The list shows up to ten of the most relevant matches out of all the sprites in the project.
Using onions (or ghost layers)
Using onion layers when doing animations is a really good way to get a feel for the flow of the animation. It's much easier to see how each frame sets up the next frame compared to when viewing each frame independently. The amount of ghost frames can be increased/decreased.
Other stuff
As with the game, the sprite assets can be hot reloaded while editing. So the artist can paint and change frame durations etc and then immediately see the changes while the animation keeps looping.
We also have support for having multiple sprites open in the tool, at different layers. There's also a quick setup script for this where specific scenes can be set up, for example attaching a character to a ball and then editing both of them at the same time.
I've always been a fan of having editors be as close to the game as possible and one neat thing we added semi-recently was the ability to be able to tab between the tool and the game at any time. So we can start a sport, notice that an animation is a bit off, press tab and load the sprite in the editor, make some adjustments, save it, press tab again and see the changes in the game. 
That's it for now! I hope we can come back with an update about our next sport real soon!
Take care!

In Topic: Cross-platform API design

06 March 2016 - 04:02 PM

Thanks a lot for the tips and feedback! Sounds like my ideas are decent enough to pursue, plus I've gotten some new insights from your answers. Much appreciated!


@Bregma: I really enjoy your passive aggressive tone.