C++

Tactics!

Three months later, and I’m back.

Tactics is relevant again, I’ve been resorting code, making things less ugly, and adding functionality to the engine for almost a week now, which means I’m back!

First of all, what have I done up until a week ago?

I was working on graphics, getting polygons to rotate properly, and did it.
I released a working version of this, with a square, movement and rotation. (I was pretty proud of myself: I don’t care what anyone else thinks)Colors, scaling (i.e. zoom) and non-oblong shapes are all completely within the scope of the code I have made, but the point of the release was to test the one feature I had doubts about, not to show off the features I’m comfortable with.

Then I moved house and forgot about it until now. With school exams finished for the semester, I started programming last week, and I feel comfortable saying that I am back!

Since graphics are working, I’m changing the layout of the source, and creating a “game instance” class that will help separate the graphics, engine, and game from eachother, and then it will be work on actual game mechanics like entities and movement!

Exciting times.

Advertisements

Another Project :D

A while ago I mentioned a secret project, rather loosely titled “RPG engine”; well on GitHub is a repository for the design and planning involved, although as of this being published it is it not very detailed. (Also the game idea is very different to what the title tends to imply)

I recently started actually working on a programming project which is designed to be a Harvest Moon clone. It is going to run without any interface, and this will be the case indefinitely. Some day, when I get better at C++ graphics, I shall bother with that, but if I want to work on graphics I’ll just work on my tactics project.

I don’t exactly know how the project is going to go, I’ll just work on it as I wish alongside the other two projects, and try to learn something.

My Super Cool Storage Design For Video Games

This is an idea I have had in previous text based designs, that I think I shall finally implement in my zombies project:

It is a system for determining how much stuff can fit inside a storage container;

It works by using hard coded dimensions for the sizes of objects and containers, (rather than a “size” attribute that directly determines how much storage it occupies.)

Then two processes occur to check to see if it could probably fit in:

First it checks to see if the object could fit into the container if the container were completely empty:

  1. Arrange the dimensions of the container in descending order, have a biggest, middle and smallest.
  2. Do the same for the object being fitted.
  3. Compare the respective sizes,

if any of the three object dimensions are greater than their respective container dimension, the object doesn’t fit.

Then it performs a check which is equivalent to the usual “size” attribute check, using the volume of the object and the volume of all other objects and the liquid capacity of the container to check the plausibility of the object fitting.

If both checks succeed then the object fits fine. This system isn’t quite perfect, but it is very good.

Of course not all objects are a simple cubic three dimensions, so three dimensions must be chosen that encompass the object for the sake of the algorithm, although most objects will have square or circular bases (buckets, sticks, kitchenware) and the latter can simply be translated to the former.

The empty space that is ‘wasted’ in this process by rounding circles up into square objects compensates very well for the fact that some situations are completely impossible but pass both tests anyway. In other words, since there is no actual tetris involved in the storage process, there is a space penalty.

Now in terms of benefits, this system provides variety, in fact, this system can create gameplay by providing situations in which the size of containers needs to make you think about how you are going to sort your possessions to deal with them.

Now all I need to do is think of something to make that a good thing, and not just completely annoying.

Secret Project Now Mentioned

Over the past couple of weeks, I have put together some thoughts and ideas I’ve had into one big messy and fun project that should probably take the rest of my life.

If you think I am biting off more than I can chew, too bad, I’ve learned not to care.

It should contain lots of npc driven gameplay, and isometric graphics.

On that note, it is time to turn my development cycle back over to the zombies project!

Different Control Schemes in Tactics

A design I have long had in mind is for three different control / planning systems working together in the same game environment.

Avatar

Normal tactical input, in which you construct a game plan, and submit it to then see the consequences of your plan; After seeing the consequences you reevaluate and repeat the process, stepping forward until you reach your goal or screw up and get shot.

The key element to avatars is their reaction time, which would control how the characters react to events, and how you think about your plan as you make it. When you submit a plan you would only see up to a point in the resulting consequences, for example:

Unit with 3s reaction time:

  • Peak around corner over 2 seconds:
    • move out for 0.5,
    • look for 1.0 and
    • move back for 0.5
  • stand behind cover for three seconds

The five second plan would be submitted, and you would be given whatever they saw for the first (five minus three) two seconds of the plan, the remaining (in this case idle) three seconds of the plan would be locked, as a trade off for the fact that you can see what happened in the first two.

This of course represents the unit spending three seconds to think about what they just saw, and evaluate the future plan they will take.

Being a very central system in the game, these will be explained in a lot more detail in the future.

Terminal

Not sure why I chose this name for them; A terminal is a giant every-possibility-considered plan that branches depending on certain events and is generally not very much fun to develop plans in.

For the most part they are exactly identical to avatars, and depending on the level design may just act as a script that saves simple tasks you have done before in case a future opponent does exactly the same thing in the early phases of your next match.

They also could serve in a terminal V terminal game in which you need to develop the best plan that will push your opponent to a check mate position where they will have to reevaluate an earlier branch in their noded plan. (Whether or not either of the previous two paragraphs made sense, you don’t actually need to know what I mean)

I have no idea at the moment with respect to making terminal design more dynamic, though this would be extremely important as simple adjustments in a unit’s placement would otherwise require an entirely duplicated branch. Overlapping with ideas presented in the final control type (scripts) will probably prove useful.

Scripts

