Blogs - Admer456

In my last blog, which was about 3 years ago, I showed some screenshots from a game I was working on. Back then, I was finishing high school, approaching the end of my relatively carefree era in life. The main thing I was worrying about at that time was getting 1st place on that gamedev contest, hosted by the college I later signed up for.

And 1st place I won. I will spare you the details of how fabulous that felt. Making a game on my custom version of the Quake 3 engine is something I really enjoyed doing, and the idea of pursuing something like that as a "modder turned indie dev" seemed quite attractive. Imagine: making games in a way similar to modding Half-Life! That would've been the dream.

However, there have always been a few things that irked me with idTech engines, and I warn you, this will get a little technical:

• Quake 1 to 3's engines do not have skeletal animation
• Additionally, no physics engine
• Additionally, written in C when I prefer C++
• Doom 3's engine, the one that has all that, has too much stuff that I'd like to change
• They're all GPL-licenced, when I prefer the MIT licence
• Usually have ancient texture & model formats

To put it shortly, Quake engines needed too much work to add some features I wanted, and the Doom 3 engine needed too much work to change or redo some of the existing systems.

Fundamentally it all boils down to personal preference and one's needs for a project. If you gave me any of these and a concrete game design, sure, I'd be able to make it. However, I'm not only after the idea of making finished games - I want to thoroughly enjoy the process and feel completely at home while doing so.

Dreams turn into visions

That's why, in September 2021, I finally let myself go and started working on a game engine. Initially, the plan was very simple: a spiritual successor to my idTech 3-based engine. It would have had retro sort of graphics just like idTech 3, maybe with some slight improvements, with the addition of a physics engine and a vegetation system so it could work for relatively open environments with lush vegetation.

