Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
16. November 2018


The source code to the indie game Delver was just released under the GPL2 license on Github.  The release includes full source code to the engine and editor, but does not contain the binary assets needed to run the game.  Delver itself is available on Steam and can be purchased here.  Delver is a 3D roguelike game, a bit of a mashup between Spelunky, Minecraft and Ultima Underworld.  The source code is written in Java and is configured to use  the IntelliJ IDEA IDE.

Delver is described as:

Delve into the shifting dungeons on your hunt for the Yithidian orb, but getting it might just be the easy part. Delver is a single player first-person action roguelike dungeon crawler, just like you wished they used to make.
Slay monsters, blast wands, hoard potions, and loot everything.

  • A silky smooth mix of 90s FPS combat with classic RPG mechanics.
  • In these dungeons once you're dead you stay dead. Permadeath means that when you die, you begin each run into the dungeon anew.
  • Tough as nails gameplay will test your skills, no grinding will save you here.
  • A procedural dungeon that will keep you on your toes, no two runs will ever be the same.
  • Delicious chunky pixels!


If you are interested in checking out the Delver source code, be sure to watch the following video for instructions on how to install, navigate and run the source if you are new to Java or IntelliJ development.

GameDev News


9. October 2018


Today Mojang announced they will be partially open sourcing the Minecraft game engine, starting today with two key libraries, with additional portions of the game engine being released over time.  The released Java source code is available on GitHub under the MIT open source license.  The two parts released today are composed of Brigadier and DataFixerUpper.


Details from Minecraft.net:

Well, the lovely folks on Stockholm's Minecraft Java team are giving you just that, by opening some of Minecraft's code as libraries so they can be used however you like! Want to use them to improve your Minecraft mods? Great idea! Want to use them for your own projects? Go for it, just don't forget to credit us! Want to use them to help improve pieces of the Minecraft Java engine? Thanks, we really appreciate it!

On Brigadier:

“I’m so proud of that name!” Nathan says. “Brigadier is the name of the command engine that Minecraft uses.” Brigadier is also the first library we've opened up!

“So in the game you can type something like /give Dinnerbone sticks and then that goes internally into Brigadier and breaks it down into pieces. Figures out what are you trying to do with this random piece of text.”

On DataFixerUpper:

“The name is so stupid that we had to keep it,” explains Nathan, unapologetically. DataFixerUpper does exactly what it sounds like, and it's one of the most important parts of the Minecraft game engine. It's also the second library we're opening up!

“The problem that we have in Minecraft, that I’m pretty sure every game has, is that data changes over time,” says Nathan. “we add a thing into Minecraft and then we kind of have to change how we store level data, how we store all the save files and stuff to accommodate it.

On the future:

The Java team will be opening up more libraries soon and we'll update this article when they do. One library under consideration is Blaze3D - a complete rewrite of the render engine that we're aiming to implement for 1.14. For now, why not use your programming expertise with our existing libraries? Don't forget to leave feedback on the GitHub page or reach out to Nathan on Twitter!


The video:

GameDev News


5. July 2018


AppGameKit is an interesting game framework, with both a higher level basic like layer to get started and a lower level C API if you want to get a bit lower level.  I have previously featured AppGameKit in the Closer Look series, if you are interested in learning more.  Thanks to user Hockeykid, you can now use AppGameKit with the Java and Kotlin languages.


Now you can utilize the power of App Game Kit with the flexibility of Java or Kotlin. Java/Kotlin offer the perfect alternative to Tier 1 due to the simple yet very powerful and versatile syntax.


Here a just a few of the Benefits
Object Oriented Programming
Java & Kotlin are built around OOP using modern and well known concepts such as Classes, Interfaces, Inheritance, etc. These allow for clean, elegant, and organized code that is both reusable and extensible
Vast Libraries
Java & Kotlin have a wide range of both 1st party and 3rd party libraries that can add lots of functionality from basic Data Structures (Queues, Linked Lists, HashMaps, etc) all the way to libraries for Gesture Recognition, Digital Signal Processing, etc.
User Interface
Want to make a desktop tool in AppGameKit? Kotlin & Java have plenty of different libraries for UI like JavaFX, AWT, or Java Swing which will work alongside AGK.
Supported Platforms
Windows
Linux
Future Platforms
Mac OSX
Android


Learn more about the release and how to get started in this forum post.

GameDev News


15. February 2018


Kotlin is a new open source language being developed by JetBrains, the folks behind such IDEs was IntelliJ, WebStorm, CLion and tools like ReSharper.  Version 0.6 of Kotlin Native was just released yesterday with support for Java 9, Objective-C container interop improved debugging and of course several bug fixes and improvements.  Kotlin is a JVM based language that essentially aims to be a better Java, more expressive with less typing while fixing a number of the languages warts.  Kotlin/Native is the technology that enables you to compile Kotlin apps directly with no need for a VM.

Kotlin

Details of the release from the Github page:

Support multiplatform projects (expect/actual) in compiler and Gradle plugin

  • Support first embedded target (STM32 board)
  • Support Kotlin 1.2.20
  • Support Java 9
  • Support Gradle 4.5
  • Transparent Objective-C/Kotlin container classes interoperability
  • Produce optimized WebAssembly binaries (10x smaller than it used to be)
  • Improved APIs for object transfer between threads and workers
  • Allow exporting top level C function in reverse interop with @cname annotation
  • Supported debugging of code with inline functions
  • Multiple bugfixes and performance optimizations

