Stitching

Happy 02022020 (Well at the time I started writing this)!

I have good news to report on the space mining rererewrite: It's going really well so far. I have changed the core class structure from previous rewrites.

This time I have spread out the tasks so that the GamePanel isn't doing all the work. Keypresses etc are handed off to the Level class, and it has specific level type classes under it - for space, surface, etc. And later I'll make these totally generic, so you can define any amount of sublevels, of any kind, via config files. The goal is to make the game totally moddable - so much so, the game actually becomes more of a game engine that builds randomly generated top down arcade games.

I have coded the seamless loading of level sectors and just need to code the reloading of the stored sector data. I have that piece done but need to restore the last saved position.

Faded

I am back to work on the arcade-style space mining game. I've ditched the 'teraforming' class for now. The planets are much more 80's retro now. They consist of a configurable surface color and grid color. Dotted over their surface are bases, spaceports, and enemy spawners. The planet surface levels are identical to the space level, but with different elements and slightly different behavior - all of which is configurable in plain text files.

I created a fade effect class. So when the player lands on a planet the screen goes black and the surface scene fades in. The black color, fade speed, and fade in/out are all configurable within the level's settings file.

The goal is to drive the game's elements by config files so users can 'skin' their own games and tweak how it plays solely through the game library files and settings files.

The spawners are next, along with the complex AI and collision detection. Then I'll code the building of upgrades using the gathered minerals.

Fighting Revisited

I have been doing some work on the NetSplit game again. Last night I decided that the game should be part action and part puzzle, as opposed to fully puzzle. It has been a long time since I've defined weapons and fighting scenarios. There have been some changes to the allowed syntax and single items no longer need to be defined in a parent group. So it will be interesting to see how broken the fight engine is.

So far so good. The player is able to punch objects. Before I had the damage messages defined in the weapon object. I may stick with that approach, as long as these messages work as expected.

It would be cool to make weapons that can be hacked, and therefore behave differently. Actually there should be lots of objects that can be hacked. In a previous game I had started, there was some hacking but not really behavior changing etc. I just need to be sure to keep the 'hacking' from being tedious. It is a game, after all - and needs to actually be *gasp* fun.

ReGenesis

When I last worked on the arcade-style space mining game I had achieved an endless universe of randomly generated planets and elements. Minerals and fuel could be gathered. Fuel was burned up and the game ends if the player ran out. Planets could be landed on (Their topography was randomly generated) and walked around. There were enemy bases and the player could shoot.

But I had HUGE problems doing collisions. There were major issues with the navigation and position detection portions of the code. These issues were at the core of the game's logic. They were so bad that I didn't even want to attempt to code enemies.

Now that I am circling back to it I felt that a rewrite was necessary. So tonight I built the core game loop and the coordinate logic. I also coded a movement class and game element class. Wrapping when going off screen is simply a flag same with random repositioning on wrap (For the starscape). Reverse movement is also a flag so that the player can stay in the center and the background moves opposite the key direction for the illusion of the player moving.

I've created a test element to verify the moving etc works. Next I will code the collisions to ensure position checking etc is now good.

Once collision is coded I will begin building the various level types, starfield, planet, maybe even inside bases. Then I will build all the random generation / restoration logic.

So far it is going FAR smoother than the previous attempt.

Back to the Back to the Map

I returned to my work on the terrain builder. My thought was I would update it to build the land masses outward from their centers. I wasn't sure how I was going to go about it. In my head I was seeing it as working in a circular path outward.

The more I thought about it the less I liked it. Fortunately as I was coding the solution hit me. Recursion. So instead of going in circles around the center I would begin at the center with a distance variable set to zero. As I work out, passing that variable to iterative calls, I used it to decrease the likelihood of cells being land further from the center.
Each call checks the current point and calls the function for its neighboring points. The result vaguely looks like a continent crossed with a confetti explosion. When zoomed in to game play distance it actually looks pretty good. It even builds out some ... acceptable mountain patterns.

Now I need to work out collisions, currently it isn't quite right. Actually I need to do some collision work - game wide. Then I need to improve the variety of the terrains based on modifiers specified in the library files.

Back to the Map

I've decided to re-attempt the planet surface generation logic. My previous attempt was ... not so good. So this time around I've decided to keep it simple. The maps it generates are fully ASCII and everything is contained within the main class, no OOP classes etc, just methods within main.

I have some modifiers that will later be passed in to create different types of worlds - temperature, landmass counts, etc. These affect what is created. I start with the polar arctic regions then I create random landmass centers and work out from those.

I'm currently walking up and down the center then east and west from those points. That is working ... Ok. I need to tweak it to work all around the center outward, I think that will give me better shapes.

Once I am happy with those I'll move on to features like mountains, rivers, and lakes.

Then the trick will be making it OOP and converting ASCII to image tiles.