Kind of a blend between CryEngine 1 (Far Cry's engine) and idTech 3, you could say. Then I started having ideas: I could have a plugin system, I could have different renderers as plugins, I could have different audio systems as plugins, and so I designed the engine with this great modularity in mind.

Guess what also happened in September 2021: I started college! As such, I had barely any time to work on the engine. I actually managed to commit a few bug fixes to it during one of my Programming classes. After a very slow year in development, I managed to get a 5-sided polygon to render, together with an external developer console, a basic plugin system, and a Source-style file system where I could mount other games.

All those systems worked together to eventually display this little polygon, and the future looked quite bright. I was taking it nice and easy and I had a plan. However, in November 2022, Godot 4 got a new beta release.

Visions evolve

Godot 4 looked very shiny and fancy, and I was certainly lured by it. It's a lightweight engine, supports C# scripting, and you can do a lot with it. I thought to myself: what if I basically just used Godot to render things, and I had my own workflow? You can compare it to what Facepunch did with Source 2, they basically wrote their own engine-like system on top of an actual engine.

This did mean I had to rewrite everything in C#, and so I did. The plugin system, the console system and so on. Eventually I wrote a tool that would compile Quake and Half-Life maps into my engine's own level format. That way I was able to open up my idTech 3 game's levels in TrenchBroom, and simply export them to my engine.

Then, however; Godot started showing some cracks on its surface. It wasn't quite a perfect option for this sort of project. If you do things the "Godot way", it'll work perfectly fine. Whatever I was doing was the complete opposite of that, and it would've led to a massive uphill battle with Godot. I had a feeling these flaws would eventually reach me, that's why I planned for them in early 2023.

Something that happened around this time, specifically as of spring 2023, I got a job! So, even less time. Despite that, in January of this year, I decided to do something rather brave. Or stupid, depending on how you look at it.

Visions revolve

I basically decoupled Godot and Elegy, making it into a "real" engine, so to speak. This meant I now had to write my own rendering code, and later all the audio, UI and physics stuff. We're kinda back to square one now!

Decoupling allowed me to take a look at the engine's design as a whole, and think. There were several dirty hacks inside Elegy so that it could run under Godot, and the map compiler tool could not utilise any of the engine's systems (e.g. game folder mounting) because of the way things worked. This allowed me to finally fix all of that.

There is a lot of nuanced stuff behind all these decisions, simply too many to write about in a single blog. My priority for now is to render textured models and levels, then I can do physics stuff and a bit of basic game stuff. Really hoping to see a very basic mini game in summer.

Where I am now

Right now it's a cloudy April over here in Bosnia, and I'm just occasionally chipping away at this thing. Of course, I cannot forget my side projects: Half-Life mapping series, Half-Life programming series and a few other things.

I initially wanted to write about how I gradually did less and less Half-Life modding stuff, but this works too. The thought of making a cool little HL mod occasionally crosses my mind, or to actually continue one of my existing mods (like the CS2 smoke one, or real-time moss), however I'm just too busy with other things.

There are also so many other things I did not even mention: learning the guitar, obtaining a driving permit, going on a boat trip to Croatia and seeing the Sponza Palace in real life, and many more. I hope to write here again, maybe in some 6 months or so. Thanks for reading!

I'm 19 now. The cake was good. Also, happy new year. B)

I've been working on a game in my custom engine and, so far so good:

Very happy with the tech so far. It's a heavily modified Quake 3 engine. We'll see where this goes!

So, it looks like I've become an adult. Yay.

The last 6 months have mostly been amazing except for the loss of two friends, one of which is gonna haunt me forever, but I won't talk about that here. :3

Time to see what I've been doing for the last few months:

A Valentine's Day map, by tradition. Every Valentine's Day, I make a map which has a heart and whatnot. Although, this year I wasn't too happy with it, so, I decided not to put it up anywhere. Though, when I showed it to some people afterwards, they liked it a lot, so I guess it wouldn't have been a bad idea anyway. Oh well. :P

A Yugo 45 model. Heh. It's for my idTech 4 game, but chances are, I'll use it in my HL mod as well. (Utopia at Stake, if you're wondering)
Other than that, I've made some more stuff like the M-3650 multimetre, MP5-SD6, Beretta 92, a screwdriver, a combat knife etc.
I'm working on a techno-stealth game set in late 80s Yugoslavia, so, there will be stuff to see. I hope.

I discovered a neat little way of manipulating world vertices in Half-Life. Here's a link to the video, displacing a vertex along the Z axis in a wavy fashion. It could probably be used for deforming terrain upon explosions, or something like that. All I know is, I won't be doing much with it until ADM reaches 0.5 or so.

Now, onto some real-life stuff:

I've been working on some sort of digital synthesizer. The thing is, it has a proximity sensor, which will allow the performer to bend the pitch by raising one hand in the air. Higher the hand position, higher the pitch, and vice-versa. I still haven't implemented this pitch-bending part, heh. I should totally get to it soon.

Anyway, thank you for reading this, I hope you have a good day/night, whatever your time zone is. :)

Back in action, once again.

Current focus: car prototype. Will be shown in Episode 4.

New features:

- trigger_date and trigger_date2. Time-dependent entities that will only trigger something if a certain date is matching the set date in an entity. This means you can trigger stuff on Christmas or whatever you can imagine. 3 AM horrors!

- major addition to view bobbing. Now not only does the viewmodel sway, it reacts to the player jumping, turning around fast and so on. The viewing camera is also affected by this.

- a car prototype that is starting to work. Includes RPM, torque curves, gear shifting and wheel traction stuff. :D

- func_loadbar. Entity which moves from 0 to 100%. Every button press will currently iterate by 2%, but that will soon be configurable per trigger. Also, a mapper can set up to 5 percentage levels at which something will be triggered.

- PHYSICS!!! Real-time physical boxes. However, the current implementation is completely serverside. Might wanna look into optimising it for multiplayer, after I'm able to load map geometry for collision.

Video:

Also, some work has been done on the UI colours. :)

Might set up a mod page. Maybe. Tell me if you think it's a good idea. :)

Now that my idTech 4-based game is done, for a Bosnian gamedev competition, I can return to ADM and Utopia at Stake.

So, what has happened?

I improved the chair physics a bit. I think I'll keep this as an Easter egg vehicle.

And now we have a couch, which uses the exact same entity class as the chair! YES! They are literally the same class in the code, yet it can use either a MDL model made with something like Max, Blender etc., or a map model made out of brushes in the map editor. ;D

I'll be gladly looking for some multiplayer stress testing of these vehicles one day, probably in summer. Soon to be added is a seat switching system, so vehicles with multiple seats can be an almost seamless experience.

Pay attention to the upper left corner. It is what this grunt "sees".

I have accidentally added an entity that mimics the 'stealth area' from CS:CZ:DS. NPCs absolutely cannot see through it. A buddy of mine wanted it for his mod, and that's how I ended up coding this feature. However, it has a bug where bullets can't go through it. They can if you are inside of the stealth area, but otherwise not quite. xd

Recently, I was digging through some sound files and I realised, I'll definitely focus on getting some FMOD in the mod. Regular 8-bit PCM just sounds awful. Imagine having only 256 levels of amplitude instead of about 65k. And OGG support, mmm...