Programmed units that aren’t controlled at all during the progress of the game. My plan for making them is to create simple scripting capabilities, and then wait for someone to learn how to use them and thus work out what their limiting feature is; when they give me feedback I would be able to significantly improve the potential of the script designing system. (So follow this blog! Leave comments! I’ll be fueled almost entirely by fanbase in not too much time at all!)

Scripts would allocate nametags to entities and go through processes to determine what they ought to try doing. (that’s all I’ve got at the moment…)

Script design would allow for some very powerful features to be added to terminal and avatar interface as well… This game could be good.

Integrated Scripts

Scripts would have the option to utilize information on the map laid out by the map-maker, to maximize the success of NPC enemies basically.

Scripts would be made to use place tags, and then a map maker (perhaps the same person who made the script?) would place these place tags on their map to create an I.S. functionality.
In the future I’ll explain the way that these three interact with eachother, and I shall also explain how the latter two systems have very strong uses in NPC construction.

Building a 2D World from Polygons

In my tactical project, I am building my world from polygons:

There are however a variety of polygon types to serve the functions of the world:

Platform

A floating platform shape, suspended in 3D space.

They have a collisionable floor and are given a specific designated height for wall structures to occupy.

By constructing a prism in the virtual space, each platform can be assigned a “field region”, the field region of two platforms can never overlap, but can touch on their extremity.

A floor thickness may be possible, but probably not until later in the project, especially since platforms won’t support 3D suspension completely anyway… Not for a long time…

Exclusion

This marks a part of a platform that isn’t occupied by floor; this way creating a hole in the floor isn’t the excruciating process of drawing a tightly folded C-shape. (which would no doubt result in collision errors if things fell smack-on the seam) This way the holes can also be more manipulable as well. (In both level editing, and in meta blocks.)

Block

Block is another word for wall. A block is a polygon that is set inside of a platform polygon; the polygon represents a wall with the height associated with the platform.

Blocks are, of course, collisionable.

Properties such as visibility (glass) and penetrability (plaster/otherwise thin walls) are so far unconsidered; they would likely take on a specialized polygon based off of the Block.

Meta

Meta-blocks are also set within a polygon. The specifics can be explained in a future post, but a meta is an alternate map for the platform, alongside programmable property systems that would allow you to control when, and where, the alternate mapping would replace the current one.

I don’t know if that makes sense, but the system I have in my head allows for the creation of destructible terrain, interactive elements such as oil slicks, and special map triggers, for all of your map-making needs.

Effect

The just-now named “effectygons” will be what manages certain live gameplay aspects of the game.

Effectygons will always hold the kinds of property that meta-blocks use as input, and will also have the possibility to interact quite heavily with meta-blocks. (as well as other effectygons. So then an oil slick would probably work better if it were just an effect!)

The flame of a flame-thrower, the smoke or explosion of a grenade, and specialties such as liquids and chemical coverings are all possibilities of this system.

The exact extent to which they will be programmable is currently unknown; the only thing I really understand is how properties and timers will work, and how meta-blocks can be used to extend their effects in map-specific ways. Things like fluid dynamic, or projectiles parting smoke would be fun and ideal, but not confirmed… I don’t know yet how it might work.

Kinetic?

Moving and functional blocks that have a height independant of their platform could be useful for map design.

Tables, working doors and miscellaneous objects and blocks would be ideally constructed in this manner… the possibility of vaulting low objects is an immensely exciting idea for a tactical shooter design as well.

The problem is that having non-rigid objects would create complications in that certain situations may desire explosions, and physics, the latter of which I am undoubtedly incapable of delivering; even if I could it would be very displeasing to have objects that behave with physics but cannot pitch or roll due to their 2D constrictions… it would be even more displeasing if they actually did pitch and roll in what is otherwise a beautiful and elegant design scheme.

As indicated by the question mark, I am not certain enough of this to really give much speculation or implication about how it would work; my first priority is working that out on a semi-technical level, to get an idea of complexity and direction.

Time Stamp

These are my thoughts and ideas so far!

They have been a few months in the making, so hopefully they are going to be good.

I’ll post some follow-up as more ideas and thoughts come… but first I am going to be posting about the technical side of collision detection in a tactical game environment such as the one I am planning and making.

Combat Systems for Zombies

In my zombies project I would like to strengthen zombies in terms of their abilities as a group.

The Sagittarian is a zombie themed interactive fiction which is definitely worth checking out.
The combat scenes are usually dictated by two rules:

  1. More than two zombies and things are getting risky;
  2. If you don’t know what is around the corner, it will probably bite you.

The events are all about zombies that you hadn’t seen getting to you, or too many zombies being in front of you and having you succumb to distraction.

This is how I would probably like to see zombies in my zombie project.

The game would be about avoiding tight melee situations, and altogether avoid being close to zombies if you aren’t providing your fullest attention.

Systems that could enforce this that come to mind involve an “attention quota” that you manually distribute between hostiles and environment in a situation, and the less you assign to an element, the more chance you have of screwing something up with it, assuming that it does do something.

This doesn’t however take into account the existence of firearms. For these two systems to work well together, firearms would need to be quite expensive, and consume ammo readily.
A supply of ammunition can help you through a couple of sticky situations, or maybe one horde situation.

The thoughts that this all leads onto, relate to some ideas such as:

  • explosives
  • non-zombie npcs
  • non-common zombies
  • environment interactions
  • firearm diversity
  • fire-arm noise that attracts more zeds
  • ad-hoc weaponry
  • status buffs like adrenaline to affect attention span and such

I’d be interested to know what other people think about where I could take these ideas as well!