GameDev News


22. September 2017


LWJGL, the Light Weight Java Game Library, just released version 3.1.2.  LWJGL is a series of Java bindings for several underlying media APIs such as OpenGL, OpenAL and Vulkan.  This release also added OpenVR and OpenEXR support among other changes and fixes.

Details from the release notes:

This build includes the following changes:

Bindings
  • Added OpenVR bindings.
  • Added Tiny OpenEXR bindings.
  • Added Yoga bindings.
  • bgfx: Updated to API version 41 (up from 34)
  • glfw: Updated to pre-release 3.3.0 version (up from 3.2.1). Includes many fixes and new features:
    • Last error code query (glfwGetError)
    • Requesting attention from the user (glfwRequestWindowAttention)
    • Platform dependent scancodes for keys (glfwGetKeyScancode)
    • Window maximization events (glfwSetWindowMaximizeCallback)
    • Window attribute modification (glfwSetWindowAttrib)
    • Joystick hats (glfwGetJoystickHats)
    • Library initialization hints (glfwInitHint)
    • Headless OSMesa backend
    • Cursor centering control (GLFW_CENTER_CURSOR)
    • macOS: Cocoa hints (GLFW_COCOA_RETINA_FRAMEBUFFER, GLFW_COCOA_FRAME_AUTOSAVE, GLFW_COCOA_GRAPHICS_SWITCHING, GLFW_COCOA_CHDIR_RESOURCES, GLFW_COCOA_MENUBAR)
    • macOS: Vulkan support via MoltenVK
    • X11: Moved to XI2 XI_RawMotion for disabled cursor mode motion input
    • EGL: Added support for EGL_KHR_get_all_proc_addresses and EGL_KHR_context_flush_control
  • jemalloc: Updated to 4.5.0 (up from 4.4.0)
  • LibOVR: Update to 1.14.0 (up from 1.10.0)
  • lmdb: Updated to 0.9.20 (up from 0.9.18)
  • NanoVG: Added support for fallback fonts.
  • nuklear: Updated to 1.37.0 (up from 1.29.1, with the new versioning)
  • OpenAL: Added AL_SOFT_source_resampler extension.
  • stb
    • Updated stb_dxt to 1.0.6 (up from 1.0.4)
    • Updated stb_easy_font to 1.0 (up from 0.7)
    • Updated stb_image to 2.15 (up from 2.13)
    • Updated stb_image_resize to 0.94 (up from 0.91)
    • Updated stb_image_write to 1.05 (up from 1.02)
    • Updated stb_perlin to 0.3 (up from 0.2)
    • Updated stb_rect_pack to 0.11 (up from 0.10)
    • Updated stb_truetype to 1.15 (up from 1.12)
    • Updated stb_vorbis to 1.10 (up from 1.09)
  • tinyfiledialogs: Updated to 2.8.3 (up from 2.7.2)
  • Vulkan: Updated to 1.0.49 (up from 1.0.38)
Improvements
  • MemoryStack: Increased default stack size to 64kb (up from 32kb)
  • Shared library loading can now utilize a ClassLoader specified by the caller. (#277)
  • Significantly reduced DEBUG_MEMORY_ALLOCATOR and DEBUG_STACK overhead in Java 9 using the new StackWalker API.
  • Migrated windows builds to appveyor and updated to Visual Studio 2017 (up from 2015)
  • EGL: The core API now includes javadoc links to the Khronos references pages
  • OpenGL ES: The core API now includes javadoc links to the Khronos references pages
Fixes
  • Assimp: Struct member nullability fixes
  • Linux: Removed dependencies to newer GLIBC versions.
  • LibOVR: Fixed layout of the ovrInputState struct.
  • OpenAL: Removed buffer auto-sizing from alcCaptureSamples. The number of samples must now be specified explicitly, similar to alcRenderSamplesSOFT.
  • Vulkan: Function addresses are now retrieved only once, using the optimal method for each function type.
    • This avoids warnings on pedantic validation layers.
  • Fixed callback invocation bugs on 32-bit architectures.
  • Fixed various javadoc formatting issues (#308)
Breaking Changes
  • Mapped more integer parameters and return values to Java boolean, that were missed while working on #181.
    • Xlib's Bool
    • OpenCL's cl_bool
    • DynCall's DCbool
  • Moved JNI global reference functions from MemoryUtil to the generated org.lwjgl.system.jni.JNINativeInterface.
  • The Vulkan capabilities have been split into two classes: VKCapabilitiesInstance and VKCapabilitiesDevice.
    • Flags for core Vulkan versions exist in both classes.
    • Flags for instance extensions exist only in VKCapabilitiesInstance.
    • Flags for device extensions exist only in VKCapabilitiesDevice.
    • Functions that dispatch on VkInstance or VkPhysicalDevice exist only in VKCapabilitiesInstance.
    • Functions that dispatch on VkDevice and device-derived handles exist only in VKCapabilitiesDevice.
    • Bootstrapping functions can be retrieved with VK.getFunctionProvider().

GameDev News


See More Tutorials on DevGa.me!

Month List