Lastly, I recently met someone who seems to be quite interested in the project. And oh my, it made my heart bump and jump and melt, and I was crying out of joy. Can't describe that feeling. :D

And don't worry, there will be an episode 3 of this blog series. Expect a mod page when I'm done with the technical base. That will be when I reach version 0.1, a.k.a. Milestone 1, when we have driveable cars, at least partial FMOD support, and perhaps partial Bullet support. We'll see. Until next time, folks! ^^

0x0017
0x0002
0x07E3

Hint: hex to dec :)
Solution: 23 02 2019 - and 17 in the title. My 17th birthday!
Have fun solving! (even tho' it's dumb easy)

In the meantime, I'm gonna talk about something. I've decided to write a tutorial series for HL. Specifically, coding. :)
Mapping tutorials are everywhere (and I wrote 30+ of them myself, albeit mostly on GameBanana, and two on TWHL), as well as skinning/modeling tutorials.

Right now, I've got about 2 coding tutorials on GameBanana and I'm planning to port them to websites like ModDB and TWHL. The reason behind this is because some people like some sites more than others, and thus some people also visit some sites more than the others. Also if one site goes down, the other will be up and running (but then again, we have Web Archive xd).

Some people think Half-Life modding is dead, but not so quite. Coding, however, is definitely one of the branches with the least amount of people. I can count only about 5-6 HL coders these days, and at least 20 coders who used to be active coders back in the early 2000s. So yeah, it'll be in VS 2017, using an updated HL SDK fork and it'll be more than just copy-paste, because I'm planning to write this stuff for beginners. :)

Custom control subsystem - done
Vehicle base - mostly done, needs physics
Physics overlay - ongoing

Now you can hold down some custom keys and they will do something. The difference is that there are single key-stroke keys (e.g. firemode switch - you can hold it as long as you want, but it'll only be "pressed" for one frame), and keys that are held down (e.g. walk forward). Keys that are held down are rather tricky since you have an unsigned short int to store the bits. Walk forward, backward, left, right, turn left, right, jump, attack etc. each take up 1 bit in that integer, and all 16 of them are taken up. Hell no, I ain't gonna mess with that.

So, I decided to do a workaround which turned out to be pretty successful. I did a secondary flashlight, a sprint key and custom vehicle controls. :D

Speaking of vehicles:

vehicle_base

It's a really really basic vehicle. As basic as it gets. You can enter it and exit it. But of course, I thought I could also try this:

A chair that you can ride. Progress. ;)

Hippity hoppity little chair on the wall
Chair vs. terrain

The vehicle system was pretty much made from scratch. I didn't base it off func_tracktrain or anything like that. However, it's going to need some physics, and I'll see what I can do about that. It's going to be wonderful. :)

The video is done. :)

So, the HUD customisation consists of about 15 parameters, and you will eventually be able to change them all in the main menu:

Sadly, since GameUI code is hardcoded into GoldSrc, I don't think I'll be able to make a nice tab in the Settings menu that will allow a nicer preview of the TDTR* curve.

TDTR is basically a line that shows how red your HUD is, depending on the health. It has parameters like health level for HUD flashing, frequency of flashing, flashing type, flashing wave, TDTR negative coefficient (inverse steepness), TDTR shift etc. The first 4 HUD CVARs I've added were red, green, blue and alpha, but I felt that wasn't enough. :3

I might be able to make a program that helps you preview the TDTR curve and HUD flashing, and then configure it. I'll have to add an option for Half-Life's original HUD behaviour too. It just goes constant red below 20 or 25 HP, otherwise it's another constant colour.

