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

ByteTroll

Members
  • Content count

    161
  • Joined

  • Last visited

Community Reputation

3031 Excellent

About ByteTroll

  • Rank
    Crossbones+

Personal Information

  • Location
    Michigan
  1. Coding is coding, no matter what your coding (TM). While certain (theoretical) concepts and practices might change between programming a game and an app (a game is really just an app), the language is not going to change. You learn to read and understand the source code by learning the language and reading/writing lots of code. Besides, you'd be surprised at what information can be carried over and applied to other areas. Just because a technique or practice falls under 'app programming,' does not mean that it can't be turned around and used in 'game programming.' Take it one step at a time. Read and write lots of code. Learn the language. You'll be fine!
  2. Try taking a different approach. Find beginner LUA resources (which you should have no problem finding), learn the language, and then go back and read/learn the "Love2D" API through the documentation. Here are some links to get you started: https://www.tutorialspoint.com/lua/ https://love2d.org/wiki/love Good luck.
  3.   Killing Floor 2, aye?  Your personal project is looking pretty dope.
  4. Google "Postal" and "Grand Theft Auto..."  There's your answer!
  5. I'd love to play it!
  6. New head crab... Half Life 3 confirmed!
  7. I've been super busy trying to wrap up other summer projects before school starts, but once things have settled down and I have a second to breathe, I will write an appropriate article.  Had I known the interest was there, I would have done it a long time ago!   Navy, I've been long aware of Java and its memory limitations, however, up until this point -- that is, up until the point where I had to develop a game using native marshaled code, memory limitations were never an issue.     I was aware going into this project that I would have to be careful.  I had done a lot of prior research on LibGDX and thought I had planned accordingly.  However, despite all the preparation, I still encountered issues.   I had initially detected leaking memory on day two, but it wasn't until day three (when I actually ran the project under my memory profiler) that I realized how severe the memory leaking was.  I found that I was leaking an upwards of 1GB of memory every 45 seconds.     After many attempts to patch the leaks in code, I realized that I had to resort to my "last resort" plan to A) ensure that I could stay in the competition, and B) ensure that I didn't get a low score at judging time.  My development tower has 32GB's of 1866 MHZ RAM, so I could survive the leaking memory, but I knew that most judges weren't going to have those hardware resources available at testing time.
  8. He does, and is.  I would not have completed this project if it wasn't for his assets (again)!
  9. It is actually funny you recommend that.  I've been considering doing something of that nature for awhile now.  I've considered taking the route Bjarne Stroustrup did with C++ -- creating a new, separate language all together. Java++ anyone?   Thankfully, most of the added functionality up until this point has been coded in raw, JDK 7 compliant Java.  All of the functionality is resolved though hooking the compiler at certain stages, processing, and then injecting the result back into the already existing trees before continuing on.   A perfect example of this injection is our operator overloading mechanism.  When the compiler goes to resolve an operator token, but detects an "overloaded" operator token the current resolve stage is halted and hooked,  After hooking, the overload is resolved (our operators work though your typical 'magic-function' ideology),  The result is then injected back into the existing trees, and all becomes right with the world!
  10. Unfortunately, yes... and I wish I didn't have to.  One should never have to stoop to that level; ever.   To answer your question, there are several reasons that we maintain a javac implementation.   1) I had initially started the javac implementation with the release of Java 1.7.  At the time, I was doing a lot of embedded systems programming with robots (I was compiling certain files on-the-fly) and I needed to have a standalone Java compiler that resided on the system.  Sadly, this is never as easy as just copying from your JDK folder and throwing it on the local filesystem.  Furthermore, for specific projects, I had used a modified JDK, so it only seemed logical.    2) Java is very good at what it does, but it doesn't always do it in the best way.  Java is a powerhouse, but there are limitations to the language which make it hard to solve some problems.  Take operator overloading as an example (which our javac implementation supports).  There are 100 times a day when I am trying to solve a problem using Java, only to think, "if I had operator overloading, this would have been resolved hours ago."  Instead, I usually have to come up with some crafty, dirty, or otherwise obnoxious looking way to solve this problem.   3) With Java, everything is a damned exception.  I clearly understand the need for exceptions -- both runtime and compile time, but there are certain sections of code (or hell, even projects) where you don't want to have to deal with them.  Moreover, there are situations where I know ahead of time that an exception will be triggered, but that use-case was intended and I want to purposely suppress the exception.  In Java you can't do that.  Everything is an exception (figuratively speaking) and everything has to be handled.  In the case I presented above, throwing an exception during runtime on a robot is pretty much game over.  The "finally" mechanism is there, but again, doesn't play well with all use-cases, so it is important to handle this stuff at language level, versus one of those spotty one off annotation based approaches I see everybody resort to..   As I previously noted, Java, like say C# is a powerhouse, but Java makes it hard to do things some times.  I have found that the little time it takes to maintain a compiler (especially since I am already a language buff/compiler guy and have a lot of experience writing and maintaining compilers) is dwarfed by the amount of time it saves during development. Especially when you find yourself in a situation like this.  There are other reasons for maintaining our own compiler, but again, what it comes down to is Java is good... Java isn't great.  By maintaining our own compiler, Java is great and saves us a lot of hassle.
  11. Slicer,    Sorry it is late, but here is a link to the postmortem post I wrote.   http://www.gamedev.net/blog/2220/entry-2262195-woa-2016-team-bytetroll-postmortem/
  12. I'd first like to apologize for the failure to provide community write-ups during the Week of Awesome. When I had initially started, I had fully planned to write a journal post a day, however, after day two of development, it became obvious that I was going to have to push aside lesser priority tasks, as the coding portion of this project took more effort and time than expected. Regardless, this postmortem post will be lengthy as I believe that keeping the community updated though the journal posts is not only important, but a major part of what makes the Week of Awesome competition so challenging and rewarding. One does not get the full experience of surviving a project development life-cycle if the documentation (or in this case, community) phase is skipped! This postmortem will expand on my previous diary posts. If you have not read my previous posts, and would like to, the posts can be found in my "WoA" developer diary, which can be found at the following link: https://www.gamedev.net/blog/2220-woa-2016-team-bytetroll/ With that all being said, lets get started with Team Bytetroll's postmortem post. As noted in my previous posts, I had a bit of bad luck this year. My normal tried-and-true team was busy with real life and alerted me to the fact that they couldn't participate this year (although, a day or two before competition, Riuthamus found out he had the week free and decided to compete; leaving me to compete against my own team). Furthermore, I had made the mistake of following the workflow I had taken in previous years and preplanned a week from competition start. While preplanning is normally good (yet alone a must), in retrospect, I took the wrong route when it came to selecting a programming language for the project. I had initially selected Java as my language of choice for three reasons: 1) Java has fast turn around time. 2) Java (for the most part) is stable and reliable. 3) Java (for the most part) is write once, deploy everywhere. Moreover Java seemed like the logical choice as I have many years of experience in Java development (although not writing games) and am very familiar and comfortable with the Java universe (tools, the way things are done, etc). Also, despite slot machine gameplay being the only type of gameplay I had never researched or implemented in my 15 years of working in the industry, I figured that it was a slot machine, and there shouldn't be too much logic behind it. However, again, looking back in retrospect, this mentality would soon cost me. It is at this time, however, that I would like to note that a majority of my frustration was not with the language itself, but with the limitations of the language -- something of which I should have foreseen. My original thinking was that several games had been coded in Java, all of which have at least average console performance. I found myself overlooking the fact that Java lacks a true programmer managed memory mechanism at the language level -- which is almost a must for any game. This proved to be the real hassle. Despite me being a first time LibGDX user, I had done my required research; making sure I was aware of their memory management scheme for releasing native objects. However, for what ever reason, I overlooked this fact, and didn't plan or account for it when creating my framework. The result was that my UI class was leaking obnoxious amounts of memory due to the way that I wrapped LibGDX's native "Texture" class. To make matters worse, I knew were and why the memory was leaking, but after multiple attempts (from both I and Migi0027) to patch it, had no way to solve the problem without a total rewrite of my framework (which at that point was close to 100 files and five or six thousand lines of code). As a result, I had to resort to my backup plan; knowing full well it was going to severely hurt my week. Despite this I kept true to my original promise[1]. I quickly cloned our in-house 'javac' compiler that I wrote and maintain at work and spent the next two days adding C++ style memory management to Java (which actually turned out pretty well). While it was a pain, it solved all of my leaking memory issues, and surprisingly turned out to be easier than rearchitecting my framework. This was not an ideal solution by any means, but given the context, it was my last and only option to stay alive in the competition.. After the memory leaking issues had been resolved, I was able to continue on with my last few days in peace; ultimately wrapping up and compiling my final build the morning of competition end. Implementing and structuring the slot logic was bit of a hassle, but an event system took care of that. Other than that, there is not much left to say. I am considering open sourcing my project and am thankful I got the chance to compete again. It was a hell of a week and I had fun. I'd like to once again thank Sean Forbes (Riuthamus) and Miguel Petersen (Migi0027-cdk) for everything that they did for me during this week -- especially to Sean, who took the time to hand draw my assets, despite him having to create assets on his own team's WoA project. To both of you, I greatly appreciate it. You allowed my project to ship (literally). - The Troll [1] [size=1]Before competition start I made a personal promise to myself that no matter what happened, I was going to follow through, push, and finish the project -- even if that meant that the project was going to be shipped incomplete... even if that meant that I was going to have to finish the project after competition end.
  13. Here is team Bytetroll's submission.  Requires Java 1.8 be installed.   https://www.dropbox.com/s/10vvhhgfhom6k9i/team_bytetroll_runic.zip?dl=0
  14. [font=calibri]As 6:30 AM rolls in, I find myself wrapping up day two of this competition. While I found myself tremendously lucky today, once again, I started off rocky. I went to start programming this morning, only to find that my Mac Mini wouldn[/font][font=calibri]'t boot. Thankfully, I was smart enough to push my code to Git [/font] [font=calibri]before shutting down last night.[/font] [font=calibri]Despite everything, I was able to make some serious progress on the programming side of things. I was finally able to wrap up my UI and audio playback libraries -- getting sound and textures in game. I was extremely lucky to have Riuthamus take time out of his busy schedule to lend me a hand in the art department. With out [/font] [font=calibri]him, I'd be screwed.[/font] I've attached a screenshot of my current progress to this post. [font=calibri]- Byte[/font]
  15. It is 12:39 AM here, which officially marks the end of day one for me. Even though I have competed in the "Week of Awesome' before" I was not sure what to expect going into this years competition. In past years, I had competed as part of "Team Slaughterhouse." During those runs, I had the luxury of not only another skilled programmer and artist, but of the fact that every year, our team had all of the original members. This year, however, everyone from Team Slaughterhouse was busy with real life, so I ended up having to take this one alone. To make matters worse, I realized early on (a few weeks before the start of the competition) that being a one man team, I would need to have fast turnaround time on the code, as I've never done real art (short of your typical programmer art). Furthermore, I knew ahead of time that I wanted to use a language that easily target all of the required competition platforms. For me, this was a critical point, as a few months ago, I changed my daily driver from a Windows box to an OS X box, and there was no way in hell I was going back to Windows. Because of this, I chose Java as my language choice. While I have many years of experience with Java, all of it is in business applications. Up to this point, I had never attempted to write a game in Java, as I am a long time C and C++ game programmer; generally preferring those languages to others. Moreover, I felt very comfortable with the tools I had at my disposal. Because I am a longtime fanboy of IntelliJ, I had the perk of a slew of various custom plugins, as well as a fully editor integrated Perl-based project management system that not only handled all of my cross-platform compiling, packaging, and debugging, but that also managed my version control repositories, and having countless other other tools and utilities for speeding up development. Despite all of the aforementioned, I found myself off to an extremely shaky start. I had taken the previous week before the competition to plan and prepare for the epic (lvl 85+) quest I had ahead of me. Because I didn't have the backing of a team, I knew that what ever route I chose would have to A) have the ability to easily incorporate not one, but two themes, as well as, B) be a small enough project to undertaken by myself -- especially given the fact that I had little to no artistic skill or experience. Due to this, I decided on creating a slot machine simulator/game. Knowing I would need as much time on the art assets as I could get, I spent the following six days writing a small boilerplate game framework. I had originally planned to use "LibGDX" as the core of this framework, so I did a little API reading and took special care to ensure that the framework I wrote did not reproduce functionality provided by LibGDX, as well as provided only the bare minimum amount of code I needed to get started. My thought was to merge in LibGDX when I needed it; linking in the jars like any other Java dependency for any other project. However, this kind of stuff always seems to work better in theory than in practice -- especially at crunch time. Come competition start (12:01 AM), I went to link in LibGDX -- after a long 15 hour coding sesh with no sleep from the night before, only to find myself spending the next four hours fighting the "old-style" builds I had downloaded. I was aware that LibGDX converted their build pipeline to Gradle a while back, but I try to stay clear of Gradle, if given the option (we use it at work, and it makes me want to cry). After a long period of frustration trying to get the old-style builds to properly link and compile, I broke down and decided to download the Gradle builds thinking it was going to be a typical Gradle install job. Instead, I was presented with a project wizard that made me generate a new project. While this would normally would only slightly erk me, I found myself getting pissed off with LibGDX's 'my way or the highway' approach -- especially since it just nullified by entire custom build pipeline (which is something I have come to depend on). After much cursing, I got back into my programming game; scrapping my build pipeline and writing a new one in Perl. I thought all was back on track until I went to start back on the game code and found that my 30 hours worth of framework prep was in the same boat as my build system. However, I was able to spend a good portion of the rest of my day getting stuff back in working order; thankfully finding myself back on track. We will have to see what day two brings. Peace out Bytetroll