Jump to content

Organizing the New Engine

Josh

163 views

The addition of our plugin system makes the engine feel different. There is a stronger distinction between core and non-essential functionality. I removed a lot of third-party libraries from the project and am just focusing on graphics, physics, pathfinding, and other features that are core to the functioning of your game. Things like file importers terrain generation, etc. can be stored away in self-contained optional plugins, or can be part of the editor project, and do not need to reside in the base engine.

I feel like this satisfies both my desire for the core engine to be as focused and streamlined as possible, and for the end user's desire to have infinity features.

I also feel like I want the engine to be as small and "in the background" as possible. I removed the superfluous print statements like "initializing engine blah blah blah..." so that only the useful info gets printed. Your game's log file is not a place I need to advertise my engine. Additionally, I am trying to simplify the game directory as much as possible with as few files as possible.

Here is the only printed output when a program is run:

Running script "Scripts/Start/Autoload/FITextureLoader.lua"
Loading plugin "Plugins/FITextureLoader.dll"...
Running script "Scripts/Start/LoadPackages.lua"
Running script "Scripts/Start/System/ComponentSystem.lua"
Running script "Scripts/Start/System/Error.lua"
Running script "Scripts/Animation.lua"
Loading shader family "Shaders/PBR.json"...
Loading model "Models/Crawler/crawler.mdl"
Loading material "Models/Crawler/crawler.mat"...
Loading texture "Models/Crawler/crawler.tex"...
Loading texture "Models/Crawler/crawlerdot3.tex"...
Loading texture "Models/Crawler/crawler_spec.tex"...
Loading shader family "Shaders/Blinn-Phong.json"...
Loading material "Models/Crawler/crawler_eyeball.mat"...
Loading texture "Models/Crawler/d_eyeball.tex"...
Loading texture "Models/Crawler/crawler_eyeballdot3.tex"...

I got rid of the "Config" folder. Shader families should be placed in the "Shaders" directory (although they can be stored anywhere) and languages can be kept in a "Localization" folder, if you use them.

The shaders folder is now organized with some sanity.

Untitled.png.2c0bd4f9c3313825d7977bf9abc9d47b.png

Materials, languages, and shader familiy JSON files all need to have a root object that indicates the type of asset they are:

{
	"material":
	{
		"color": [ 1, 1, 1, 1 ],
		"emission": [ 0, 0, 0 ],
		"metallic": 0.75,
		"roughness": 0.5,
		"baseTexture": {
			"file": "./wall_01_D.tex"
		},
		"normalTexture": {
			"file": "./wall_01_N.tex"
		}   
	}
}

The "Scripts/Start" directory will now be executed recursively at program start. I hid the required scripts away in a sub-folder called "System" so hopefully no one will delete them.

I have renamed the "Bank" and "BankStream" classes to "Buffer" and "BufferStream". The old class names were a holdover from the days of BlitzMax.

Finally, with UPX I got the size of the release EXE and required DLLs down to 3.5 megabytes.

The whole thing should feel small, efficient, and quick to start. The opposite of bloated.

  • Like 3


1 Comment


Recommended Comments

The small footprint is one of the many reasons why I really like Leadwerks. 