The crowbar shaking needs to be a little slower, hmm.
I'll probably separate v_angles from angles for env_viewsway too, so you can actually change the view and playermodel angles separately. In fact, this should allow for the rotation of brush entities and NPCs (yes, drunk Barneys) since all entities have the "angles" keyvalue, but I'm yet to test this feature.
trigger_valueop has support for about 140 keyvalues right now, however, I must still write support for every single entity (including the world, it's got 3 or 4 custom keyvalues).
trigger_difficulty has easy, medium, hard and the "not" variants of the three. It seems to work perfectly and the "not" variants were implemented after the video.

Once I get enough of the mod done, I'll eventually put it up on a mod page. BTW AdmSrc doesn't have to do anything with Source. It's short for "Admer's source", which is the source code of the project. The mod itself is still unnamed, but I might end up reviving my old HL mod, so we'll see. But not really "An unknown game". I'll rename it but I'll still keep the initials "AUG".

* The Deader The Redder

From now on, I might call the blog "AdmSrc" instead of "That old HL mod of mine".

Some of you might remember a mod that used to be called "Admer: The Game", and was then renamed to "An unknown game". I do for sure. It was a failure but also a success.

In 2015, I started working on my first (and only) HL mod. I had a couple of ideas that I wanted to realise, but I failed. I canceled the mod in 2016 because:

• I was an awful noob at programming.
  It was a time when I had just gotten into C++. My only prior programming experience back then was QBasic. And even then it wasn't much. I didn't know about data types, functions, anything. Just basic input, if statements, goto etc. Barely enough to make a primitive text game.
  All my code for the mod was never really "mine", since I just copy-pasted it from tutorials. And I never learnt anything.
• I was losing motivation to work on the mod. As my mapping skills grew, I realised how terrible my mod's maps were and I was too lazy to fix and redo everything from scratch. The same goes for other skills.
• I was lazy. All my ideas were in my head, I was too lazy to write them down and I had no mod design document, no organisation, no anything. I simply didn't know where I was going and what to do, so I half-baked everything. (ahem, quarter-baked)

Recently, I happened to see the mod's page here. I remembered the old stats, suddenly. It used to have 10s, sometimes 100s viewers a day, and now it varies between 0 and 1. So I thought "How great it'd be to do this again, except with the skills I have now?"

Last year, I was analysing some progress of my skills. Since 2015, I've improved in mapping a lot, in texturing a lot, video editing significantly (I mean, not much to be improved since I've been video-editing since the age of 8), sound editing a lot, music production so-so, but there was just that one skill that stagnated.

It was programming. In late 2017, I started panicking due to the fact that I knew I'd have programming class next year. So I wanted to prepare myself.

I just needed a good start. Something to jumpstart my learning. And in November 2017, a guy came into our classroom, recording a promo video for the high school. We were having IT class, and our professor told us to open Dev-C++ and pretend to be typing something. They all pretended. Except me.
I opened up a source file, saw how it's written, memorised the syntax and commands within a minute, and wrote a program. When I returned home, I got VS 2010 Express, registered it and decided to make GMan killable.

It was an unbelievable experience for me back then. I actually understood something for once. And all he was doing was setting his health to 50% of his max health every time he was attacked:

pev->health = m_iMaxHealth / 2;

Now that was just the beginning. I called my little brother in and showed him that, and he was so amazed. He laughed in disbelief, because all the time he knew about HL (since the age of 2 or 3), he knew that you just can't kill GMan.

However, it's been a long while since 2017. In late 2018, however, I got into C++ again. I got my new PC in July, and that meant I could finally get my hands on Visual Studio 2017, a nice step up from Visual Studio 6.0, 2005 Express, 2009 Express and 2010 Express. My 2007 laptop simply didn't have enough space for 2012, 2015 nor 2017.

And that meant a new beginning, a new age. I was looking for some libraries that can enable me drawing stuff to a window, and boy I found one: SDL. I learnt quite some C++ for those few months, and coming back to the Half-Life SDK once again, I finally understood most of the stuff in it. It felt amazing to finally understand something that troubled you for a few years. That age was an age of learning something I've always wanted to learn.

I had prototyped a function in AngelScript for Sven Co-op (was my first time tinkering with AS scripting), and then I decided to port it to the HL SDK.

Now, what now? Well, I'm working on a small mod base that I'll eventually release. Once the code base is done and the example assets, I can move on to the revival of my old mod. It'll be a big one. :)
What I've done so far is this:

• proper semi-auto for the Glock, and an intentional secondary fire mode that refills your ammo (also planning to do tactical reload for all weapons with ammo and mags)
• env_viewsway - the port of my prototyped AS function, as an entity
• trigger_valueop - an entity that changes keyvalues of another entity; it took quite some time to make, lol.
  This entity is so powerful. You can change ANY keyvalue of an entity with it, health, position, animation, animation frame, class name (why'd anyone change that?), anything. I had to modify the base entity class a bit to make this come true.
• trigger_difficulty - I always wondered why HL didn't have this, a trigger that triggers something only if a certain difficulty is set
• util_rotator - an entity that rotates another entity, can rotate around one or two points (think of it as Moon rotates around Earth, and Earth rotates around the Sun); might change it to a trigger_ instead of utility
• util_consoleprinter - a very useful entity for debugging your entity setups
• shaking can now affect players in the air, but env_shake has options for either mode
• crowbar shakes the player's view when you hit something
• a flashy customisable HUD with so many parameters: frequency of flashing, health level at which the health bar goes red, HUD colour (obviously), curve of TDTR (The Deader The Redder - basically how red the HUD is depending on the health level), wave of flashing (can be a sine wave, saw wave, triangle wave, yet to implement the square wave but that'll be very easy), way of flashing (red to fully transparent, constant red, red to your predefined colour), and so on.
• test effect using the EFX API (imploding bullet tracers for now)
• changes to the base entity that allow for this: GetKeyValue and SetKeyValue
  Essentially, the base entity provides a GetKV and SetKV for all the base keyvalues defined in the pev structure. Other base classes (e.g. CBaseDelay) will implement a GetKV2 and SetKV2, which is for their own respected keyvalues that aren't present in the base entity class. And lastly, entities that inherit from these will have GetKV3 and SetKV3 for their own keyvalues. KV is called first, checking for a keyvalue name. If it fails, it calls KV2 with the same argument. If that fails too, then it calls KV3 and sets it. If even that fails, well, GetKV3 will return "null", and SetKV3 will print an error in the console saying there's no such keyvalue.

In the next DevBlog, I'll post some screenshots and perhaps a video of some things in action. :)

For years, I've been using low-end hardware. Even the best PC I've ever had only had an Ati Radeon HD 4650, 2GB of DDR2 RAM, an Intel Pentium Dual-Core processor and a 300GB Hitachi hard drive. It died in summer 2014.

A year before its sudden death, I got a 2012 Fujitsu A512, which had a slightly worse GPU, slightly better CPU, more RAM and a more capacitive HDD. So the performance wasn't much of an upgrade. More like an insignificant downgrade.

After the old PC died, we got a 2007 Fujitsu S7210. Intel GMA X3100, 2GB of RAM, Intel Core 2 Duo T7500 and a 160GB HDD. Originally it belonged to my younger brother, until late 2015, when I stayed at my grandparents' for a week. My parents insisted that I let my brother use the A512 for the time being, and that I bring the S7210 with me.

It was a mistake. Or was it, really?

My brother got spoiled and couldn't stop using my 2012 laptop. He didn't want to switch back once I returned. And I've been using the 11-year-old laptop ever since.

Its performance was awful. Maps would take sometimes hours to compile, rendering videos in Sony Vegas would take ages even at 360p, games had horrible framerates. But it taught me an important thing: optimisation.

Optimisation is an art. You've got a bunch of polygons in a map, but are they all worth looking at? Some of them are unnecessary. Also, most of them aren't even visible when you're standing in some areas. My laptop pretty much advocated that. It's so satisfying when you make some changes to your level, and you gain 5 more frames per second. Additionally, the compiling times are reduced a lot. I once had a map compile for nearly 2h48m. I shortened it down to just 3 minutes by placing some hint brushes and turning some things into func_detail. Basically, VIS (the 3rd part of GoldSrc map compilation; calculates what polys are seen when) had too many portals to handle. I reduced the number of these portals drastically by changing some rocks into func_detail and adding hint brushes (imagine it as placing the portals manually).

So I would say it's a blessing in disguise, as one of my friends said on Discord.

And what now? Why the title goodbye? Am I no longer going to optimise?

Nope. I just drifted away from the topic a little bit. Here's the thing: I'm saying goodbye to my 11-year-old laptop.

It's not going anywhere. It's just getting retired, because a new worker is soon coming into its position. It's got a surprisingly good portfolio too:

CPU: AMD Ryzen 5 1600
GPU: Asus Cerberus GTX 1050 Ti
Memory: 8GB DDR4 RAM
Storage: 1TB HDD and 250GB Samsung 860EVO SSD

I've been waiting 5 years for this moment. The patience will finally pay off. I'll enter a new age, an age of prosperity, peace, high framerates, an age where my room won't get too hot due to the CPU temps, an age where the engine is the limit, no longer the hardware (to a certain extent).

See, I thought that my golden age was gone. When I was 9 and 10, those were the best days ever. I had that HD4650 PC, all my favourite games were there, I was buying PC Play magazines every week, and I had lots of free time. But now I understand that that was only the silver age, followed by a dark age. What happens next will be my true time to shine, hopefully. :]

So, in a few days, it will be time to say goodbye to my old Fujitsu S7210. You've served me well, comrade. Now await your retirement, 140 € a month it will be. :v