• 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

467 Neutral

About BauerGL

  • Rank

Personal Information

  1. Just making a note here that this devlog is cancelled. However! The development of the game is still going on strong, you can continue to follow it via our web or twitter (see signature links)!   Thanks for checking it out, have a great winter break and an awesome 2017!
  2. Behold, another sport is nearing completion! This one is currently called Animal Feed, and the aim of the game is to feed the sugar craving animals with delicious candy! The gameplay is similar to clay pigeon shooting and whack-a-mole, where you aim the crosshair with the dpad and throw candy using the A button. Get the highest score by gaining multipliers and hitting specific high-value targets. Birds, bumblebees, capybaras, moles and maybe even some more, show up when the sweets are for free! Here's a short gameplay clip: We've had a bunch of meetings to decide where we are headed next and our plan is to wrap up two more sports plus some additional content before the end of the year. Next up we'll get started with a new sport as well as adding team vs team mode to all sports. We've also got a really funny idea about how to decide the winner when some players end up with a tie score at the end of a tournament. More to come! 
  3. Hey all! It's been a long time since the last update, for various reasons. One of the reasons is that we've tried to develop multiple sports at the same time, essentially prototyping five sports simultaneously. Therefore there hasn't been a lot of interesting stuff to show, until now!   We've recently finished up one of the prototypes, namely a sport named Capy Throw. The basic idea is that you'll need to rotate your character as fast as possible by rotating the dpad/analog stick, and then time your release with the rotation to throw your capybara in a straight line, to throw it as far as possible! It's also possible to deploy a hang glider with the press of a button and depending on when it is deployed you will either get more wind resistance or a bit of extra hang time, so timing is very important!   Here is a quick gif that shows the gameplay loop in Capy Throw:   There's also a news post about it here: http://sportmatchen.com/news.html#2016-07-11   Take care! 
  4. I'd like to mention Braid and The Witness too! I don't have all the links at the moment but there are some youtube videos with Jon Blow where he discusses his view on these kinds of things. This one for example might be a bit interesting: https://www.youtube.com/watch?v=UwBl7Rnkt78
  5. 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. 
  6. 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.
  7. 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.
  8. 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.   Overview   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!
  9. 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. 
  10. I'm currently trying to rewrite a small engine using a style which is more towards C than C++, and at the same time I'm trying to figure out a way to keep the platform specific code separated from the platform-independent code.    The basic idea is to have a folder structure with one folder containing all the generic code and one folder per platform where all the platform-dependent code will live. Each platform will then include the generic code where needed. Super simple structure and it's very easy to see which files belong to which platform. The whole point of this is to get rid of randomly placed #ifdef PLATFORMX spread throughout the code.   Do you have any tips for how this can be done in a nice and clean way?   So far I've got these ideas:   The platform-independent code can define and use a basic struct which contains data that must be present on all platforms. For a sprite object it could be stuff like position, rotation, scale, list of animations etc.    The struct could then also define a void* platformData at the end, where the platform layer can define the data it needs (file handles, render info, etc). It could also work with platform-specific sub-structs, where Win32Sprite contains a Sprite object at the top plus the platform-dependent info. So casting a Win32Sprite to Sprite would be fine since both have the same data layout at the start.   For a potential Sprite::render() function, it could just push the generic sprite info (material, position, etc) onto a render queue which can then be processed and rendered to screen on the platform-dependent side however it sees fit.   The loading code would however need to be implemented per platform, so there's really no way to implement a Sprite::load() function without it being platform-dependent. For these kinds of functions I really have no idea how to properly do it. One way would be to define a function in the platform-independent code that must be implemented in the platform-specific code, but in that case it would be nice if those "required functions" could be kept in the same header so it's easy to see what a platform layer is required to implement.   If you have any tips or links to articles, I would greatly appreciate it!
  11. Hello friends of sport! Seems like we all made it through into the new year, nice! We're back in the (metaphorical) gym after a really sweet and relaxing winter vacation. Pre-Christmas we started work on our newest sport and today we're here to announce its completion. Behold!   Hoops is a frantic all-against-all battle, where you'll need to master both timing and agility. Push and stomp your opponents to steal the ball, go for heart-stopping three-pointers or dribble your way to the basket and watch the other players cry in agony. And if your opponents are being cocky, shatter their self-esteem with a sizzling slam dunk!   A fun thing about Hoops is that it contains a lot of extra stuff, such as the seemingly pissed vulture and a really exciting halftime show featuring Mr.P and two cheerleading stoats!   Wow, that is surely setup for success. So what to do now? Go pump some iron? Run a marathon? Hell no! We'll go sit down in front of our computers and start working on the next sport of course!
  12. Sporty new year to you all!   Here is a screenshot of our most relaxed sport so far, called Boll Toss.   The goal is to toss your ball (using angle and power meters) into one of the marked scoring areas. You'll need to take both the wind and the surface type into consideration. Currently we have sand, ice, asphalt and "indoor court" as surface types, each with their own impact on the ball physics (bounce/friction). If you are really pro at this sport, you might even try to toss your ball into one of the baskets to get the highest score!    Also, here are some dancing stoats!
  13.   The Game Super Sportmatchen is a competitive sports game for up to four people locally. The game consists of a selection of different sports, ranging from the frantic and fast paced to more relaxed and concentration based sports. Invite your friends, foes and relatives for a game of competitive sports!   Two of the playable characters, Agneta from Sweden and Johnny Top from Canada.         One of the currently available sports, 250m Plint-Sprint.   The Background The game came to be (as they often do) during an evening filled with beer and other healthy beverages. For some reason we had a discussion about the absurd nature of competing in sports, basically everything from the shocking amount of money involved to the often comical sports interviews.    Basically this comic:   So we started with the thought that it’d be fun to try to capture that in a game without going overboard with weirdness. However, during development we’ve more and more steered towards trying to do something that is a mix of Track n Field and Mario Party, with a focus on fun competition in a cute setting. It’s a great game if you want to turn your best friends into your worst enemies. ;)   The Secret Sauce Super Sportmatchen is being developed using a custom made engine in C/C++ and Lua. We chose to go for a custom engine both because of the game requirements being very simple and also because it allows us to tailor the features to our exact needs. For example we have a great workflow with the ability to hot reload both code and assets, which greatly helps speed things up during development.   The tools we use are: Sublime Text 3 for coding C++ and Lua Visual Studio 2012 for debugging C++  Photoshop CS5 for the graphics Reaper and sfxr for most of the audio (with Matt Montag's NES VST for the music)   The Team Super Sportmatchen is being developed by three dudes: one coder, one artist and me doing both code and audio. We’re working on the game in our spare time and the initial commit was done way back in late 2014. Since we only have a few hours per week to work on the game the progress is a bit sporadic, but we are aiming to get the game done sometime in 2016!     Follow us on twitter, sportmatchen.com and here on this devlog! We are grateful for all the feedback we can get, thank you!
  14. One thing that I can recommend btw is to use one channel for reliable msgs and at least one for non-reliable. Some non-100%-sure answers: Afaik Enet is a very thin layer on top of UDP, which means that youll have to do a lotofstuff yourself, such as calculating the data rate, ping, etc. I think it maintains its own copies of the data. About your example with lost packets when sent unreliably on the same channel, I guess this can/will happen evey now and then but in the general case they should both arrive in order. I wouldnt recommend a channel per msg type though, but it could be an idea to use different channels based on update rate. Ie you might send positions and rotations each frame on one channel, and send something like powerup status or time played updates every 100ms on a different channel. This gotme excited to dev another mp game. :)
  15. Hm I'm afraid I can't answer most of your questions right now, they are probably more suited for the ENet developers. I haven't used ENet much in the last year and I've never checked through the source. I need to dig up some source code from old projects to get a better grip on how I used to do things. :)