• 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.

Krohm

Members
  • Content count

    3148
  • Joined

  • Last visited

Community Reputation

5028 Excellent

About Krohm

  • Rank
    Contributor
  1. As a start consider a game is much more than code. In my experience simple games run great in browser. Everybody can play them, they're portable, need no install and nowadays you can get quite far with them I mean pure HTML/JS stuff. OFC you don't use HTML nor JS but some framework, and maybe Dart or Typescript. And there are plenty of frameworks. Plenty. So you want to go programmer route? C? Say no to C. You'll get mad very soon. I don't suggest C++ either. C# is kinda good. Or, you could just play a bit with Unreal, see what you can do, learn a bit about pipeline. Make a few levels learn a bit about gameplay. Or heck, you could just buy some games off steam or the humble bundle and see what you like. Sketch a plan.
  2. Any chance you have enough perf/functionality to just expand each prism to a buffer and somehow ray-walk it? After playing the Talos Principle I had to surrender to the fact Parallax Occlusion Mapping (of sort) is now fully viable so maybe having some kind of "fog collection buffer" with dual layers might work. Plus, everyone and the dog is doing terrible screen-space reflections.
  3. There are indeed a variety of ways, I know them as 'tags' and in theory they work... except for some reason they really don't in this specific case. I use sourcetree so it's just a matter of pushing a button. Well the snip is a full SHA and I've had a collision already in the past (not on SHA) so I feel quite safe for the next few years! They are indeed almost unique. Absolutely true. I'd say this problem is orthogonal to being distributed or not (compare P4 or other old stuff). For our environment it's fairly convenient to have a bare repository on a shared folder: ideally we don't push short lived branches there - ideally we sync no more than a couple of times a week and push a full untagged branch with explicit merge commits. I suggest everyone to have a go; my experience with git is positive albeit I used to have a thing for Mercurial. Maybe I should have made clear that GitVersionTask stamps your c# executable with proper versioning by looking at the git. It isn't even just a property setting: you can inspect the result programmatically. Anyhow, I had been given unwelcome news today so I'll be slow on replying. Given my new schedule, I think I might just give up on GitVersionTask and go back on explicit version stamping. Inconvenient but I have already spent too much time in figuring out what's wrong there.
  4. Uhm, where did the source control subforum go? Nice to have a modern-looking gamedev.net indeed! Ok, let's get to the real deal. At my current job I have somewhat managed to get to something useful and to be released. I always had an issue with versioning and so I just installed GitVersion, the relative tools and its automatic MSBuild thingie GitVersionTask. Leaving aside I'm meeting some resistance in using source control at all, our team is so small there's really no point in using anything more than the old merge/branch model. Software development around here is... curiously managed to say for the least so I had the following needs: Official builds marked as major.minor.patch Unofficial builds as (1) plus unique identifier. SHA would be perfect. So, what I do: I merge off master to work on something, when I merge back to master that would be a 'build'. Whatever that build is released to public or not is not my concern: stuff in master is ideally official. It seems like mainline development should be my thing right? Wrong. I tried countless configurations and wasted about three hours today the end result is always some variation of (output in VS build). My gitVersion.yml: next-version: 7.2 mode: Mainline I tried annotating the master branch by using gitVersion.yml 'branch:' subsection with no avail. I have however confirmed the file is being consumed by successfully altering the produced major/minor and by producing errors. I am a bit reluctant in opening an issue on the project page as it's basically certain it's something by my side. What am I missing? By the way, after all this pain I might actually consider other versioning mechanisms. All sort of suggestions are welcome.
  5. I consider myself very lucky in finding this as one of the first sites I found when I got my functional internet connection. The pennies I've spent on dial-up have been definitely the best investments I ever did no doubt.  Thank you gamedev. I hope I can get the discord dudes to reset my account. Peace!
  6. Albeit not perfect, upvoting is widely understood and sorta working. I would however get away with the idea of scoring as numbers: whatever you keep them serverside it's a thing but I don't think they should be presented to user. Everything that matters is to bubble up valuable insights. What I care: understand if something/someone is valuable/reliable. In general the specific number isn't relevant to me but I know if it's in the thousands he's probably been around a bit. Perhaps I will re-read. Sometimes I also check 'member since'. Some messages also have 'tags'. I recall the 'popular' tag on the Vulkan/API discussion. I'm pretty sure those could help. Then, how do we enable people to distribute them?
  7. I thought I might stop by a little (I managed to lose the discord account). I am at a point I could consider having paid enough of my company technical debt. Not to say the problem is solved but at least the projects can start moving forwards. The workflow involved in embedded systems is terrible. I don't think we would even be at register combiners level if GPU industry took the same stance. I knew that already but being around here provided me really good value. I realized I have been very lucky following this field, there has been a revolution decade(s) ago with GPUs and people never ever got to realize it. I have finally managed to get some decent amount of C#. And some experience with Angular. Does that mean /me is web-dev now? Notice me Senpai!
  8. STOP. If you want to do something more than you are already, let it be something not mind-based. I suggest jogging. Or fast-walking. Go have an ice cream to the other side of town. Whatever makes it for you. I currently work 0800-1730 but with a 80 minute commute that becomes quite longer. This is hopefully changing now and I plan to go on swimming. I don't think you need motivation at this point. You need to manage yourself for long-term effort.
  9. Wow that's kinda cool. I don't think I ever visualized something that is between stuff that doesn't exist. Wow.
  10. I would suggest against inferring your narrow-phase collision data from graphical assets. It is kinda unflexible; sometimes for artistic reasons you want the collision data to be smaller, bigger or different; I remember a game in which staircases were often simplified to ramps at collision level.   An automated process will most likely be unable to detect when to use a sphere primitive instead of a hull or perhaps an assembly of hulls instead of a trisoup.   Tying the physics to graphics involves quite some work for simplification and going by that mindset you'll probably open the door to the special collision flags [i]collidable/bot-collidable/weaponclip[/i] etc...  mighty be worth thinking in more generic terms.
  11. I feel the controls are a bit off... I moved a ball out of a chasm and it rolled horizontally to crush me. I wasn't expecting that. Not my kind of game unfortunately.
  12. Did you use your personal email as contact? Don't do that! Have an email for each product!   No extra permissions required. Good. I'm trying it.
  13. That's kinda cool.
  14. An update to the game you posted a few days ago... I've downloaded it again.   This time I read the description and I still couldn't get what to do. It was my understanding I was the circle and I had to land on the cube somehow so the description didn't make sense to me. However it turns out (by accident) I can get inside the donut-like thing (which is a single object) with multiple colors... Interesting idea, I also see you added a few sharing things leaderboards and play services, ok. I'm leaving you 4 stars for the effort but I still think you must find a solution for better affordance.