Im-ugh-ges

Progress on the arcade space mining game was going well. I have created a *workable* random terrain building class and got landing on (and leaving) planets coded. This includes storing the generated terrains in case the player leaves then returns. I updated the movement of the level when it's a planet type to keep the player boxed into the generated terrain (it's set really large so they'd have to go for a long time before hitting the edge).

Clearly something was about to go wrong.

It was time to swap out the colored squares of the terrains with terrain images (although it's arcade style, drawing in Java is just a pain - I've tried drawing everything in Java in the past, untenable). I created images for the handful of terrain types, and swapped the colors out for BufferedImages.

Kaboom!

Complete IO and processing meltdown. So I went in and made the terrain a collection of image names, and just had single images of each type and then just drew them in the proper places in the grid. This went much better. But it is still horribly tanked. I'm going to adjust the images sizes and lessen the amount of them. I'll also be making sure I'm not drawing tiles that aren't even on the screen.

Perhaps now is the time to bite the bullet and ditch Java for something more conducive - even though I love Java, and am very comfortable in it now.

Terraforming

The next step in the arcade-style space mining game I'm making is terraforming. I need to be able to build planets randomly. In previous attempts the planet surface was just tiled backgrounds but now I want to build actual world topography.
To do so I'm first building an elevation map then using that to build the terrain tiles. I have a sea level value to determine whether the tile is above or below sea level. And I also take into account the latitude, so I can generate the polar and equator regions. I will later expand this but so far the tiles somewhat resemble a planets topography. There is some other logic built in it to handle areas of water.
It works in the stand alone working project. I still need to update it to function within the game project itself.

Active Elements

So far my plan for dynamically creating random elements is working. I have an endless game universe. It is still buggy though. I'm only rendering the elements in view bug there's a problem with that logic, it seems the active area is moving faster than the current x/y somehow. I think once I get that worked out I can test that I am only creating new elements when the player is in a new location in the game.

I'm currently doing that by looking at the min/max x and y of the existing elements, if the view is beyond either I can generate more.

I ran into an issue when adding elements while I'm reading them so I added a boolean I can set to true while I'm reading them. I don't spawn anything while that's happening. So far that has resolved it while still giving me windows of creation opportunities.

I just need to debug the active element check.

New Endless World Approach

I'm changing my approach. I've tried building and endless game world of random items using panels, related to each other and with their own coordinate systems. This has resulted in stuttering and glitchy positioning and lag. My new approach uses the idea of an exploration history. If the player goes into new territory, by about half the display width/height, random checks are made and possibly new elements spawned.

I'm not yet certain of how long a player can explore before the element count is too much for the game, resulting in lag. That will be one of my first tests. But surely I can mitigate this much easier than trying to make the panel techniques work.

My next steps are to store the created elements for restarting and saving games. I also need to code the starfield and planet surfaces, which will be tiled images. That will also be a challenge, I will have to store surface features like craters etc so the planets look the same when restarting or returning to them. It should be similar to tracking any other element type though.

Not Jumping Ahead

I am re-re-re-starting the space mining arcade style game. This time I want to start simple. I want to set up a grid of nine world panels and ensure they are arranged properly. THEN I will worry about populating them etc. In the past I got ahead of myself and tried to build everything out AND get them arranged correctly. This time out I want to get them arranged and moving correctly, and creating new panels as the player approaches them. Once that is working properly THEN I will populate and or load them from files.

Utopia Flip

My Tomorrowland-inspired IntFiction game is going well. I've tested the logic that randomly flips the player from a retrofuturistic wonderland to a deadly, dark dystopia. Now I'm working through some puzzles and clues in the utopian commercial district.
As I go I'm making some minor - and not so minor tweaks to the game engine. I've updated the logic block elements so that Eval blocks can be defined within the Logicset blocks, instead of requiring Logic elements to house the Evals. So it is possible to do:

{logicset
  [@eval
    ...
  ]
}

As well as:

{logicset
  {logic
    [@eval
      ...
    ]
  }
}

This will save some work when defining more basic logic checks. I may do some other time-saving updates as well. We'll see.

Fight Fix

I continue to be amazed at the issues that keep coming up - after all this time. Granted, the fight engine wasn't rebuilt when I re-coded the WorldWeaver engine. Still I thought I had it working with previous games, where I had many enemies and fights defined.

Tonight I uncovered a bug in the fight engine. It wasn't displaying the 'kill' message. Whenever an enemy is killed the engine would simply say 'I'm not sure what you were trying to examine'. This means that the kill message wasn't being passed to the parser - or not being displayed right then in the fight engine.

After a bunch of debugging I updated it to add the kill message to the fight engine's output. That - at last - fixed it.

We'll see what other fight engine surprises are in store.

Blueprints In 3D

