Posts Tagged ‘TODO’
Today I have to finish the following:
- Implement the story
- Make moar enemies (at least 3)
- Make moar levels (like 5?)
- Menu + game over screens
- Correct the character movement (if anyone has any experience with making realistic 8-way movement, it would be much appreciated!)
Finishing those things would make me satisfied, and would let me consider the game “finished”. I also have some “stretch goals” so to say:
- Sounds! And music! I have no idea how to this! Free online sound files I guess!
- Art update!
- Exclamation points!
And 3. 2. 1. GO
Good luck everyone!
My game is almost done. I have 5-11 hours and this todo-list:
- Add humans(in code)
- Human animation
- Level2 background
- Some additional stuff, e.g. doors, furniture..
- Level3 ???
Find the video of v0.2 on YouTube: http://youtu.be/-hzI1prmSVs
- the player´s character (a green virus! what surprise!) is now animated.
- the player can rotate/turn the camera left and right.
- some red enemies rotate and wait for the player to shoot them.
- at the far end of the level there is an exit waiting.
To do stuff:
- Camera moves out of the level walls – ugly, must fix!
- Enemies want to shoot player badly. Must implement this.
- Maybe some health bar for the virus? (Do viruses in reality have … health?! Wondering….)
- Dead enemies must drop “source code artifacts” -> for feeding the virus, so that it can evolve / mutate / grow / level up
- Some UI for main menu etc (think I will use generic Unity-GUI – ugly, but times running out)
- Some funny background story.
- More levels.
- UI for choosing the power-ups of the morphed virus.
- Now: empty the bottle of beer, then sleep a little.
Screenie of “Morph, Virus, Morph!” v0.2
Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there. It’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.
The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.
So, here it goes:
Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).
What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.
That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not. An ID would be an unsigned integer, so it could range from 0 to over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.
The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.
Although it looks complicated compared to the previous system, it seems that it’s worth a try. Did anybody run into similar, or other worthy conclusions on that matter?
The level editor. Because of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.
The scenes. The hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.
Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and if it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a massacre and I was really confused which if statement was responsible for what event.
The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?
And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?
That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.
If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that
Time won’t stop even if I wish. Minutes and hours are passing by like snowflakes in heavy snow storm but there is progress! I’ve done quite some stuff in last few hours if I can boast. Enemies are implemented, lighting system updated and some additional graphics done. I want to make more than 2 enemies at the moment but I’m afraid 9 hours will turn around like nothing and that’s why I have to concentrate on most important stuff – dying, completing a map and most of all main menu.
Title for my miniLD11 entry. I decided to take make a sandbox type game of an actual sandbox. After the first day, I haven’t put much work into it, but I have a sandbox i can display and I can shovel the sand around.
*Add phisic to the sand, making it collapse when a pile is too big.
*Add bucket with water. Wet sand has better building propreties ( I guess )
*Add some candy like music.
*Figure out some king of gameplay. :S