Really happy to see you still going forward with this approach, while making it more flexible. 

  • Like 3

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By jen in jen's Blog 0
      My small project will be called Foregate, it will be a dark medieval Diablo style single player action RPG.
      The graphics will be simple, no PBR, 256x256 map, reasonably low-res models.
      Camera style? Top-down-ish I think? Like in Diablo exactly - and because the camera is not directly in-front of the 3 models, I can get away with low-resolution assets - bonus. Also, with top-down view, I won't have to worry about high resolution sky-boxes. 
      What's my plan for this project?
      I plan to make this project as small and as simple as possible, possibly release it as open-source, and have fun with it of course.
      My previous experience with game development (1-2 years ago?) was amateurish I think, still is now. I want to give it a go again, this time with experience although my skill in C++ is not really that good? Maybe I can improve it in this project.
      More about the game
      The content is not set in stone yet but I have a general idea of how the mechanics is going to look and feel - Diablo-ish obviously. It'll have monsters (ancient & mythical probably), loot when killing a monster, gold as in-game currency, visual grid inventory, player stats (level, strength, agility, vitality, energy, &c.). 
      The game will be single-player. Possibly a coop multiplayer also? I don't have any interest in making massive multi-player. 
      I started my development yesterday with the basic preparations (setting up project environment, &c.), today I made my first step in developing the core components; worker class, game state, task class.
      I have a game state that keeps a single source of truth for the entire application; all game data will be stored in this class as "states". 
      I also have a "Worker" which will do the processing of tasks in the game.
      I also have "object" class, this can be a monster, the player, a weapon, a prop, or an NPC.
      So the idea is to have a CQRS type of interaction between the classes and the data. Any action in the game will be interpreted as "Task" for the Worker class. The worker class iterates through the Task. Tasks can be created by any class interfaced with the Worker class trough "addNewTask" and the new tasks can be of a certain type i.e.: ATTACK, IDLE, SAVE_GAME, EXIT_GAME, the new task will also have a payload data and it's processed according to its task type e.g. an ATTACK with payload "{ Damage: 10, Target: MonsterA }" will reduce the health of MonsterA by 10 - the worker class will change the game state; find MonsterA in MonsterState and reduce its health by 10. 
      I think it's advantageous to have this type of centralized module where all actions are processed; I can do all sorts of procedures during the processes, maybe debug data, filter actions, mutate payloads, and such.
      How much time am I going to put into this?
      A couple of hours a day for 3 days a week maybe.
      So it's all a rough sketch for now and it's heading the right direction. I'll have more to report later on. 

      This is Forgate Castle, minus the castle, in the map Forgate; the starting location for the player. The fortification will have merchants, and quest givers.
       
    • By jen in jen's Blog 4
      I've got a bit of free time on my hands for a while. I plan to take up Leadwerks again and come up with a simple project to have fun with.
      I use VSCode at work and I don't have a Windows machine at the moment. Codeblocks is a bit dated now and I'm not sure if it has all the features to fit my workflow so I can't use it. 
      It's a bit fiddly to build C++ apps on VSCode. There's a prescribed method of setting up your C++ project in the official hubs but I don't think those are necessary in my case, I just need a script that builds the project which I have below.
      By the way, VSCode website is here: https://code.visualstudio.com/
      Have fun.
      Save as build.sh in your project's root folder and run using build.sh or build.sh -r for release. Works for Stable version LW and any previous versions(?) - at least v4.5 (archived). BETA branch (4.6?) doesn't seem to build for me, missing Leadwerks.a file.
      Disclaimer: not really fully tested for bigger projects? I've only tested this with sample projects that have no additional project folder structure in its Source so I'm not sure if the script will propagate its search for CPP files thoroughly and process each file successfully in bigger projects. Back-up project files before running the script for the first time please.
      Updated: 26/02/2020
      #!/bin/sh if [ $1 == "-h" ]; then echo "Build script is set to DEBUG by default. Set -r in first argument of the script to build for release."; exit 1; fi if [ $1 != "" ] && [ $1 != "-r" ] && [ $1 != "-h" ]; then echo "Type build.sh -h to see brief help description."; exit 1; fi debugFlags='-g -DDEBUG -D_DEBUG'; debugLibPath='Debug'; PROJECT_PATH=$( cd "$(dirname "${BASH_SOURCE[0]}")" ; pwd -P ) LEADWERKS_PATH=~/.local/share/Steam/steamapps/common/Leadwerks declare a compiledFiles; declare a includedFilePaths; if [ $1 == "-r" ]; then debugFlags=''; debugLibPath='Release'; fi truncate -s 0 $PROJECT_PATH/build.log echo "Leadwerks Path: $LEADWERKS_PATH" echo "Project Path: $PROJECT_PATH" echo "Compiling source..." if [ ! -d "$PROJECT_PATH/Compilations" ]; then mkdir $PROJECT_PATH/Compilations; fi if [ ! -d "$PROJECT_PATH/Compilations/$debugLibPath" ]; then mkdir $PROJECT_PATH/Compilations/$debugLibPath; fi for f in $(find $PROJECT_PATH/Source -name '*.h' ); do includedFilePaths+=("-I $(dirname "${f}")") done includedFilesJoined=$(printf "%s " "${includedFilePaths[@]}") includedFilesJoined="-${includedFilesJoined:1}" for f in $(find $PROJECT_PATH/Source -name '*.cpp' ); do originalSourcePath=$PROJECT_PATH/Source; compilationsPath=$PROJECT_PATH/Compilations/$debugLibPath; compiledFilePath=${f/.cpp/'.o'}; compiledFilePath=${compiledFilePath/$originalSourcePath/$compilationsPath}; mkdir -p $(dirname "${compiledFilePath}") g++ -std=c++0x $debugFlags -w -fexceptions -msse3 -DDG_DISABLE_ASSERT -DZLIB \ -DPLATFORM_LINUX -D_NEWTON_STATIC_LIB -DFT2_BUILD_LIBRARY -DOPENGL \ -Dunix -D__STEAM__ -D_POSIX_VER -D_POSIX_VER_64 -DDG_THREAD_EMULATION \ -D_STATICLIB -DDG_USE_THREAD_EMULATION -DGL_GLEXT_PROTOTYPES -DLEADWERKS_3_1 \ -DLUA_USE_LINUX -D_GLIBCXX_USE_CXX11_ABI=1 -D_CUSTOM_JOINTS_STATIC_LIB -fPIC -O2 -std=c++0x \ $includedFilesJoined \ -I $LEADWERKS_PATH/Include/Libraries/VHACD/src/VHACD_Lib/inc \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dMath \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dgNewton \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dContainers \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dgCore \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dgTimeTracker \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dgPhysics \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/sdk/dCustomJoints \ -I $LEADWERKS_PATH/Include/Libraries/tolua++-1.0.93/include \ -I $LEADWERKS_PATH/Include/Libraries/lua-5.1.4 \ -I $LEADWERKS_PATH/Include/Libraries/freetype-2.4.7/include \ -I $LEADWERKS_PATH/Include/Libraries/enet-1.3.1/include \ -I $LEADWERKS_PATH/Include/Libraries/RecastNavigation/DebugUtils/Include \ -I $LEADWERKS_PATH/Include/Libraries/RecastNavigation/Detour/Include \ -I $LEADWERKS_PATH/Include/Libraries/RecastNavigation/DetourCrowd/Include \ -I $LEADWERKS_PATH/Include/Libraries/RecastNavigation/DetourTileCache/Include \ -I $LEADWERKS_PATH/Include/Libraries/RecastNavigation/Recast/Include \ -I $LEADWERKS_PATH/Include/Libraries/libvorbis/include \ -I $LEADWERKS_PATH/Include/Libraries/NewtonDynamics/packages/thirdParty/timeTracker \ -I $LEADWERKS_PATH/Include/Libraries/libvorbis/lib \ -I $LEADWERKS_PATH/Include/Libraries/libogg/include \ -I $LEADWERKS_PATH/Include \ -I $LEADWERKS_PATH/Include/Libraries/zlib-1.2.5 \ -I $LEADWERKS_PATH/Include/Libraries/zlib-1.2.5/contrib/minizip \ -I $LEADWERKS_PATH/Include/Libraries/freetype-2.4.7/include/freetype \ -I $LEADWERKS_PATH/Include/Libraries/freetype-2.4.7/include/freetype/config \ -I $LEADWERKS_PATH/Include/Libraries/LuaJIT/dynasm \ -I $LEADWERKS_PATH/Include/Libraries/glew-1.6.0/include \ -c $f -o $compiledFilePath; compiledFiles+=($compiledFilePath) done compiledFilesJoined=$(printf "%s " "${compiledFiles[@]}") compiledFilesJoined="/${compiledFilesJoined:1}" echo "Building project..."; g++ -o $PROJECT_PATH/${PWD##*/} $compiledFilesJoined -s "$LEADWERKS_PATH/Library/Linux/$debugLibPath/Leadwerks.a" -ldl \ -lopenal -lGL -lGLU "$LEADWERKS_PATH/Library/Linux/libluajit.a" $PROJECT_PATH/libsteam_api.so \ -lX11 -lXext -lXrender -lXft -lpthread -lcurl "$LEADWERKS_PATH/Library/Linux/libopenvr_api.so" echo "Build complete. See build.log for result summary." About the game: I'm kind of disappointed with the Action RPGs released recently. I want to give the genre a shot, present my own interpretation of how it should look like? Dark, medieval, less electric, modest if not rare use of glow shaders... maybe?

    • By Josh in Josh's Dev Blog 0
      A new update is available for beta testers. This adds a new LOD system to the terrain system, fixes the terrain normals, and adds some new features. The terrain example has been updated ans shows how to apply multiple material layers and save the data.

      Terrain in LE4 uses a system of tiles. The tiles are rendered at a different resolution based on distance. This works great for medium sized terrains, but problems arise when we have very large view distances. This is why it is okay to use a 4096x4096 terrain in LE4, but your camera range should only show a portion of the terrain at once. A terrain that size will use 1024 separate tiles, and having them all onscreen at once can cause slowdown just because of the number of objects. That have to be culled and drawn.

      Another approach is to progressively divide the terrain up into quadrants starting from the top and working down to the lowest level. When a box is created that is a certain distance from the camera, the algorithm stops subdividing it and draws a tile. The same resolution tile is drawn over and over, but it is stretched to cover different sized areas.

      This approach is much better suited to cover very large areas. At the furthest distance, the entire terrain will be drawn with just one single 32x32 patch. Here it is in action with a 2048x2048 terrain, the same size as The Zone:
      This example shows how to load a heightmap, add some layers to it, and save the data, or load the data we previously saved:
      --Create terrain local terrain = CreateTerrain(world,2048,32) terrain:SetScale(1,150,1) --Load heightmap terrain:LoadHeightmap("Terrain/2048/2048.r16", VK_FORMAT_R16_UNORM) --Add base layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) --Add rock layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) terrain:SetLayerSlopeConstraints(rockLayerID, 35, 90, 25) --Add snow layer mtl = LoadMaterial("Materials/Snow/snow01.mat") snowLayerID = terrain:AddLayer(mtl) terrain:SetLayerHeightConstraints(snowLayerID, 50, 1000, 8) terrain:SetLayerSlopeConstraints(snowLayerID, 0, 35, 10) --Normals if FileType("Terrain/2048/2048_N.raw") == 0 then terrain:UpdateNormals() terrain:SaveNormals("Terrain/2048/2048_N.raw") else terrain:LoadNormals("Terrain/2048/2048_N.raw") end --Layers if FileType("Terrain/2048/2048_L.raw") == 0 or FileType("Terrain/2048/2048_A.raw") == 0 then terrain:SetLayer(rockLayerID, 1) terrain:SetLayer(snowLayerID, 1) terrain:SaveLayers(WriteFile("Terrain/2048/2048_L.raw")) terrain:SaveAlpha(WriteFile("Terrain/2048/2048_A.raw")) else terrain:LoadLayers("Terrain/2048/2048_L.raw") terrain:LoadAlpha("Terrain/2048/2048_A.raw") end The x86 build configurations have also been removed from the game template project. This is available now in the beta tester forum.
×
×
  • Create New...