I have recently been tasked with modeling some cars and trucks for an FPS. This is the first time I've modeled cars so I did a bit of tutorial viewing. In Blender 3d you can use images as backgrounds and set them to only show in various views (front, side, top, etc). So I tracked down some free car blueprints and I'm using them as guides. The trick is getting them aligned correctly.

It seems that free blueprints don't quite line up so well (At least the top and side of the one I am using) so I'm taking some creative liberties with BMW's body design :) - but it's fine. We are just looking for generic 'cars' so we may need to tweak some of its unmistakeably BMW-y features anyway.

So far this has been an amazing learning experience. I've done the car's basic body and its headlights and so far it consists of two plane meshes. Every vertice/face has been manually created and positioned... Using the guide images. It's somewhat like tracing a drawing in 3D.

Fight Code Mystery

I figured out the problem with the World Weaver fight class. I was placing debug messages throughout the various methods of the class when I encountered one method whose code was commented out with a note stating that the engine needs to be rewritten still. A while ago I did a thorough rewrite of the client code and apparently hadn't finished the fighting engine. It seems since the rewrite I hadn't yet done any games that did fighting.

I gave it a couple of variables, one for the Player and one for the Opponent - for easy access in the various methods. I had to tweak some of the message logic and cleaned up some method definitions to use the new variables. Now it works. It still doesn't show the 'kill' message properly but the core fighting logic seems good so far.

Back to work on defining the Atomic Cage game.

Now Broke

I am still building games in the World Weaver IntFiction engine I built. The engine is pretty stable, I haven't had to touch the actual code in a long time. Until recently. I ran into an issue when an Event (As opposed to a Command) causes the Player to travel to a new location. It was outputting the Room description twice, so I created the silent travel Action type. It moves the Player but doesn't output any Room Messages. In these scenarios the output is corrected.

I just ran into another interesting problem. In previous games spawning was working fine, however in this new game it seems to be getting stuck in a loop somewhere. This is very frustrating since it was working in the past. I have no idea what broke it. I'll have to add some output messages to pinpoint where it is hanging. When I find the problem I'll outline it here along with the solution I end up correcting it with.

Redundant

I am still plugging away at the NetSplit IntFiction game in the WorldWeaver engine. This time around I'm doing a bit of planning as I go, hoping I don't hit a wall like previous attempts. One thing I'm noticing is a lot of redundancy in the commands and events to accommodate logic cases.

For example, if an event is checking an attribute and then changing that attribute it seems to result in both cases firing. One workaround is to use the fail_event attribute and this is most likely sufficient I just need to remember to use it, otherwise I end up with one node for each logic result, and I have to be careful bout where I do the logic check.

Maybe I need to add a case statement logic eval. And I need to double check the order in which I process logic and messages. Logic should be done first, then the messages. This will hopefully make logic cases more intuitive and less redundant.

Big World

I am making another attempt at an endless world system for my Galaxynet arcade game. I am using panels that are 2x the screen size. Up to three will be loaded at a time. The center panel will be the active one, and any neighboring panels the player is approaching will be loaded and ready to display. If the current panel moves far enough a neighboring panel becomes the active one and its relevant neighbors are loaded.

Each panel has its own GUID and its data is stored in text files. The panels are arranged relative to each other so there are no massive x and y values. For save and restore, the active panel's GUID is stored in the saved game state. The background texture is an exception, it is either random stars or a grid of textures. All other elements will be stored and loaded - as ling as they have non-blank GUIDs. So to create elements like display screens etc, give them blank string GUIDs and they will not be saved to data files.

I know from past attempts, loading ad positioning neighboring panels will be a challenge. Hopefully this new means of handling it will work far more seamlessly than my earlier attempt.

Recording

I use Tests (macros) all the time while I'm authoring games in my IF engine. The problem is defining tests involves remembering all the commands you want it to fire. Until last night. I added command recording. It's an admin tool that records everything the tester enters i to the game. If the tester fires another test as part of the recording session that test's commands are not recorded. When the recording is turned off the recorded commands are output so they can be copied and pasted into the desired test's commands list.

I've already used it once and it made life SO much easier. The further I get into defining the game the more invaluable this new tool will be.

Fun Again

After taking a break from my WorldWeaver IntFiction engine, and IF in general, I've come back. I'm working on a new iteration of the NetSplit cyberpunk/hacker game. And for the first time writing IF games I'm actually really having fun. Usually it starts out exciting - a good story/game idea etc. But soon becomes tedious. I spend hours defining mundane buildings and rooms. I start to wonder if the game - after all my hard work - will even be fun to play.

I'm not sure this game will be fun either but so far it's still fun to author. It may be that I'm learning how to use my own engine more effectively. I've been able to conversations, puzzles, and traps. I've also been able to code 'hacker commands' and time-based events.

I'll be updating the WorldWeaver site with the latest builds and WIP copy of NetSplit soon.